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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
If you have a testcase without lto, it will be certainly easier to reduce.  So
yes, a testcase would be appreciated.

[Bug target/63679] [5/6 Regression][AArch64] Failure to constant fold.

[jan.sm...@alcatel-lucent.com]

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

Jan Smets  changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #41 from Jan Smets  ---
Breaks a bunch of other things. See PR 69352

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

[jan.sm...@alcatel-lucent.com]

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

Jan Smets  changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #1 from Jan Smets  ---
Same for mips compiling source files. If you need a testcase please let me
know.

[Bug c++/69324] non-constexpr function cannot be called in a constexpr initializer even if the full-expression is a constexpr

[dreifachstein at gmail dot com]

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

Yu Xiaolei  changed:

   What|Removed |Added

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

--- Comment #1 from Yu Xiaolei  ---
Sorry I had misread the spec. Non-constexpr invocation is explicitly forbidden
in the spec.

[Bug tree-optimization/69326] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

Bug 69320 Summary: [6 Regression] wrong code generation at -O2 and higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69320

   What|Removed |Added

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

[Bug tree-optimization/69320] [6 Regression] wrong code generation at -O2 and higher

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---
Fixed by commit on the trunk.

[Bug tree-optimization/69320] [6 Regression] wrong code generation at -O2 and higher

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #12 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug tree-optimization/69325] [6 Regression] wrong code at -O3 on x86-64-linux-gnu (in 32- and 64-bit modes)

[law at redhat dot com]

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

Bug 69320 Summary: [6 Regression] wrong code generation at -O2 and higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69320

   What|Removed |Added

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

[Bug tree-optimization/69320] [6 Regression] wrong code generation at -O2 and higher

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Tue Jan 19 06:43:54 2016
New Revision: 232548

URL: https://gcc.gnu.org/viewcvs?rev=232548&root=gcc&view=rev
Log:
2016-01-18  Jeff Law  

PR tree-optimization/69320
* tree-ssa-dom.c (record_edge_info): For comparisons against a boolean
ranged object, do nothing if the RHS constant is not [0..1].
(optimize_stmt): Comparing a boolean ranged object against a
constant outside [0..1] results in a compile-time constant.

* tree-ssanames.c (ssa_name_has_boolean_range): Remove unnecessary
test.

PR tree-optimization/69320
* gcc.c-torture/pr69320-1.c: New test.
* gcc.c-torture/pr69320-2.c: New test.
* gcc.c-torture/pr69320-3.c: New test.
* gcc.c-torture/pr69320-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr69320-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr69320-2.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr69320-3.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr69320-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c
trunk/gcc/tree-ssanames.c

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

[law at redhat dot com]

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

--- Comment #43 from Jeffrey A. Law  ---
Mike, consider this approval for backporting the fix to the release branches.

[Bug bootstrap/69352] 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=69352

Bug ID: 69352
   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
CC: alalaw01 at gcc dot gnu.org
  Target Milestone: ---

On Linux/x86-64, r232508 gave

export/gnu/import/git/gcc-regression/gcc/gcc/caller-save.c: In function
\u2018insert_restore\u2019:
/export/gnu/import/git/gcc-regression/gcc/gcc/caller-save.c:1187:1: internal
compiler error: in equal_mem_array_ref_p, at tree-ssa-scopedtables.c:271
 insert_restore (struct insn_chain *chain, int before_p, int regno,
 ^

0x10f2b5e equal_mem_array_ref_p
   
/export/gnu/import/git/gcc-regression/gcc/gcc/tree-ssa-scopedtables.c:271
0x10f2b5e hashable_expr_equal_p
   
/export/gnu/import/git/gcc-regression/gcc/gcc/tree-ssa-scopedtables.c:309
0x10f2c82 expr_elt_hasher::equal(expr_hash_elt* const&, expr_hash_elt* const&)
   
/export/gnu/import/git/gcc-regression/gcc/gcc/tree-ssa-scopedtables.c:747
0xff0f50 hash_table::find_slot_with_hash(expr_hash_elt* const&, unsigned int,
insert_option)
/export/gnu/import/git/gcc-regression/gcc/gcc/hash-table.h:873
0xfea061 hash_table::find_slot(expr_hash_elt*
const&, insert_option)
/export/gnu/import/git/gcc-regression/gcc/gcc/hash-table.h:414
0xfea061 lookup_avail_expr
/export/gnu/import/git/gcc-regression/gcc/gcc/tree-ssa-dom.c:1988
0xfeabd9 eliminate_redundant_computations
/export/gnu/import/git/gcc-regression/gcc/gcc/tree-ssa-dom.c:1455
0xfee4ee optimize_stmt
/export/gnu/import/git/gcc-regression/gcc/gcc/tree-ssa-dom.c:1833
0xfee4ee dom_opt_dom_walker::before_dom_children(basic_block_def*)
/export/gnu/import/git/gcc-regression/gcc/gcc/tree-ssa-dom.c:1363
0x195aecb dom_walker::walk(basic_block_def*)
/export/gnu/import/git/gcc-regression/gcc/gcc/domwalk.c:265
0xfef610 execute
/export/gnu/import/git/gcc-regression/gcc/gcc/tree-ssa-dom.c:608
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/cc0VbGJg.ltrans30.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: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
/export/gnu/import/git/gcc-regression/gcc/gcc/cp/Make-lang.in:100: recipe for
target 'cc1plus' failed

[Bug c++/69251] [6 Regression] ICE in unify_array_domain on a flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Target|i686-linux-gnu  |
Summary|[6 Regression] ICE  |[6 Regression] ICE in
   |(segmentation fault) in |unify_array_domain on a
   |unify_array_domain on   |flexible array member
   |i686-linux-gnu  |

--- Comment #7 from Martin Sebor  ---
A minimal patch to fix the ICE has been posted for review:
  https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01348.html

[Bug c++/61597] Unexpected behavior at runtime

[dev.kram5 at gmail dot com]

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

Mark  changed:

   What|Removed |Added

 CC||dev.kram5 at gmail dot com

--- Comment #20 from Mark  ---
I know this thread is very old but I just like to add my findings.
I find out that your Memory::Array::begin, does not return the reference for
the base address of the array.

See this code revision of yours
http://coliru.stacked-crooked.com/a/c8a35765668fbca6
and look down at line 1081

I have changed it to
auto const begin = &indices[0];

[Bug c++/24664] Template instantiation generating an array of voids doesn't fail

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
Author: ppalka
Date: Tue Jan 19 00:19:16 2016
New Revision: 232547

URL: https://gcc.gnu.org/viewcvs?rev=232547&root=gcc&view=rev
Log:
Fix the remaining PR c++/24666 blockers (arrays decay to pointers too early)

gcc/cp/ChangeLog:

PR c++/11858
PR c++/24663
PR c++/24664
* decl.c (grokdeclarator): Don't decay array parameter type to
a pointer type if it's dependent.
(grokparms): Invoke strip_top_quals instead of directly invoking
cp_build_qualified_type.
* pt.c (decay_dependent_array_parm_type): New static function.
(type_unification_real): Call decay_dependent_array_parm_type
to decay a dependent array parameter type to its corresponding
pointer type before unification.
(more_specialized_fn): Likewise.
(get_bindings): Likewise.
* tree.c (cp_build_qualified_type): Trivial typofix in
documentation.

gcc/testsuite/ChangeLog:

PR c++/11858
PR c++/24663
PR c++/24664
* g++.dg/template/pr11858.C: New test.
* g++.dg/template/pr24663.C: New test.
* g++.dg/template/unify12.C: New test.
* g++.dg/template/unify13.C: New test.
* g++.dg/template/unify14.C: New test.
* g++.dg/template/unify15.C: New test.
* g++.dg/template/unify16.C: New test.
* g++.dg/template/unify17.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/template/pr11858.C
trunk/gcc/testsuite/g++.dg/template/pr24663.C
trunk/gcc/testsuite/g++.dg/template/unify12.C
trunk/gcc/testsuite/g++.dg/template/unify13.C
trunk/gcc/testsuite/g++.dg/template/unify14.C
trunk/gcc/testsuite/g++.dg/template/unify15.C
trunk/gcc/testsuite/g++.dg/template/unify16.C
trunk/gcc/testsuite/g++.dg/template/unify17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/24666] [meta-bug] arrays decay to pointers too early

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
Author: ppalka
Date: Tue Jan 19 00:19:16 2016
New Revision: 232547

URL: https://gcc.gnu.org/viewcvs?rev=232547&root=gcc&view=rev
Log:
Fix the remaining PR c++/24666 blockers (arrays decay to pointers too early)

gcc/cp/ChangeLog:

PR c++/11858
PR c++/24663
PR c++/24664
* decl.c (grokdeclarator): Don't decay array parameter type to
a pointer type if it's dependent.
(grokparms): Invoke strip_top_quals instead of directly invoking
cp_build_qualified_type.
* pt.c (decay_dependent_array_parm_type): New static function.
(type_unification_real): Call decay_dependent_array_parm_type
to decay a dependent array parameter type to its corresponding
pointer type before unification.
(more_specialized_fn): Likewise.
(get_bindings): Likewise.
* tree.c (cp_build_qualified_type): Trivial typofix in
documentation.

gcc/testsuite/ChangeLog:

PR c++/11858
PR c++/24663
PR c++/24664
* g++.dg/template/pr11858.C: New test.
* g++.dg/template/pr24663.C: New test.
* g++.dg/template/unify12.C: New test.
* g++.dg/template/unify13.C: New test.
* g++.dg/template/unify14.C: New test.
* g++.dg/template/unify15.C: New test.
* g++.dg/template/unify16.C: New test.
* g++.dg/template/unify17.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/template/pr11858.C
trunk/gcc/testsuite/g++.dg/template/pr24663.C
trunk/gcc/testsuite/g++.dg/template/unify12.C
trunk/gcc/testsuite/g++.dg/template/unify13.C
trunk/gcc/testsuite/g++.dg/template/unify14.C
trunk/gcc/testsuite/g++.dg/template/unify15.C
trunk/gcc/testsuite/g++.dg/template/unify16.C
trunk/gcc/testsuite/g++.dg/template/unify17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/24663] Template instantiation generating a zero-sized array doesn't fail

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
Author: ppalka
Date: Tue Jan 19 00:19:16 2016
New Revision: 232547

URL: https://gcc.gnu.org/viewcvs?rev=232547&root=gcc&view=rev
Log:
Fix the remaining PR c++/24666 blockers (arrays decay to pointers too early)

gcc/cp/ChangeLog:

PR c++/11858
PR c++/24663
PR c++/24664
* decl.c (grokdeclarator): Don't decay array parameter type to
a pointer type if it's dependent.
(grokparms): Invoke strip_top_quals instead of directly invoking
cp_build_qualified_type.
* pt.c (decay_dependent_array_parm_type): New static function.
(type_unification_real): Call decay_dependent_array_parm_type
to decay a dependent array parameter type to its corresponding
pointer type before unification.
(more_specialized_fn): Likewise.
(get_bindings): Likewise.
* tree.c (cp_build_qualified_type): Trivial typofix in
documentation.

gcc/testsuite/ChangeLog:

PR c++/11858
PR c++/24663
PR c++/24664
* g++.dg/template/pr11858.C: New test.
* g++.dg/template/pr24663.C: New test.
* g++.dg/template/unify12.C: New test.
* g++.dg/template/unify13.C: New test.
* g++.dg/template/unify14.C: New test.
* g++.dg/template/unify15.C: New test.
* g++.dg/template/unify16.C: New test.
* g++.dg/template/unify17.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/template/pr11858.C
trunk/gcc/testsuite/g++.dg/template/pr24663.C
trunk/gcc/testsuite/g++.dg/template/unify12.C
trunk/gcc/testsuite/g++.dg/template/unify13.C
trunk/gcc/testsuite/g++.dg/template/unify14.C
trunk/gcc/testsuite/g++.dg/template/unify15.C
trunk/gcc/testsuite/g++.dg/template/unify16.C
trunk/gcc/testsuite/g++.dg/template/unify17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/11858] Name lookup error ignored when instantiated from expression within sizeof() in template function parameter

[ppalka at gcc dot gnu.org]

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

--- Comment #6 from Patrick Palka  ---
Author: ppalka
Date: Tue Jan 19 00:19:16 2016
New Revision: 232547

URL: https://gcc.gnu.org/viewcvs?rev=232547&root=gcc&view=rev
Log:
Fix the remaining PR c++/24666 blockers (arrays decay to pointers too early)

gcc/cp/ChangeLog:

PR c++/11858
PR c++/24663
PR c++/24664
* decl.c (grokdeclarator): Don't decay array parameter type to
a pointer type if it's dependent.
(grokparms): Invoke strip_top_quals instead of directly invoking
cp_build_qualified_type.
* pt.c (decay_dependent_array_parm_type): New static function.
(type_unification_real): Call decay_dependent_array_parm_type
to decay a dependent array parameter type to its corresponding
pointer type before unification.
(more_specialized_fn): Likewise.
(get_bindings): Likewise.
* tree.c (cp_build_qualified_type): Trivial typofix in
documentation.

gcc/testsuite/ChangeLog:

PR c++/11858
PR c++/24663
PR c++/24664
* g++.dg/template/pr11858.C: New test.
* g++.dg/template/pr24663.C: New test.
* g++.dg/template/unify12.C: New test.
* g++.dg/template/unify13.C: New test.
* g++.dg/template/unify14.C: New test.
* g++.dg/template/unify15.C: New test.
* g++.dg/template/unify16.C: New test.
* g++.dg/template/unify17.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/template/pr11858.C
trunk/gcc/testsuite/g++.dg/template/pr24663.C
trunk/gcc/testsuite/g++.dg/template/unify12.C
trunk/gcc/testsuite/g++.dg/template/unify13.C
trunk/gcc/testsuite/g++.dg/template/unify14.C
trunk/gcc/testsuite/g++.dg/template/unify15.C
trunk/gcc/testsuite/g++.dg/template/unify16.C
trunk/gcc/testsuite/g++.dg/template/unify17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68692] [6 Regression][graphite] ice: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
The original concept for stdc-predef.h includes that it might include 
other headers - in particular, that it might #include_next 
, so that e.g. libdfp could provide its own stdc-predef.h 
that defines relevant __STDC_* macros to say that DFP library 
functionality is available before including the glibc version, when you 
use -isystem /usr/include/dfp.

Now, libdfp currently doesn't do that, and such use of libdfp might not be 
expected to work with PCH, so fixincluding may well be sufficient for this 
bug at present.

[Bug driver/69351] New: response files on linux don't get populated and leave undeleted temporary files

[slyfox at inbox dot ru]

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

Bug ID: 69351
   Summary: response files on linux don't get populated and leave
undeleted temporary files
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

Target: x86_64-pc-linux-gnu

Was originally found in GHC:
https://ghc.haskell.org/trac/ghc/ticket/10986#comment:10

How to reproduce:

$ mkdir temp
$ touch a.rsp
$ echo 'int main(){}' > a.c

$ TEMP=./temp gcc a.c -o a @a.rsp
$ TEMP=./temp gcc a.c -o a @a.rsp
$ TEMP=./temp gcc a.c -o a @a.rsp
$ TEMP=./temp gcc a.c -o a @a.rsp
$ cat a.rsp
$ ls temp/
cc0IcCCL  ccAThvWy  ccWtkCWa  ccdRashU

$ cat cc0IcCCL
-plugin
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper
-plugin-opt=-fresolution=./temp/ccna5Vgh.res
-plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr
-m
elf_x86_64
-dynamic-linker
/lib64/ld-linux-x86-64.so.2
-o
a
/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/crtbegin.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0
-L/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64
-L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../..
./temp/ccEaETmy.o
-lgcc
--as-needed
-lgcc_s
--no-as-needed
-lc
-lgcc
--as-needed
-lgcc_s
--no-as-needed
/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/crtend.o
/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/crtn.o

[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
LGTM, builds fine as well.

[Bug testsuite/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC|ubizjak at gmail dot com   |
  Component|lto |testsuite
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #12 from Uroš Bizjak  ---
Testsuite issue, patch posted at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01341.html

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

[vapier at gcc dot gnu.org]

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

Mike Frysinger  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org,
   ||wilson at tuliptree dot org

--- Comment #42 from Mike Frysinger  ---
cc-ing the people listed as ia64 maintainers ... can we get someone to just
approve the patch for gcc-4.9 & gcc-5 branches ?  i can take care of actually
committing it.

[Bug target/69252] [4.9/5/6 Regression] gcc.dg/vect/vect-iv-9.c FAILs with -Os -fmodulo-sched -fmodulo-sched-allow-regmoves -fsched-pressure

[zhroma at ispras dot ru]

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

--- Comment #13 from Roman Zhuykov  ---
(In reply to Jakub Jelinek from comment #12)
> Thus, Roman, can you please post your patch to gcc-patches?
Ok, in addition to comment 3 link, reposted it right now
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01336.html, and ask Martin to
help with creating new regression test, since I'm not ready to setup powerpc
qemu vm at the moment.

[Bug jit/69144] running the libgccjit tests leaves temporary files /tmp/libgccjit-*

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-18
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

The debris seems to be:

- ahead-of-time compilation artifacts (.exe files, .so and .s) which
linger in the tempdir after they've been copied up to the output_path.

- dumpfiles that were requested via gcc_jit_context_enable_dump

This will affect users of the libgccjit, not just the testsuite, so these
should probably be cleaned up by jit::tempdir::~tempdir, or maybe when they are
copied up to their final locations.  (Maybe the latter should add the tempfiles
to a list which gets unlinked by the former)

[Bug target/69305] [5/6 Regression] wrong code with -O and int128 @ aarch64

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Henderson  ---
Mine.

[Bug libstdc++/69350] Don't define the C99 functions in -std=c++98 mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-18
Version|5.3.1   |6.0
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug libstdc++/69350] New: Don't define the C99 functions in -std=c++98 mode

[redi at gcc dot gnu.org]

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

Bug ID: 69350
   Summary: Don't define the C99  functions in -std=c++98
mode
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

std::signbit etc. shouldn't be defined in C++98 mode.

They shouldn't be in namespace std, but for -std=gnu++98 (not -std=c++98) we
might want to leave them defined in the global namespace (that won't be
possible for GNU/Linux unless/until we stop defining _GNU_SOURCE implicitly).

[Bug target/69176] [6 Regression] ICE in in final_scan_insn, at final.c:2981 on aarch64-linux-gnu

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #18 from Richard Henderson  ---
Fixed.

[Bug target/69176] [6 Regression] ICE in in final_scan_insn, at final.c:2981 on aarch64-linux-gnu

[rth at gcc dot gnu.org]

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

--- Comment #17 from Richard Henderson  ---
Author: rth
Date: Mon Jan 18 20:56:13 2016
New Revision: 232540

URL: https://gcc.gnu.org/viewcvs?rev=232540&root=gcc&view=rev
Log:
PR target/69176

  * config/aarch64/aarch64.md (add3): Move long immediate
  operands to pseudo only if CSE is expected.  Split long immediate
  operands only after reload, and for the stack pointer.
  (*add3_pluslong): Remove.
  (*addsi3_aarch64, *adddi3_aarch64): Merge into...
  (*add3_aarch64): ... here.  Add r/rk/Upl alternative.
  (*addsi3_aarch64_uxtw): Add r/rk/Upl alternative.
  (*add3 peepholes): New.
  (*add3 splitters): New.
  * config/aarch64/constraints.md (Upl): New.
  * config/aarch64/predicates.md (aarch64_pluslong_strict_immedate): New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/config/aarch64/constraints.md
trunk/gcc/config/aarch64/predicates.md

[Bug c++/69349] New: template substitution error for flexible array members

[msebor at gcc dot gnu.org]

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

Bug ID: 69349
   Summary: template substitution error for flexible array members
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While working on a fix for bug 69251 I noticed the following problem.

The following valid test case fails with both 5.3 and 6.0.  It is accepted by
Clang.

$ cat x.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -o/dev/null -xc++ x.c

template 
struct A;

template 
struct A { typedef int X; };

template  int foo (T&, typename A::X = 0) { return 0; }

struct B { int n, a[]; };

void bar (B *b)
{
foo (b->a);
}
x.c: In function ‘void bar(B*)’:
x.c:13:14: error: no matching function for call to ‘foo(int [])’
 foo (b->a);
  ^

x.c:7:24: note: candidate: template int foo(T&, typename A::X)
 template  int foo (T&, typename A::X = 0) { return 0; }
^~~

x.c:7:24: note:   template argument deduction/substitution failed:
x.c: In substitution of ‘template int foo(T&, typename A::X) [with
T = int []]’:
x.c:13:14:   required from here
x.c:7:24: error: invalid use of incomplete type ‘struct A’
x.c:2:8: note: declaration of ‘struct A’
 struct A;
^


G++ 5.3.0 gives a slightly different error because it treats flexible array
members and zero-length arrays identically:

x.c:9:21: warning: ISO C++ forbids zero-size array ‘a’ [-Wpedantic]
 struct B { int n, a[]; };
 ^
x.c: In function ‘void bar(B*)’:
x.c:13:14: error: no matching function for call to ‘foo(int [0])’
 foo (b->a);
  ^
x.c:7:24: note: candidate: template int foo(T&, typename A::X)
 template  int foo (T&, typename A::X = 0) { return 0; }
^
x.c:7:24: note:   template argument deduction/substitution failed:
x.c: In substitution of ‘template int foo(T&, typename A::X) [with
T = int [0]]’:
x.c:13:14:   required from here
x.c:7:24: error: invalid use of incomplete type ‘struct A’
x.c:2:8: note: declaration of ‘struct A’
 struct A;
^

[Bug c/67314] No warning on assigning an out-of-range integer to an enum

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #4)
> The trouble is that while gcc
> makes it easy to assign without a warning values to enums that are outside
> the range of the enumerated type, it makes it difficult to handle such
> values in case and switch statements without eliciting one of the -Wswitch
> warnings.  In those cases gcc either complains about "case values being not
> in enumerated type" or it complains about a "switch missing default case"
> and there doesn't seem to be an easy way to make it happy. 

Cast to int?

[Bug c/67314] No warning on assigning an out-of-range integer to an enum

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #5 from Eric Gallager  ---
(In reply to Martin Sebor from comment #4)
> The trouble is that while gcc makes it easy to assign without a warning
> values to enums that are outside the range of the enumerated type, it makes
> it difficult to handle such values in case and switch statements without
> eliciting one of the -Wswitch warnings.  In those cases gcc either complains
> about "case values being not in enumerated type" or it complains about a
> "switch missing default case" and there doesn't seem to be an easy way to
> make it happy.

See also Bug 61864 for more on issues with warnings having to do with the
relationship between enums and switch statements.

[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname

[dvyukov at google dot com]

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

--- Comment #8 from Dmitry Vyukov  ---
Jakub, does the following patch look good to you?
Just don't want to intermix tsan and sanitizer_common interceptor macros.
I think it's better to define and initialize an interceptor in a single file.


Index: rtl/tsan_interceptors.cc
===
--- rtl/tsan_interceptors.cc(revision 257875)
+++ rtl/tsan_interceptors.cc(working copy)
@@ -2313,6 +2313,11 @@
 // Since the interceptor only initializes memory for msan, the simplest
solution
 // is to disable the interceptor in tsan (other sanitizers do not call
 // signal handlers from COMMON_INTERCEPTOR_ENTER).
+// As __tls_get_addr has been intercepted in the past, to avoid breaking
+// libtsan ABI, keep it around, but just call the real function.
+#if SANITIZER_INTERCEPT_TLS_GET_ADDR
+#define NEED_TLS_GET_ADDR
+#endif
 #undef SANITIZER_INTERCEPT_TLS_GET_ADDR

 #define COMMON_INTERCEPT_FUNCTION(name) INTERCEPT_FUNCTION(name)
@@ -2538,6 +2543,12 @@

 #include "sanitizer_common/sanitizer_common_syscalls.inc"

+#ifdef NEED_TLS_GET_ADDR
+TSAN_INTERCEPTOR(void *, __tls_get_addr, void *arg) {
+  return REAL(__tls_get_addr)(arg);
+}
+#endif
+
 namespace __tsan {

 static void finalize(void *arg) {
@@ -2721,6 +2732,10 @@
   TSAN_INTERCEPT(__cxa_atexit);
   TSAN_INTERCEPT(_exit);

+#ifdef NEED_TLS_GET_ADDR
+  TSAN_INTERCEPT(__tls_get_addr);
+#endif
+
 #if !SANITIZER_MAC && !SANITIZER_ANDROID
   // Need to setup it, because interceptors check that the function is
resolved.
   // But atexit is emitted directly into the module, so can't be resolved.

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #8 from Jan Hubicka  ---
Hmm, I really do not see symbol definition loop here. As complains already on:

.text   
.globl  callmefirst 
.type   callmefirst, @function  
callmefirst:
.globl  callmesecond
.type   callmesecond, @function 
callmesecond:   
jmp callmealias.lto_priv.0  
.weakrefcallmealias.lto_priv.0,callmesecond 

in my reading callmealias.lto_priv.0 is declared as alias of callmesecond and
the jmp should weakrefly bind to it.

Jakub, why this is refused?

[Bug c++/69253] [6 Regression] ICE in cxx_incomplete_type_diagnostic initializing a flexible array member with empty string

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01325.html

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

  Component|lto |target

--- Comment #3 from Jan Hubicka  ---
OK, this looks more like target issue  so I am changing component. flag_pic is
a global option and it is merged by the lto wrapper and corrected based on the
linker output. Because static executable is built, flag_pic should be 0. 

Targets must be ready for -fPIC being different at compile time and link time
and ought to honor the link time setting...

[Bug c++/69253] [6 Regression] ICE in cxx_incomplete_type_diagnostic initializing a flexible array member with empty string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[6 Regression] g++ ICE at   |[6 Regression] ICE in
   |-O0 on x86_64-linux-gnu in  |cxx_incomplete_type_diagnos
   |"cxx_incomplete_type_diagno |tic initializing a flexible
   |stic"   |array member with empty
   ||string
  Known to fail||6.0

--- Comment #3 from Martin Sebor  ---
Oddly, the following slightly modified test case is accepted and doesn't ICE:

struct A { char i, a []; };

void foo () {
(struct A){ 1, "" };
}

[Bug tree-optimization/69320] [6 Regression] wrong code generation at -O2 and higher

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law  ---
I've backtested against all 4 duplicates and my change fixes all of them.

[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #15 from Jakub Jelinek  ---
Created attachment 37389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37389&action=edit
gcc6-pr65779.patch

Untested fix.

[Bug tree-optimization/69326] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Similarly.  Confirmed as a dup of 69320.  My pending fix for 69320 fixes this
as well.

[Bug tree-optimization/69325] [6 Regression] wrong code at -O3 on x86-64-linux-gnu (in 32- and 64-bit modes)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Confirmed.  Same underlying issue as 69320.  Better testcase than 69320 though.

[Bug tree-optimization/69320] [6 Regression] wrong code generation at -O2 and higher

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
Jakub.  I'll certainly backtest against the referenced BZs

While the fix is trivial, I'm seriously considering just turning the
exploitation of ranges off for gcc-6.  It didn't help as much as I had wanted
in the path splitting bits, so it's not terribly important for this release.

[Bug lto/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
... and in case anyone is curious, with -fuse-linker-plugin we inline the
memcpys as we work out the block size. This is why they pass.

[Bug lto/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #10 from Jan Hubicka  ---
OK, this reproduces for me.  We get:
Merging nodes for my_memcpy. Candidates:
my_memcpy/4 (my_memcpy) @0x76cc7450
  Type: function definition analyzed
  Visibility: force_output externally_visible public
  next sharing asm name: 36
  References: 
  Referring: 
  Read from file: memops-asm-lib.o
  First run: 0
  Function flags:
  Called by: 
  Calls: 
*my_memcpy/36 (memcpy) @0x76cc9a10
  Type: function
  Visibility: external public
  next sharing asm name: 35
  previous sharing asm name: 4
  References: 
  Referring: 
  Read from file: memops-asm.o
  First run: 0
  Function flags:
  Called by: main_test/31 (1.00 per call) 
  Calls: 
*my_memcpy/35 (__builtin_memcpy) @0x76cc9b80
  Type: function
  Visibility: external public
  previous sharing asm name: 36
  References: 
  Referring: 
  Read from file: memops-asm.o
  First run: 0
  Function flags:
  Called by: main_test/31 (1.00 per call) 
  Calls: 
Not merging decls; DECL_BUILT_IN mismatch
Not merging decls; DECL_BUILT_IN mismatch

which is expected, one memcpy and __builtin_memcpy are builtins while my_memcpy
is not.

Now at ltrans time we have:

memcpy/8 (memcpy) @0x76ccb450   
  Type: function definition analyzed
  Visibility: externally_visible public 
  References: inside_main/0 (read)  
  Referring:
  Read from file: oo.ltrans0.o  
  First run: 0  
  Function flags:   
  Called by:
  Calls: abort/13

i.e. unused memcpy and 

my_memcpy/4 (my_memcpy) @0x76cc1e60 
  Type: function definition analyzed
  Visibility: force_output externally_visible public
  References:   
  Referring: *my_memcpy/36 (alias)  
  Read from file: oo.ltrans0.o  
  First run: 0  
  Function flags: nonfreeing_fn 
  Called by:
  Calls:
*my_memcpy/36 (memcpy) @0x76cc1cf0  
  Type: function definition analyzed alias transparent_alias
  Visibility: externally_visible external public
  References: my_memcpy/4 (alias)   
  Referring:
  Read from file: oo.ltrans0.o  
  First run: 0  
  Function flags:   
  Called by: main_test/31 (1.00 per call) main_test/31 (1.00 per call)  
  Calls:
i.e. used my_memcpy

Then we get to:
(gdb) bt
#0  expand_builtin_memcpy_args (dest=0x76923fe0, src=0x76923ca0,
len=0x76918b88, target=target@entry=0x769391e0,
exp=exp@entry=0x7692eab0)
at ../../gcc/builtins.c:2904
#1  0x005db286 in expand_builtin_memcpy (target=0x769391e0,
exp=0x7692eab0) at ../../gcc/builtins.c:2991
#2  expand_builtin (exp=0x7692eab0, target=0x769391e0, subtarget=0x0,
mode=DImode, ignore=0) at ../../gcc/builtins.c:5963
#3  0x006c7bf4 in expand_expr_real_1 (exp=0x7692eab0,
target=, tmode=DImode, modifier=EXPAND_NORMAL,
alt_rtl=, 
inner_reference_p=inner_reference_p@entry=false) at ../../gcc/expr.c:10563
#4  0x006c94a9 in expand_expr_real (exp=exp@entry=0x7692eab0,
target=, tmode=,
modifier=modifier@entry=EXPAND_NORMAL, 
alt_rtl=alt_rtl@entry=0x7fffe2b0,
inner_reference_p=inner_reference_p@entry=false) at ../../gcc/expr.c:7947
#5  0x006d070a in store_expr_with_bounds (exp=exp@entry=0x7692eab0,
target=target@entry=0x769391e0, call_param_p=call_param_p@entry=0, 
nontemporal=nontemporal@entry=false, reverse=reverse@entry=false,
btarget=btarget@entry=0x76918bd0) at ../../gcc/expr.c:5

[Bug c++/69338] incorrect ctor initialization of a flexible array member

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Another test case (derived from the test case in bug 69253), this one even
shows a -Warray-bounds warning with -O2.  With 69253 fixed (and the test case
still accepted), 6.0 also aborts but doesn't print the -Warray-bounds warning.

$ ~/bin/gcc-5.1.0/bin/g++ -O2 -Wall -Wextra -Wpedantic -fpermissive z.c &&
./a.out
z.c:1:22: warning: ISO C++ forbids zero-size array ‘a’ [-Wpedantic]
 struct A { char n, a[]; };
  ^
z.c: In function ‘int main()’:
z.c:11:37: warning: ISO C++ forbids compound-literals [-Wpedantic]
 int a0 = ((struct A){ 1, "" }).a[0];
 ^
z.c:11:37: warning: initializer-string for array of chars is too long
[-fpermissive]
z.c:11:43: warning: array subscript is above array bounds [-Warray-bounds]
 int a0 = ((struct A){ 1, "" }).a[0];
   ^
12345678
Aborted (core dumped)


$ /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc++ -O2 z.c
&& ./a.out
z.c: In function ‘int main()’:
z.c:11:37: warning: ISO C++ forbids compound-literals [-Wpedantic]
 int a0 = ((struct A){ 1, "" }).a[0];
 ^

z.c:11:37: warning: initialization of a flexible array member [-Wpedantic]
12345678
Aborted (core dumped)

[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
The following has even chance to work :)

Index: cgraph.c
===
--- cgraph.c(revision 232466)
+++ cgraph.c(working copy)
@@ -3305,10 +3295,12 @@ cgraph_node::get_untransformed_body (voi
   size_t len;
   tree decl = this->decl;

-  if (DECL_RESULT (decl))
+  /* Check if body is already there.  Either we have gimple body or
+ the function is thunk and in that case we set DECL_ARGUMENTS.  */
+  if (DECL_ARGUMENTS (decl) || gimple_has_body_p (decl))
 return false;

-  gcc_assert (in_lto_p);
+  gcc_assert (in_lto_p && !DECL_RESULT (decl));

   timevar_push (TV_IPA_LTO_GIMPLE_IN);

[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
The problem seems to be that cgraph_node::get_untransformed_body checks
presence of body by DECL_RESULT which is NULL for thunks. Rest of places seems
to check for DECL_ARGUMENTS.

I am testing:
Index: cgraph.c
===
--- cgraph.c(revision 232466)
+++ cgraph.c(working copy)
@@ -3305,10 +3295,11 @@ cgraph_node::get_untransformed_body (voi
   size_t len;
   tree decl = this->decl;

-  if (DECL_RESULT (decl))
+  /* Check if body is already there.  */
+  if (!DECL_ARGUMENTS (decl))
 return false;

-  gcc_assert (in_lto_p);
+  gcc_assert (in_lto_p && !DECL_RESULT (decl))

   timevar_push (TV_IPA_LTO_GIMPLE_IN);

[Bug lto/69136] [6 Regression] ICE in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c:991

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Aha, it is abstract decl.  I am testing:

Index: ../../gcc/lto/lto-symtab.c
===
--- ../../gcc/lto/lto-symtab.c  (revision 232466)
+++ ../../gcc/lto/lto-symtab.c  (working copy)
@@ -987,6 +1008,8 @@ lto_symtab_merge_symbols (void)
 tree
 lto_symtab_prevailing_virtual_decl (tree decl)
 {
+  if (DECL_ABSTRACT_P (decl))
+return decl;
   gcc_checking_assert (!type_in_anonymous_namespace_p (DECL_CONTEXT (decl))
   && DECL_ASSEMBLER_NAME_SET_P (decl));

[Bug lto/69136] [6 Regression] ICE in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c:991

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Hmm, we have:
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 structural equality method basetype

arg-types 
chain 
chain 
nothrow public private abstract external virtual QI file
/aux/hubicka/skia.ii line 4 col 1 align 16 context >

(gdb) p decl->decl_with_vis.assembler_name
$2 = (tree) 0x0

so it seems that the decl was not seen by free_lang_data but still leaked into
the stream.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #219 from Jan Hubicka  ---
devirtualization issue is now fixed, so we are down to -fno-lifetime-dse.

[Bug lto/61886] [4.9/5/6 Regression] LTO breaks fread with _FORTIFY_SOURCE=2

[hubicka at gcc dot gnu.org]

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

--- Comment #57 from Jan Hubicka  ---
The alias-2.c should be now fixed on targets with anchors.

[Bug ipa/62051] [4.9/5/6 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka  ---
Created attachment 37388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37388&action=edit
patch

Hi,
this patch adds the logic to gimple-fold.c which makes the offending dtor
non-refeable.  It is bit uglier than I hoped for.  The reason is that the dtor
itself is COMDAT so it seems perfectly OK to refer it since we can provide the
body, but the body itself refers to vtable that is not output in the unit.

The patch simply prohibits references to all COMDAT and EXTERN methods and
vtables of types with visibility attributes which will prevent optimizing of
many inlines i.e. in libstdc++.

It still seem to me that the the testcase is sort of invalid because it provide
inline body for the dtor. Can we think of better solution (perhaps validating
comdats before using them and checking if symbols they refer to are referable)?

[Bug testsuite/69181] multiline.exp does not handle conditional compilation

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed as of r232535; marking as resolved.

[Bug middle-end/66877] [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_over_widening_pattern: detected" 2

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #3 from Nick Clifton  ---
Created attachment 37387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37387&action=edit
Vectorizer dump

Hi Richard,

  Here is a dump from a failing testcase.  This was from a toolchain configured
as --target=arm-eabi built using today's FSF mainline sources.

Cheers
  Nick

[Bug testsuite/69181] multiline.exp does not handle conditional compilation

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Mon Jan 18 17:26:58 2016
New Revision: 232535

URL: https://gcc.gnu.org/viewcvs?rev=232535&root=gcc&view=rev
Log:
PR testsuite/69181: ensure expected multiline outputs is cleared per-test

gcc/testsuite/ChangeLog:
PR testsuite/69181
* gcc.dg/pr69181-1.c: New test file.
* gcc.dg/pr69181-2.c: New test file.
* lib/gcc-dg.exp (dg-test): Consolidate post-test cleanup of
globals by moving it to...
(cleanup-after-saved-dg-test): ...this new function.  Add
"global additional_sources_used".  Add reset of global
multiline_expected_outputs to the empty list.
* lib/multiline.exp (_multiline_expected_outputs): Rename this
global to...
(multiline_expected_outputs): ...this, and updated comments to
note that it is modified from gcc-dg.exp.
(dg-end-multiline-output): Update for the above renaming.
(handle-multiline-outputs): Likewise.  Remove the clearing
of the expected outputs to the empty list.


Added:
trunk/gcc/testsuite/gcc.dg/pr69181-1.c
trunk/gcc/testsuite/gcc.dg/pr69181-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/gcc-dg.exp
trunk/gcc/testsuite/lib/multiline.exp

[Bug target/69345] [6 Regression] 459.GemsFDTD regression

[afomin.mailbox at gmail dot com]

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

--- Comment #3 from Alexander Fomin  ---
Looks like it's r232401.

[Bug libstdc++/60637] --fast-math breaks std::signbit function

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 18 17:15:42 2016
New Revision: 232534

URL: https://gcc.gnu.org/viewcvs?rev=232534&root=gcc&view=rev
Log:
Add test for PR 60637

PR libstdc++/60637
* testsuite/26_numerics/headers/cmath/60637.cc: Add test.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/60637.cc
Modified:
trunk/libstdc++-v3/ChangeLog

[Bug ipa/68148] Devirtualization only applies to last of multiple successive calls

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #6 from James Greenhalgh  ---
This fix also fixed an ICE on ARM targets:

bug.cpp:23:1: internal compiler error: in get_untransformed_body, at
cgraph.c:3311
 }
 ^

0x8dc245 cgraph_node::get_untransformed_body()
.../gcc/cgraph.c:3311
0x8e79bd cgraph_node::expand()
.../gcc/cgraphunit.c:1941
0x8e9413 expand_all_functions
.../gcc/cgraphunit.c:2107
0x8e9413 symbol_table::compile()
...gcc/cgraphunit.c:2463
0x8eb56f symbol_table::finalize_compilation_unit()
.../gcc/cgraphunit.c:2553

The testcase for that looked like:

class B
{
  public:
virtual void a (int *x) = 0;
virtual void b (int *x) = 0;
};

class Mouseintdapter : public virtual B
{
  void a (int *x) {}
  void b (int *x) {}
};

B* collection;

void foo (int *x)
{
  collection->a(x);
}
void bar (int *x)
{
  collection->b(x);
}

And would fail at -O2 for most ARM target flag combinations I tried.

[Bug target/67895] Wrong assembly: incorrect rounding/SAE specifier position

[afomin at gcc dot gnu.org]

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

--- Comment #3 from afomin at gcc dot gnu.org ---
Author: afomin
Date: Mon Jan 18 17:09:06 2016
New Revision: 232533

URL: https://gcc.gnu.org/viewcvs?rev=232533&root=gcc&view=rev
Log:
Backport to mainline
2015-10-09  Alexander Fomin  

gcc/

PR target/67895
* config/i386/sse.md (define_insn "sse_cvtsi2ss"):
Adjust embedded rounding/SAE specifier position.
(define_insn "sse_cvtsi2ssq"): Likewise.
(define_insn "cvtusi232"): Likewise.
(define_insn "cvtusi264"): Likewise.
(define_insn "sse2_cvtsi2sdq"): Likewise.
(define_insn "avx512dq_rangep"):
Likewise.
(define_insn "avx512dq_ranges"): Likewise.

gcc/testsuite

PR target/67895
* gcc.target/i386/avx512dq-vrangepd-1.c: Adjust.
* gcc.target/i386/avx512dq-vrangeps-1.c: Likewise.
* gcc.target/i386/avx512dq-vrangesd-1.c: Likewise.
* gcc.target/i386/avx512dq-vrangess-1.c: Likewise.
* gcc.target/i386/avx512f-vcvtsi2sd64-1.c: Likewise.
* gcc.target/i386/avx512f-vcvtsi2ss-1.c: Likewise.
* gcc.target/i386/avx512f-vcvtsi2ss64-1.c: Likewise.
* gcc.target/i386/avx512f-vcvtusi2sd64-1.c: Likewise.
* gcc.target/i386/avx512f-vcvtusi2ss-1.c: Likewise.
* gcc.target/i386/avx512f-vcvtusi2ss64-1.c: Likewise.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/sse.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512dq-vrangepd-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512dq-vrangeps-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512dq-vrangesd-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512dq-vrangess-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512f-vcvtsi2sd64-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512f-vcvtsi2ss-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512f-vcvtsi2ss64-1.c
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512f-vcvtusi2sd64-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512f-vcvtusi2ss-1.c
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512f-vcvtusi2ss64-1.c

[Bug libstdc++/60637] --fast-math breaks std::signbit function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #10 from Jonathan Wakely  ---
Fixed for 4.9.4 and 5.4

[Bug c++/69348] New: alias declarations can not be used inside qualifiers of declarators

[vanyacpp at gmail dot com]

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

Bug ID: 69348
   Summary: alias declarations can not be used inside qualifiers
of declarators
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

GCC shows error on this code. The code works correctly on clang and MSVC.

template 
struct X {
int foo();
};

template 
using foo2 = X;

template 
int foo2::foo()
{
}

error: invalid use of incomplete type 'struct X'

[Bug middle-end/69347] [6 regression] excessive compile time with -O2

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-18
 CC||trippels at gcc dot gnu.org
  Component|c   |middle-end
Summary|excessive compile time with |[6 regression] excessive
   |-O2 |compile time with -O2
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
fsm_find_thread_path() is the culprit, adding CC.

[Bug c/69347] New: excessive compile time with -O2

[dcb314 at hotmail dot com]

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

Bug ID: 69347
   Summary: excessive compile time with -O2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 37386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37386&action=edit
gzipped C source code

The attached code, when compiled by gcc 5.3.1 and flag -O2, takes 32 seconds.

With gcc trunk dated 20160117 and flag -O2, it takes 19 minutes.

Some 36 times longer is somewhat surprising.

[Bug libstdc++/60637] --fast-math breaks std::signbit function

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 18 16:28:48 2016
New Revision: 232532

URL: https://gcc.gnu.org/viewcvs?rev=232532&root=gcc&view=rev
Log:
Fix C++98 std::signbit

PR libstdc++/60637
* include/c_global/cmath (signbit) [__cplusplus < 201103L]: Use
__builtin_signbitf or __builtin_signbitl as appropriate.
* testsuite/26_numerics/headers/cmath/60637.cc: New.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/26_numerics/headers/cmath/60637.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/c_global/cmath

[Bug libstdc++/60637] --fast-math breaks std::signbit function

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 18 16:28:16 2016
New Revision: 232531

URL: https://gcc.gnu.org/viewcvs?rev=232531&root=gcc&view=rev
Log:
Fix C++98 std::signbit

PR libstdc++/60637
* include/c_global/cmath (signbit) [__cplusplus < 201103L]: Use
__builtin_signbitf or __builtin_signbitl as appropriate.
* testsuite/26_numerics/headers/cmath/60637.cc: New.

Added:
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/26_numerics/headers/cmath/60637.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/c_global/cmath

[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Daniel Richard G. from comment #8)
> First, GCC can't find its own runtime library when linking programs:
> 
> /usr/bin/ld: cannot find -lgcc_s

That's Bug 35248, it's a problem with --enable-version-specific-runtime-libs

> I can specify -L$(PREFIX)/lib/gcc/x86_64-unknown-linux-gnu/lib64 manually,
> and that allows things to link. But then, unless I futz with
> ld.so.conf/LD_LIBRARY_PATH, the resulting executable uses the wrong instance
> of libgcc/libstdc++:

Yes, that's how linking works.

https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #21 from Uroš Bizjak  ---
Fixed.

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[uros at gcc dot gnu.org]

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

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jan 18 16:19:53 2016
New Revision: 232528

URL: https://gcc.gnu.org/viewcvs?rev=232528&root=gcc&view=rev
Log:
Backport from mainline
2016-01-07  Uros Bizjak  

PR target/69140
* config/i386/i386.c (ix86_frame_pointer_required): Enable
frame pointer for TARGET_64BIT_MS_ABI when stack is misaligned.

testsuite/ChangeLog:

Backport from mainline
2016-01-06  Uros Bizjak  

PR target/69140
* gcc.target/i386/pr69140.c: New test


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr69140.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/60743] build/genautomata uses 700 MB memory for ARM

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #12 from ktkachov at gcc dot gnu.org ---
Seems the division reservations on the other automata still cause too much
state space explosion.
Perhaps reducing the reservation durations on the division reservations would
help.

Adding the xgene1.md description for GCC 5 must have exacerbated this.

[Bug bootstrap/60743] build/genautomata uses 700 MB memory for ARM

[tyrel at kulshanconcepts dot com]

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

Tyrel Haveman  changed:

   What|Removed |Added

 CC||tyrel at kulshanconcepts dot 
com

--- Comment #11 from Tyrel Haveman  ---
Hello -- I'm building GCC 5.3.0 and I'm seeing this same issue. Has there been
a regression?

build/genautomata is using over 850 MB when building ARM and gets killed with
Error 137.

I'm building with target arm-non-eabi on x86_64-linux-gnu.

[Bug lto/69003] [4.9/5 Regression] Undefined reference with gcc -r incremental linking

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression]|[4.9/5 Regression]
   |Undefined reference with|Undefined reference with
   |gcc -r incremental linking  |gcc -r incremental linking

--- Comment #8 from Jan Hubicka  ---
Fixed on trunk so far.

[Bug lto/69003] [4.9/5/6 Regression] Undefined reference with gcc -r incremental linking

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Mon Jan 18 15:58:06 2016
New Revision: 232525

URL: https://gcc.gnu.org/viewcvs?rev=232525&root=gcc&view=rev
Log:
PR lto/69003
* lto-partition.c (rename_statics): Fix pasto.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-partition.c

[Bug testsuite/69181] multiline.exp does not handle conditional compilation

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Updated patch:
  https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01300.html

[Bug c++/68767] [6 regression] spurious warning: null argument where non-null required

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  ---
Author: jason
Date: Mon Jan 18 15:54:14 2016
New Revision: 232522

URL: https://gcc.gnu.org/viewcvs?rev=232522&root=gcc&view=rev
Log:
PR c++/68767
gcc/c-family/
* c-common.c (check_function_arguments_recurse): Fold the whole
COND_EXPR, not just the condition.
gcc/cp/
* cp-gimplify.c (cp_fold) [COND_EXPR]: Simplify.  Do fold COND_EXPR.
(contains_label_1, contains_label_p): Remove.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wnonnull2.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c

[Bug tree-optimization/69328] [6 Regression] ice in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1379 with -O3

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
This patch works for me:

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 635c797..9d4d286 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -7441,6 +7441,10 @@ vect_is_simple_cond (tree cond, vec_info *vinfo, tree
*comp_vectype)
   && TREE_CODE (rhs) != FIXED_CST)
 return false;

+  if (vectype1 && vectype2
+  && TYPE_VECTOR_SUBPARTS (vectype1) != TYPE_VECTOR_SUBPARTS (vectype2))
+return false;
+
   *comp_vectype = vectype1 ? vectype1 : vectype2;
   return true;
 }
@@ -7544,13 +7548,9 @@ vectorizable_condition (gimple *stmt,
gimple_stmt_iterator *gsi,
   if (!vect_is_simple_use (else_clause, stmt_info->vinfo, &def_stmt, &dt))
 return false;

-  if (VECTOR_BOOLEAN_TYPE_P (comp_vectype))
-{
-  vec_cmp_type = comp_vectype;
-  masked = true;
-}
-  else
-vec_cmp_type = build_same_sized_truth_vector_type (comp_vectype);
+  masked = !COMPARISON_CLASS_P (cond_expr);
+  vec_cmp_type = build_same_sized_truth_vector_type (comp_vectype);
+
   if (vec_cmp_type == NULL_TREE)
 return false;

[Bug fortran/66680] [5 Regression] ICE with openmp, a loop and a type bound procedure

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #10 from Dominique d'Humieres  ---
Test committed on trunk and gcc-5 branch. Closing as FIXED.

[Bug fortran/54070] [4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[pault at gcc dot gnu.org]

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

--- Comment #32 from Paul Thomas  ---
(In reply to neil.n.carlson from comment #31)
> Sorry, ignore the example of comment 30.  I had already reported this in PR
> 67564 (not a duplicate of this one).  I'm getting old ...

Thanks for your appreciation of my efforts!

I was going to attack some of the remaining deferred character issues after a
spell of regression fixing.

I have taken note of PR67564 and will give it a poke around tonight.

Best regards

Paul

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #2)
> Works for me but
> https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01237.html still has it.
> 
> Maybe some as feature stuff?  Tom, what target did you reproduce on?

I'm able to reproduce this on Fedora 23 using -fno-use-linker-plugin:

$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O2 -flto
-fno-use-linker-plugin -c attr-weakref-1_0.c 

$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O2 -flto
-fno-use-linker-plugin -c attr-weakref-1_1.c 

$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O2 -flto
-fno-use-linker-plugin -c attr-weakref-1_2.c 

$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O2 -flto
-fno-use-linker-plugin attr-weakref-1_0.o attr-weakref-1_1.o attr-weakref-1_2.o 
/tmp/ccydxp6I.s: Assembler messages:
/tmp/ccydxp6I.s: Error: symbol definition loop encountered at
`callmealias.lto_priv.1'
/tmp/ccydxp6I.s: Error: symbol definition loop encountered at
`callmealias.lto_priv.0'
lto-wrapper: fatal error: /ssd/uros/gcc-build/gcc/xgcc returned 1 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.

(The compilation works OK w/o -fno-use-linker-plugin.)

[Bug target/69305] [5/6 Regression] wrong code with -O and int128 @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #9 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > The patterns are just weird.
> 
> All that comes from the addti3 expander in aarch64.md
> If I delete it the testcase doesn't abort.
> I'll have a closer look there.

Every approach I've tried to implement addti3 properly (that is, comparing (a +
b) u< a instead of (a + b) u>= 0) doesn't give better code than 4.9 which
didn't have the custom expanders.

Richard, you added these expanders. Any ideas on how to implement them properly
and better than the fallback?
Or should we just delete them?

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[nix at esperi dot org.uk]

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

--- Comment #5 from Nix  ---
I didn't think of that (I try to forget that fixincludes exists because it
gives me nightmares). But much though I hate fixincludes, this sort of fix (to
headers for an obsolete program which will by definition never be fixed) is
more or less exactly what it was designed for, and seems a perfect fit for this
case. The question is whether further adjustments are needed to compensate for
the removal of ... I'll do some experimentation.

[Bug target/47122] vax-*-openbsd* configuration purports to require openbsd-pthread.h

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #3 from Bernd Schmidt  ---
Can this be closed?

[Bug fortran/54070] [4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[neil.n.carlson at gmail dot com]

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

--- Comment #31 from neil.n.carlson at gmail dot com ---
Sorry, ignore the example of comment 30.  I had already reported this in PR
67564 (not a duplicate of this one).  I'm getting old ...

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #3 from Igor Zamyatin  ---
(In reply to amker from comment #2)
> It's my change, I will look into it.

Any plans on this?

[Bug tree-optimization/69336] Constant value not detected

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
That looks reasonable, AFAICT get_ref_base_and_extent will deal with anything
that is handled_component_p. The same patch enables the optimization on
aarch64, with appropriate --param sra-max-scalarization-size-Ospeed to pull the
constant-pool entry in.

[Bug fortran/54070] [4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[neil.n.carlson at gmail dot com]

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

--- Comment #30 from neil.n.carlson at gmail dot com ---
Paul, you've done a lot of great work here (a huge thanks!) and I can confirm
that many of my deferred-length character issues seem to be resolved now with
the trunk (r232457, 1/15/2016).  I'm uncertain though whether you consider this
PR resolved or if you are still working on it (there were lots of examples in
PRs marked as duplicates).  I still have at least one remaining issue with this
trunk version:

class(*), allocatable :: x(:)
allocate(x, source=['foo','bar'])
end

Compiles fine, but produces a run time seg fault:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7F85F60F5517
#1  0x7F85F60F5B5E
#2  0x7F85F55F695F
#3  0x7F85F56507ED
#4  0x400932 in __copy_character_1.3416 at bug.f90:?
#5  0x400B91 in MAIN__ at bug.f90:?
Segmentation fault (core dumped)

Should I open another PR for this?

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #30 from The Written Word  
---
(In reply to The Written Word from comment #29)
> (In reply to Alexander from comment #28)
> > this one file should recompile with -O1 optimization
> 
> Thanks. I rebuilt with charset.c with -O1 and it compiled. I resumed the
> build and the compile now fails with:
> /opt/build/china/gcc-4.9.3/.obj/./prev-gcc/xg++
> -B/opt/build/china/gcc-4.9.3/.obj/./prev-gcc/
> -B/opt/build/gcc49/ia64-hp-hpux11.31/bin/ -nostdinc++
> -B/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.
> libs
> -B/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/
> libsupc++/.libs 
> -I/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/
> include/ia64-hp-hpux11.31 
> -I/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/
> include  -I/opt/build/china/gcc-4.9.3/libstdc++-v3/libsupc++
> -L/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.
> libs
> -L/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/
> libsupc++/.libs -c  -DUSE_LIBUNWIND_EXCEPTIONS -DIN_GCC_FRONTEND -g -O2
> -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
> -DHAVE_CONFIG_H -I. -Ifortran -I/opt/build/china/gcc-4.9.3/gcc
> -I/opt/build/china/gcc-4.9.3/gcc/fortran
> -I/opt/build/china/gcc-4.9.3/gcc/../include -I./../intl
> -I/opt/build/china/gcc-4.9.3/gcc/../libcpp/include
> -I/opt/TWWfsw/libgmp51/include -I/opt/TWWfsw/libmpfr31/include
> -I/opt/TWWfsw/libmpc10/include 
> -I/opt/build/china/gcc-4.9.3/gcc/../libdecnumber
> -I/opt/build/china/gcc-4.9.3/gcc/../libdecnumber/dpd -I../libdecnumber
> -I/opt/build/china/gcc-4.9.3/gcc/../libbacktrace-o fortran/scanner.o -MT
> fortran/scanner.o -MMD -MP -MF fortran/.deps/scanner.TPo
> /opt/build/china/gcc-4.9.3/gcc/fortran/scanner.c
> /opt/build/china/gcc-4.9.3/gcc/fortran/scanner.c: In function 'const char*
> gfc_read_orig_filename(const char*, const char**)':
> /opt/build/china/gcc-4.9.3/gcc/fortran/scanner.c:2220:1: internal compiler
> error: in plus_constant, at explow.c:87
>  }
>  ^

Rebuilding with -O0 or with no optimization specified worked around this. Is
that what others have done?

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #29 from The Written Word  
---
(In reply to Alexander from comment #28)
> this one file should recompile with -O1 optimization

Thanks. I rebuilt with charset.c with -O1 and it compiled. I resumed the build
and the compile now fails with:
/opt/build/china/gcc-4.9.3/.obj/./prev-gcc/xg++
-B/opt/build/china/gcc-4.9.3/.obj/./prev-gcc/
-B/opt/build/gcc49/ia64-hp-hpux11.31/bin/ -nostdinc++
-B/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs
-B/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs

-I/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31
 -I/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/include 
-I/opt/build/china/gcc-4.9.3/libstdc++-v3/libsupc++
-L/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-4.9.3/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs
-c  -DUSE_LIBUNWIND_EXCEPTIONS -DIN_GCC_FRONTEND -g -O2 -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Ifortran
-I/opt/build/china/gcc-4.9.3/gcc -I/opt/build/china/gcc-4.9.3/gcc/fortran
-I/opt/build/china/gcc-4.9.3/gcc/../include -I./../intl
-I/opt/build/china/gcc-4.9.3/gcc/../libcpp/include
-I/opt/TWWfsw/libgmp51/include -I/opt/TWWfsw/libmpfr31/include
-I/opt/TWWfsw/libmpc10/include 
-I/opt/build/china/gcc-4.9.3/gcc/../libdecnumber
-I/opt/build/china/gcc-4.9.3/gcc/../libdecnumber/dpd -I../libdecnumber
-I/opt/build/china/gcc-4.9.3/gcc/../libbacktrace-o fortran/scanner.o -MT
fortran/scanner.o -MMD -MP -MF fortran/.deps/scanner.TPo
/opt/build/china/gcc-4.9.3/gcc/fortran/scanner.c
/opt/build/china/gcc-4.9.3/gcc/fortran/scanner.c: In function 'const char*
gfc_read_orig_filename(const char*, const char**)':
/opt/build/china/gcc-4.9.3/gcc/fortran/scanner.c:2220:1: internal compiler
error: in plus_constant, at explow.c:87
 }
 ^

[Bug target/69345] [6 Regression] 459.GemsFDTD regression

[afomin.mailbox at gmail dot com]

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

Alexander Fomin  changed:

   What|Removed |Added

 CC||afomin.mailbox at gmail dot com

--- Comment #2 from Alexander Fomin  ---
I can confirm we've also seen it on Core i7.
Now bisecting.

[Bug target/69345] [6 Regression] 459.GemsFDTD regression

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
candidates are r232435 and r232401 I think (which would be both mine).

[Bug tree-optimization/69297] [6 Regression] Performance regression after r230020

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69297] [6 Regression] Performance regression after r230020

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 18 14:25:56 2016
New Revision: 232519

URL: https://gcc.gnu.org/viewcvs?rev=232519&root=gcc&view=rev
Log:
2016-01-18  Richard Biener  

PR tree-optimization/69297
* tree-vect-slp.c (vect_bb_slp_scalar_cost): Count each scalar
stmt at most once.
(vect_bb_vectorization_profitable_p): Clear visited flag again.

* gcc.dg/vect/costmodel/x86_64/costmodel-pr69297.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr69297.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/69328] [6 Regression] ice in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1379 with -O3

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
(In reply to Richard Biener from comment #3)
> > ./cc1 -quiet t.c -O3
> t.c: In function ‘fn1’:
> t.c:2:6: internal compiler error: in vector_compare_rtx, at optabs.c:5290
>  void fn1() {
>   ^~~
> 
> 0xca84f2 vector_compare_rtx
> /space/rguenther/src/svn/trunk3/gcc/optabs.c:5290
> 0xca979f expand_vec_cond_expr(tree_node*, tree_node*, tree_node*,
> tree_node*, rtx_def*)
> /space/rguenther/src/svn/trunk3/gcc/optabs.c:5612
> 
> sth else is wrong here.

Looks like vectype1 and vectype2 in vect_is_simple_cond have different number
of elements and we don't catch it.

[Bug middle-end/68542] [6 Regression] 10% 481.wrf performance regression

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Mon Jan 18 14:14:35 2016
New Revision: 232518

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

2016-01-18  Yuri Rumyantsev  

PR middle-end/68542
* fold-const.c (fold_binary_op_with_conditional_arg): Bail out for case
of mixind vector and scalar types.
(fold_relational_const): Add handling of vector
comparison with boolean result.
* tree-cfg.c (verify_gimple_comparison): Add argument CODE, allow
comparison of vector operands with boolean result for EQ/NE only.
(verify_gimple_assign_binary): Adjust call for
verify_gimple_comparison.
(verify_gimple_cond): Likewise.
* tree-vrp.c (extract_code_and_val_from_cond_with_ops): Modify check on
valid type of VAL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-vrp.c

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So shouldn't we just fixinclude the bad stdc-predef.h headers and resolve this
that way?  IMNSHO stdc-predef.h really shouldn't include anything.

[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

[Bug target/69305] [5/6 Regression] wrong code with -O and int128 @ aarch64

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> The patterns are just weird.

All that comes from the addti3 expander in aarch64.md
If I delete it the testcase doesn't abort.
I'll have a closer look there.

[Bug target/69305] [5/6 Regression] wrong code with -O and int128 @ aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The patterns are just weird.
(insn 10 7 11 2 (parallel [
(set (reg:CC_NZ 66 cc)
(compare:CC_NZ (plus:DI (reg:DI 79)
(reg:DI 85 [ x ]))
(const_int 0 [0])))
(set (reg:DI 81)
(plus:DI (reg:DI 79)
(reg:DI 85 [ x ])))
]) pr69305-1.c:5 100 {adddi3_compare0}
 (expr_list:REG_DEAD (reg:DI 85 [ x ])
(expr_list:REG_DEAD (reg:DI 79)
(nil
(insn 11 10 25 2 (set (reg:DI 82)
(plus:DI (geu:DI (reg:CC 66 cc)
(const_int 0 [0]))
(reg:DI 86 [ x+8 ]))) pr69305-1.c:5 452 {*csinc2di_insn}
 (expr_list:REG_DEAD (reg:DI 86 [ x+8 ])
(expr_list:REG_DEAD (reg:CC 66 cc)
(nil
This suggests that that you compare (a + b) cmp 0 and add 1 in the second insn
if (a + b) u>= 0, which is always, while what you are actually interested in is
whether (a + b) u< a (or equivalently (a + b) u< b), i.e. if there is an
overflow in the addition.  E.g. on x86_64 (though, only after split2) it is
represented that way:
(insn 33 13 34 2 (parallel [
(set (reg:CCC 17 flags)
(compare:CCC (plus:DI (reg:DI 0 ax [97])
(reg:DI 38 r9 [orig:90 x ] [90]))
(reg:DI 0 ax [97])))
(set (reg:DI 0 ax [95])
(plus:DI (reg:DI 0 ax [97])
(reg:DI 38 r9 [orig:90 x ] [90])))
]) pr69305-1.c:5 306 {*adddi3_cc_overflow_1}
 (nil))
(insn 34 33 20 2 (parallel [
(set (reg:DI 1 dx [+8 ])
(plus:DI (plus:DI (ltu:DI (reg:CC 17 flags)
(const_int 0 [0]))
(reg:DI 1 dx [+8 ]))
(reg:DI 39 r10 [ x+8 ])))
(clobber (reg:CC 17 flags))
]) pr69305-1.c:5 284 {adddi3_carry}
 (nil))

[Bug target/43052] [4.9/5/6 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #35 from Bernd Schmidt  ---
Closing since PR52171 tracks the other problem.

[Bug sanitizer/67515] crash from ubsan for non-virtual call in initializer list with an invalid vtable

[yury.zaytsev at traveltainment dot de]

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

--- Comment #11 from Yury V. Zaytsev  ---
Hi Roger,

Thank you for the hint! I've tried the solution from the linked ticket, but I'm
still getting the same problem, albeit at a different place in the code (not
sure why?!). In addition I'm still struggling with undefined behaviors in other
parts of boost, like this one: https://svn.boost.org/trac/boost/ticket/11204
... for now I'll try to remove the use of boost::lexical_cast where possible
:-/

Thanks!