[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

--- Comment #8 from Markus Trippelsdorf  ---
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 18740]
ipa_profile_generate_summary () at ../../gcc/gcc/ipa-profile.c:214
214   = h->hvalue.counters [0];
(gdb) bt
#0  ipa_profile_generate_summary () at ../../gcc/gcc/ipa-profile.c:214
#1  0x00a9f197 in execute_ipa_summary_passes (ipa_pass=0x175c300) at
../../gcc/gcc/passes.c:2011
#2  0x00830f94 in ipa_passes () at ../../gcc/gcc/cgraphunit.c:2022
#3  compile () at ../../gcc/gcc/cgraphunit.c:2126
#4  0x008314e5 in finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:2280
#5  0x0062a58f in cp_write_global_declarations () at
../../gcc/gcc/cp/decl2.c:4431
#6  0x00b4763d in compile_file () at ../../gcc/gcc/toplev.c:561
#7  0x00b495b8 in do_compile () at ../../gcc/gcc/toplev.c:1887
#8  toplev_main (argc=16, argv=0x7fffe0b8) at ../../gcc/gcc/toplev.c:1963
#9  0x775eff90 in __libc_start_main () from /lib/libc.so.6
#10 0x0053e021 in _start ()
(gdb) l
209counter 2 is total number of executions.  */
210 if (h->hvalue.counters[2])
211   {
212 struct cgraph_edge * e = cgraph_edge (node,
stmt);
213 e->indirect_info->common_target_id
214   = h->hvalue.counters [0];
215 e->indirect_info->common_target_probability
216   = GCOV_COMPUTE_SCALE (h->hvalue.counters [1],
h->hvalue.counters [2]);
217 if (e->indirect_info->common_target_probability
> REG_BR_PROB_BASE)
218   {
(gdb) p *e
$4 = {
  count = 990, 
  caller = 0x75b62668, 
  callee = 0x75ada148, 
  prev_caller = 0x0, 
  next_caller = 0x75c92f70, 
  prev_callee = 0x0, 
  next_callee = 0x758c0820, 
  call_stmt = 0x75875da8, 
  indirect_info = 0x0, 
  aux = 0x0, 
  inline_failed = CIF_FUNCTION_NOT_CONSIDERED, 
  lto_stmt_uid = 0, 
  frequency = 1000, 
  uid = 769, 
  indirect_inlining_edge = 0, 
  indirect_unknown_callee = 0, 
  call_stmt_cannot_inline_p = 0, 
  can_throw_external = 0, 
  speculative = 0
}

[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470

--- Comment #24 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 16 08:09:05 2013
New Revision: 206009

URL: http://gcc.gnu.org/viewcvs?rev=206009&root=gcc&view=rev
Log:
PR middle-end/58956
PR middle-end/59470
* gimple-walk.h (walk_stmt_load_store_addr_fn): New typedef.
(walk_stmt_load_store_addr_ops, walk_stmt_load_store_ops): Use it
for callback params.
* gimple-walk.c (walk_stmt_load_store_ops): Likewise.
(walk_stmt_load_store_addr_ops): Likewise.  Adjust all callback
calls to supply the gimple operand containing the base tree
as an extra argument.
* tree-ssa-ter.c: Include gimple-walk.h.
(find_ssaname, find_ssaname_in_store): New helper functions.
(find_replaceable_in_bb): For calls or GIMPLE_ASM, only set
same_root_var if USE is used somewhere in the stores of the stmt.
* ipa-prop.c (visit_ref_for_mod_analysis): Remove name of the stmt
argument and ATTRIBUTE_UNUSED, add another unnamed tree argument.
* ipa-pure-const.c (check_load, check_store, check_ipa_load,
check_ipa_store): Likewise.
* gimple.c (gimple_ior_addresses_taken_1, check_loadstore): Likewise.
* ipa-split.c (test_nonssa_use, mark_nonssa_use): Likewise.
(verify_non_ssa_vars, visit_bb): Adjust their callers.
* cfgexpand.c (add_scope_conflicts_1): Use
walk_stmt_load_store_addr_fn type for visit variable.
(visit_op, visit_conflict): Remove name of the stmt
argument and ATTRIBUTE_UNUSED, add another unnamed tree argument.
* tree-sra.c (asm_visit_addr): Likewise.  Remove name of the data
argument and ATTRIBUTE_UNUSED.
* cgraphbuild.c (mark_address, mark_load, mark_store): Add another
unnamed tree argument.
* gimple-ssa-isolate-paths.c (check_loadstore): Likewise.  Remove
ATTRIBUTE_UNUSED from stmt parameter.

* gcc.target/i386/pr59470.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr59470.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/cgraphbuild.c
trunk/gcc/gimple-ssa-isolate-paths.c
trunk/gcc/gimple-walk.c
trunk/gcc/gimple-walk.h
trunk/gcc/gimple.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-pure-const.c
trunk/gcc/ipa-split.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c
trunk/gcc/tree-ssa-ter.c

[Bug middle-end/58956] [4.7 Regression] wrong code at -O1 and above (affecting gcc 4.6 to trunk)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58956

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 16 08:09:05 2013
New Revision: 206009

URL: http://gcc.gnu.org/viewcvs?rev=206009&root=gcc&view=rev
Log:
PR middle-end/58956
PR middle-end/59470
* gimple-walk.h (walk_stmt_load_store_addr_fn): New typedef.
(walk_stmt_load_store_addr_ops, walk_stmt_load_store_ops): Use it
for callback params.
* gimple-walk.c (walk_stmt_load_store_ops): Likewise.
(walk_stmt_load_store_addr_ops): Likewise.  Adjust all callback
calls to supply the gimple operand containing the base tree
as an extra argument.
* tree-ssa-ter.c: Include gimple-walk.h.
(find_ssaname, find_ssaname_in_store): New helper functions.
(find_replaceable_in_bb): For calls or GIMPLE_ASM, only set
same_root_var if USE is used somewhere in the stores of the stmt.
* ipa-prop.c (visit_ref_for_mod_analysis): Remove name of the stmt
argument and ATTRIBUTE_UNUSED, add another unnamed tree argument.
* ipa-pure-const.c (check_load, check_store, check_ipa_load,
check_ipa_store): Likewise.
* gimple.c (gimple_ior_addresses_taken_1, check_loadstore): Likewise.
* ipa-split.c (test_nonssa_use, mark_nonssa_use): Likewise.
(verify_non_ssa_vars, visit_bb): Adjust their callers.
* cfgexpand.c (add_scope_conflicts_1): Use
walk_stmt_load_store_addr_fn type for visit variable.
(visit_op, visit_conflict): Remove name of the stmt
argument and ATTRIBUTE_UNUSED, add another unnamed tree argument.
* tree-sra.c (asm_visit_addr): Likewise.  Remove name of the data
argument and ATTRIBUTE_UNUSED.
* cgraphbuild.c (mark_address, mark_load, mark_store): Add another
unnamed tree argument.
* gimple-ssa-isolate-paths.c (check_loadstore): Likewise.  Remove
ATTRIBUTE_UNUSED from stmt parameter.

* gcc.target/i386/pr59470.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr59470.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/cgraphbuild.c
trunk/gcc/gimple-ssa-isolate-paths.c
trunk/gcc/gimple-walk.c
trunk/gcc/gimple-walk.h
trunk/gcc/gimple.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-pure-const.c
trunk/gcc/ipa-split.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c
trunk/gcc/tree-ssa-ter.c

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

--- Comment #9 from Markus Trippelsdorf  ---
Maybe something like this:

diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
index ef9e24224921..66f87816e1bf 100644
--- a/gcc/ipa-profile.c
+++ b/gcc/ipa-profile.c
@@ -210,6 +210,8 @@ ipa_profile_generate_summary (void)
if (h->hvalue.counters[2])
  {
struct cgraph_edge * e = cgraph_edge (node, stmt);
+   if (e && !e->indirect_unknown_callee)
+ break;
e->indirect_info->common_target_id
  = h->hvalue.counters [0];
e->indirect_info->common_target_probability

Seems to fix Mozilla build untill the next (unrelated) ICE:

/var/tmp/mozilla-central/js/src/vm/Stack.cpp: In member function ‘operator++’:
/var/tmp/mozilla-central/js/src/vm/Stack.cpp:717:1: internal compiler error: in
fixup_reorder_chain, at cfgrtl.c:3739
 }
 ^
0x5b594c fixup_reorder_chain
../../gcc/gcc/cfgrtl.c:3738
0x5b594c cfg_layout_finalize()
../../gcc/gcc/cfgrtl.c:4295
0xd42eb2 duplicate_computed_gotos
../../gcc/gcc/bb-reorder.c:2492
0xd42eb2 execute
../../gcc/gcc/bb-reorder.c:2524
Please submit a full bug report,

[Bug c++/59522] "cc1plus: error: unrecognized command line option ‘-fmy-loop-block’ " is generated when g++ is run but not with cc1plus

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59522

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Bugzilla isn't the right place for these kind of questions, use gcc-help
mailing list.

FWIW, I don't see why it shouldn't work with g++.

[Bug c++/59522] "cc1plus: error: unrecognized command line option ‘-fmy-loop-block’ " is generated when g++ is run but not with cc1plus

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59522

--- Comment #2 from Andrew Pinski  ---
The one thing is your new g++ is it executing your newly build cc1plus?  That
is the main reason why it would fail.  Try add -B . to the command line if you
are still in the build directory.

[Bug c++/59522] "cc1plus: error: unrecognized command line option ‘-fmy-loop-block’ " is generated when g++ is run but not with cc1plus

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59522

--- Comment #3 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #1)
> Bugzilla isn't the right place for these kind of questions, use gcc-help
> mailing list.

Even gcc-help might not be the correct place to ask this question.  gcc@ might
be better since this is a question about modifying gcc rather than using gcc.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #28 from ktkachov at gcc dot gnu.org ---
I'm seeing this on arm-none-eabi now as well:

FAIL: gcc.dg/pr59350.c (internal compiler error)
FAIL: gcc.dg/pr59350.c (test for excess errors)

$TOP/gcc/gcc/testsuite/gcc.dg/pr59350.c: In function 'uDNS_ReceiveMsg':
$TOP/gcc/gcc/testsuite/gcc.dg/pr59350.c:82:1: internal compiler error: in
vt_expand_var_loc_chain, at var-tracking.c:8212
0xc123cb vt_expand_var_loc_chain
$TOP/gcc/gcc/var-tracking.c:8212
0xc123cb vt_expand_var_loc_chain
$TOP/gcc/gcc/var-tracking.c:8190
0xc14a0a vt_expand_loc_callback
$TOP/gcc/gcc/var-tracking.c:8408
0x6b54eb cselib_expand_value_rtx_1
$TOP/gcc/gcc/cselib.c:1684
0x6b681e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
$TOP/gcc/gcc/cselib.c:1531
0xc146a6 vt_expand_loc_callback
$TOP/gcc/gcc/var-tracking.c:8344
0x6b5405 cselib_expand_value_rtx_1
$TOP/gcc/gcc/cselib.c:1649
0x6b681e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
$TOP/gcc/gcc/cselib.c:1531
0xc11f57 vt_expand_var_loc_chain
$TOP/gcc/gcc/var-tracking.c:8246
0xc14a0a vt_expand_loc_callback
$TOP/gcc/gcc/var-tracking.c:8408
0x6b54eb cselib_expand_value_rtx_1
$TOP/gcc/gcc/cselib.c:1684
0x6b681e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
$TOP/gcc/gcc/cselib.c:1531
0xc0dd9f vt_expand_loc
$TOP/gcc/gcc/var-tracking.c:8498
0xc1e669 emit_notes_in_bb
$TOP/gcc/gcc/var-tracking.c:9094
0xc1e669 vt_emit_notes
$TOP/gcc/gcc/var-tracking.c:9431
0xc1f18f variable_tracking_main_1
$TOP/gcc/gcc/var-tracking.c:10292
0xc1f18f variable_tracking_main()
$TOP/gcc/gcc/var-tracking.c:10306
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/56716] during gcc 4.8.0 build on Cygwin: bid128_fma.c:4460:1: internal compiler error: Segmentation fault

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56716

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #12 from Kai Tietz  ---
Reporters didn't commented on backported patches ... I assume that this issue
is fix for 4.8 and current trunk.  At least I couldn't reproduce it anymore.

If issue still exists please open new bug with testcase for reproducing.

[Bug tree-optimization/45685] [4.7/4.8/4.9 Regression] missed conditional move opportunity in loop

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #29 from ktkachov at gcc dot gnu.org ---
Created attachment 31445
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31445&action=edit
Dump from phiopt1 pass on arm

Hi Jeff,

This test now fails on arm. I've attached the dump that I get. We don't do any
conversion on arm now.

[Bug other/46542] GCC 4.7 pending patches meta-bug

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542

Bug 46542 depends on bug 45685, which changed state.

Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity 
in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685

   What|Removed |Added

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

[Bug tree-optimization/45685] [4.7/4.8/4.9 Regression] missed conditional move opportunity in loop

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #30 from ktkachov at gcc dot gnu.org ---
Reopening...

[Bug tree-optimization/42632] [4.5 Regression] unimplemented: inlining failed in call to ‘pskb_trim’: recursive inlining

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42632

Bug 42632 depends on bug 45685, which changed state.

Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity 
in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685

   What|Removed |Added

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

[Bug c++/22007] Stack overflow in g++.dg/eh/cleanup1.C

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22007

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #5 from Kai Tietz  ---
Issue seems to be solved for 32-bit and 64-bit windows on cygwin-host.  I can't
reproduce issue there anymore for 4.9 and 4.8.

Is issue still an issue for 4.7, 4.8, 4.9 for you?

[Bug tree-optimization/41488] IVOpts cannot coalesce multiple induction variables

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Hi Bin,

I'm seeing tree-ssa/scev-7.c failing on arm

[Bug target/55181] [4.7/4.8/4.9 Regression] Expensive shift loop where a bit-testing instruction could be used

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #8 from Oleg Endo  ---
(In reply to Richard Biener from comment #6)
> Note that a bit-test instruction can only be used if the and only feeds a
> comparison against zero.  Not sure how canonical bit-test patterns should
> look like, but combine should be able to work this out, no?  Unless we
> mess things up earlier during generic expansion (which seems to be the
> case)

A single bit test pattern such as (taken from SH)

(define_insn "tstsi_t"
  [(set (reg:SI T_REG)
(eq:SI (and:SI (match_operand:SI 0 "logical_operand" "%z,r")
   (match_operand:SI 1 "logical_operand" "K08,r"))
   (const_int 0)))]

is not enough.  If the second operand is a constant combine will try out
various variations (canonicalized bit extractions) such as zero_extend or

  [(set (reg:SI T_REG)
 (and:SI (not:SI (match_operand:SI 0 "logical_operand" "z"))
 (const_int 1)))]

[Bug libgomp/58756] FAIL: libgomp.c/pr58392.c execution test

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58756

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 16 10:34:28 2013
New Revision: 206011

URL: http://gcc.gnu.org/viewcvs?rev=206011&root=gcc&view=rev
Log:
PR libgomp/58756
* omp-low.c (lower_rec_input_clauses) : For
reductions without placeholder if is_simd, but when not using
GOMP_SIMD* internal calls, also perform the reduction operation
on the outer var rather than simple assignment.

* testsuite/libgomp.c/pr58756.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr58756.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/libgomp/ChangeLog

[Bug libgomp/58756] FAIL: libgomp.c/pr58392.c execution test

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58756

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Should be fixed now.

[Bug ipa/59473] [4.9 Regression] ice in get_class_context with -O3

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59473

--- Comment #4 from Jan Hubicka  ---
Author: hubicka
Date: Mon Dec 16 10:52:48 2013
New Revision: 206012

URL: http://gcc.gnu.org/viewcvs?rev=206012&root=gcc&view=rev
Log:

PR ipa/59473
* ipa-devirt.c (get_class_context): Do not ICE when type is found
at wrong offset.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350

--- Comment #29 from Eric Botcazou  ---
> I'm seeing this on arm-none-eabi now as well:
> 
> FAIL: gcc.dg/pr59350.c (internal compiler error)
> FAIL: gcc.dg/pr59350.c (test for excess errors)
> 
> $TOP/gcc/gcc/testsuite/gcc.dg/pr59350.c: In function 'uDNS_ReceiveMsg':
> $TOP/gcc/gcc/testsuite/gcc.dg/pr59350.c:82:1: internal compiler error: in
> vt_expand_var_loc_chain, at var-tracking.c:8212

The assertion is supposed to be at var-tracking.c:8213 after the patch.

[Bug ipa/59473] [4.9 Regression] ice in get_class_context with -O3

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59473

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
Fixed.

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

--- Comment #10 from Jan Hubicka  ---
Yes, this patch is OK, will you test and commit it?  I will also re-test the
patch that should prevent early passes from missing this optimization.

[Bug testsuite/59524] New: cilk-plus tests are run with --disable-libcilkrts

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59524

Bug ID: 59524
   Summary: cilk-plus tests are run with --disable-libcilkrts
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: octoploid at yandex dot com

The cilk-plus tests are run even with --disable-libcilkrts.

[Bug other/46542] GCC 4.7 pending patches meta-bug

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542

Bug 46542 depends on bug 45685, which changed state.

Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity 
in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685

   What|Removed |Added

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

[Bug tree-optimization/42632] [4.5 Regression] unimplemented: inlining failed in call to ‘pskb_trim’: recursive inlining

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42632

Bug 42632 depends on bug 45685, which changed state.

Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity 
in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685

   What|Removed |Added

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

[Bug rtl-optimization/59511] [4.9 Regression] FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa with -mtune=corei7

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59511

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
One movdqa started appearing with r204212, the second movdqa started appearing
with r204752.  Vlad, can you please have a look?

[Bug tree-optimization/45685] [4.7/4.8/4.9 Regression] missed conditional move opportunity in loop

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #31 from ktkachov at gcc dot gnu.org ---
It seems I just had a weird out-of date tree. It passes on trunk. Sorry for the
noise

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350

--- Comment #30 from ktkachov at gcc dot gnu.org ---
It seems I had some weird tree state. It passes on trunk after doing a clean
build.

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

--- Comment #11 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #10)
> Yes, this patch is OK, will you test and commit it?  I will also re-test the
> patch that should prevent early passes from missing this optimization.

I've tested it on x86_64-pc-linux-gnu.
Please commit it yourself, because I don't have access.
Thanks.

[Bug fortran/59525] New: Inheritance problems

[sarantis.pantazis at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525

Bug ID: 59525
   Summary: Inheritance problems
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sarantis.pantazis at gmail dot com

I have some problems with inheritance.
In particular, I can not allocate an allocatable class variable to a child type
(the extra components are not recognized by the compiler).

Attached is a minimal working example.
The error message is the following:

testInheritance.f08:25.23:
write(*,*) bla%i, bla%j
Error: 'j' at (1) is not a member of the 'mytype' structure

[Bug fortran/59525] Inheritance problems

[sarantis.pantazis at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525

--- Comment #1 from Sarantis Pantazis  ---
Created attachment 31446
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31446&action=edit
Minimal working example

[Bug tree-optimization/59523] ICE on spec2000/176.gcc, 200.sixtrack after r205856 for -march=core-avx2

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59523

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-12-16
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Please provide a testcase.

[Bug fortran/59525] Inheritance problems

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Sarantis Pantazis from comment #0)
> I have some problems with inheritance.

What you describe is not a bug in the gfortran compiler, but in your
understanding of how inheritance works.


> testInheritance.f08:25.23:
> write(*,*) bla%i, bla%j
> Error: 'j' at (1) is not a member of the 'mytype' structure

This error is perfectly fine. Your code is not valid Fortran.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469

--- Comment #19 from Jan Hubicka  ---
> I can't reproduce this.
> What platform is this? What is the command line?

I used x86-64 and you apparently need LTO to trigger it.  I used same
commandline
as in original report
g++ -flto-partition=none -flto -fPIC -shared -fno-rtti -O3 BasicBlock.ii
Function.ii

You may produce object files and that will get you to dataflow earilier.

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

--- Comment #12 from Jan Hubicka  ---
OK, will commit it shortly (after re-testing with break replaced by continue).
You may just ask for write access and write me as garant.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469

--- Comment #20 from Jan Hubicka  ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
> 
> --- Comment #17 from Markus Trippelsdorf  ---
> In the non-lto case one has:
> lib/libLLVMAsmParser.so:
> U
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_

I think this is a bug by itself, since the symbol seems to be nonkeyed comdat
and thus
every unit that use it should define it.

> If I understand you correctly, you say that the undefined symbol
> of lib/libLLVMAsmParser.so is a bug in LLVM.

I think it is eitehr bug in source (LLVM). Most probably becuase
libLLVMAsmParser simply omits inline definition in libLLVMAsmParser.so where it
should not or some sort of bug in C++ visibility logic.

For that we need to figure out how the symbol is defined and used in
lib/libLLVMAsmParser.so

Honza

[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
We do very basic ODR check in ipa-devirt, perhaps we can extend it to handle
this case, too.

But as a fallback we should probably also stop ICEing when things progress to
actual fold (I saw ICEs like this before but they all tracked down to bugs in
devirtualization logic, this is first one that really come from misformed
source code).

[Bug c++/59526] New: [C++11] Defaulted special member functions don't accept noexcept if a member has a non-trivial noexcept operator in the corresponding special member function

[bootsarehax at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59526

Bug ID: 59526
   Summary: [C++11] Defaulted special member functions don't
accept noexcept if a member has a non-trivial noexcept
operator in the corresponding special member function
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bootsarehax at gmail dot com

The following code fails for struct X on gcc 4.8.2 with:

bla.cpp:15:3: error: function ‘X::X()’ defaulted on its first declaration with
an exception-specification that differs from the implicit declaration ‘X::X()’
   X() noexcept = default;

bla.cpp:16:6: error: function ‘X& X::operator=(X&&)’ defaulted on its first
declaration with an exception-specification that differs from the implicit
declaration ‘X& X::operator=(X&&)’
   X& operator=(X&&) noexcept = default;

#include 

template
struct F {
  F() noexcept(b) {}
  F& operator=(F&&) noexcept(b) {return *this;}
};

struct Simple {
  Simple() noexcept {}
  Simple& operator=(Simple&&) noexcept {return *this;}
};

struct X {
  X() noexcept = default;
  X& operator=(X&&) noexcept = default;
  F f;
};
struct X2 {
  X2() /* noexcept */ = default;
  X2& operator=(X2&&) /* noexcept */ = default;
  F f;
};
struct X3 {
  X3() noexcept = default;
  X3& operator=(X3&&) noexcept = default;
  Simple f;
};

static_assert(std::is_nothrow_constructible::value, "");
static_assert(std::is_nothrow_move_assignable::value, "");
static_assert(std::is_nothrow_constructible::value, "");
static_assert(std::is_nothrow_move_assignable::value, "");
static_assert(std::is_nothrow_constructible::value, "");
static_assert(std::is_nothrow_move_assignable::value, "");

X2 shows that a noexcept function is implicitly generated. X3 shows that it is
necessary for the noexcept operator to depend on a template parameter to
trigger this behavior.

[Bug bootstrap/56645] libgcc /configure identifies non-existing /lib/cpp as preprocessor on Mingw

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56645

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz  ---
Hmm, by this report I can't make much out of it.  To see the failure reported
in config.log for this test might be helpful.  I can't reproduce the issue by
building mingw-w64 based toolchain, so it seems to be something specific to
MinGW.org setup...

AFAICS might be the cause for this issue the lack of installed headers/runtime.
As you were using as prefix /mingw/local/, are you sure crt and headers are
installed in /mingw/local/mingw32/include and /mingw/local/mingw32/lib?

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

--- Comment #13 from Jan Hubicka  ---
Author: hubicka
Date: Mon Dec 16 13:37:43 2013
New Revision: 206014

URL: http://gcc.gnu.org/viewcvs?rev=206014&root=gcc&view=rev
Log:
PR ipa/59265
* ipa-profile.c (ipa_profile_generate_summary): Do not ICE when
call is already devirtualized.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-profile.c

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #14 from Jan Hubicka  ---
Fixed. Thank you for testing it.  The Firefox ICE
Seems to fix Mozilla build untill the next (unrelated) ICE:

/var/tmp/mozilla-central/js/src/vm/Stack.cpp: In member function ‘operator++’:
/var/tmp/mozilla-central/js/src/vm/Stack.cpp:717:1: internal compiler error: in
fixup_reorder_chain, at cfgrtl.c:3739
 }
 ^
0x5b594c fixup_reorder_chain
../../gcc/gcc/cfgrtl.c:3738
0x5b594c cfg_layout_finalize()
../../gcc/gcc/cfgrtl.c:4295
0xd42eb2 duplicate_computed_gotos
../../gcc/gcc/bb-reorder.c:2492
0xd42eb2 execute
../../gcc/gcc/bb-reorder.c:2524
Please submit a full bug report,

is apparently related to Tereza's patch enabling -freroder-blocks-and-partition
(and -fno-reorder-blocks-and-partition should be a workaround). Can you,
please, open a new PR for it, if not reported already?

[Bug fortran/54949] [F03] abstract procedure pointers not rejected

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54949

--- Comment #4 from janus at gcc dot gnu.org ---
Both test cases give an ICE at least with 4.6 on upward, but not with 4.4, so
the ICE is technically a regression.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469

--- Comment #21 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #20)
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
> > 
> > --- Comment #17 from Markus Trippelsdorf  ---
> > In the non-lto case one has:
> > lib/libLLVMAsmParser.so:
> > U
> > _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
> 
> I think this is a bug by itself, since the symbol seems to be nonkeyed
> comdat and thus
> every unit that use it should define it.
> 
> > If I understand you correctly, you say that the undefined symbol
> > of lib/libLLVMAsmParser.so is a bug in LLVM.
> 
> I think it is eitehr bug in source (LLVM). Most probably becuase
> libLLVMAsmParser simply omits inline definition in libLLVMAsmParser.so where
> it
> should not or some sort of bug in C++ visibility logic.
> 
> For that we need to figure out how the symbol is defined and used in
> lib/libLLVMAsmParser.so

libLLVMAsmParser.so only uses the declaration:
http://llvm.org/docs/doxygen/html/SymbolTableListTraits_8h_source.html

And not the definition:
http://llvm.org/docs/doxygen/html/SymbolTableListTraitsImpl_8h_source.html

[Bug gcov-profile/59527] New: [4.9 Regression] ICE: in fixup_reorder_chain, at cfgrtl.c:3739 during PGO Firefox build

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527

Bug ID: 59527
   Summary: [4.9 Regression] ICE: in fixup_reorder_chain, at
cfgrtl.c:3739 during PGO Firefox build
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: octoploid at yandex dot com

src % /var/tmp/gcc_test/usr/local/bin/g++ -w -r -nostdlib -o js -flto=4
-fprofile-use -fprofile-correction -march=native -fno-rtti -fno-exceptions
-fno-math-errno -std=gnu++0x -pthread -pipe -O3 Unified_cpp_9.ii
...
/var/tmp/mozilla-central/js/src/vm/Stack.cpp: In member function ‘operator++’:
/var/tmp/mozilla-central/js/src/vm/Stack.cpp:717:1: internal compiler error: in
fixup_reorder_chain, at cfgrtl.c:3739
 }
 ^
0x5b594c fixup_reorder_chain
../../gcc/gcc/cfgrtl.c:3738
0x5b594c cfg_layout_finalize()
../../gcc/gcc/cfgrtl.c:4295
0xd42eb2 duplicate_computed_gotos
../../gcc/gcc/bb-reorder.c:2492
0xd42eb2 execute
../../gcc/gcc/bb-reorder.c:2524
Please submit a full bug report,

-fno-reorder-blocks-and-partition fixes the issue.

I'm currently reducing this further.

[Bug ipa/59008] [4.9 Regression] ICEs in try_make_edge_direct_simple_call / propagate_controlled_uses

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59008

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Jambor  ---
Indeed. Unfortunately, I will not be able to take a look until January.

[Bug fortran/59525] Inheritance problems

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
(In reply to janus from comment #2)
> (In reply to Sarantis Pantazis from comment #0)
> > I have some problems with inheritance.
> 
> What you describe is not a bug in the gfortran compiler, but in your
> understanding of how inheritance works.

To give a hit:

> > write(*,*) bla%i, bla%j
> > Error: 'j' at (1) is not a member of the 'mytype' structure

bla%j is not part of mytype. You need to use "select type" to access it - as
you did in "subroutine setbla"

[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

--- Comment #5 from joseph at codesourcery dot com  ---
On Thu, 12 Dec 2013, algrant at acm dot org wrote:

> demonstrates the same lack of ordering.  You suggest that this might
> be a problem with the atomic built-ins - and yes, if this had been a
> load-acquire, it would be a problem with the built-in not introducing a
> barrier or using a load-acquire instruction.  But for a load-consume on
> this architecture, no barrier is necessary to separate the load-consume
> from a load that is address-dependent on it.  The programmer wrote a
> dependency but the compiler lost track of it.

"address-dependent" is not a C standard concept.  As far as I can tell, at 
least as regards C there are no such ordering constraints between 
non-atomic operations, only between operations at least one of which is 
atomic - thus, it is the responsibility of the atomic built-in functions 
to ensure whatever ordering may be required.  (Whereas the parts of the 
memory model defining what counts as a "memory location" *do* have 
implications in the absence of atomics, restricting the code sequences 
that can be used for struct modifications and preventing speculative 
stores.)

> It's not necessary to demonstrate failure - there's an architectural 
> race condition here.  Even if it doesn't fail now there's no guarantee
> it will never fail on future more aggressively reordering cores.

You still need to provide a testcase (a complete program that can be 
compiled and linked with current GCC) that (a) does not show undefined 
behavior, (b) that, you justify by reference to the standard definitions 
and how they apply to source code constructs, must exhibit specific 
observable behavior (values printed, assertions passed, etc. - *not* just 
ordering of loads at the architectural level), and (c) that, you justify 
by reference to the architecture definition if not to actual observed 
failure, could fail to meet the requirements for observable behavior, 
given the code generated by GCC and the behavior permitted by the 
architecture for that code.

I am unable to tell what code you envisage running in another thread or 
what observable failure you think could result from "lack of ordering", 
because you have not provided a complete testcase.  Thus, I am unable to 
tell if there is a genuine bug here at all.  The standard definitions 
associated with atomicity are extremely complicated; you need to be very 
careful about identifying exactly how particular definitions apply to 
particular source code constructs and so how you deduce the requirements 
on behavior of a particular program, for a bug report to be of any use.

[Bug tree-optimization/41488] IVOpts cannot coalesce multiple induction variables

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #10 from Jeffrey A. Law  ---
ktkachov,

It seems to be working fine for me with my arm-eabi cross compiler.  Perhaps
you could provide some more details:

make check-gcc RUNTESTFLAGS="tree-ssa.exp=scev-7.c"
[ ... ]

In the gcc.sum file I've got:

Running /home/gcc/GIT/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ...
PASS: gcc.dg/tree-ssa/scev-7.c (test for excess errors)
PASS: gcc.dg/tree-ssa/scev-7.c scan-tree-dump-times sccp "Simplify PEELED_CHREC
into POLYNOMIAL_CHREC" 1

AFAICT, this issue has been resolved.

[Bug tree-optimization/58296] ivopts is unable to handle some loops altered by the loop header copying pass

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58296

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
Resolved by recent commit on trunk

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

--- Comment #15 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #14)
> Fixed. Thank you for testing it.  The Firefox ICE
> Seems to fix Mozilla build untill the next (unrelated) ICE:
> 
> /var/tmp/mozilla-central/js/src/vm/Stack.cpp: In member function
> ‘operator++’:
> /var/tmp/mozilla-central/js/src/vm/Stack.cpp:717:1: internal compiler error:
> in fixup_reorder_chain, at cfgrtl.c:3739
>  }
>  ^
> 0x5b594c fixup_reorder_chain
> ../../gcc/gcc/cfgrtl.c:3738
> 0x5b594c cfg_layout_finalize()
> ../../gcc/gcc/cfgrtl.c:4295
> 0xd42eb2 duplicate_computed_gotos
> ../../gcc/gcc/bb-reorder.c:2492
> 0xd42eb2 execute
> ../../gcc/gcc/bb-reorder.c:2524
> Please submit a full bug report,
> 
> is apparently related to Tereza's patch enabling
> -freroder-blocks-and-partition (and -fno-reorder-blocks-and-partition should
> be a workaround). Can you, please, open a new PR for it, if not reported
> already?

PR59527.

It looks like the fixes for this bug may be buggy, because with 
-fno-reorder-blocks-and-partition I get:

Executing: c++ -o js -Wall -Wpointer-arith -Woverloaded-virtual
-Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null
-Wsign-compare -Wno-invalid-offsetof -Wcast-align -flto=4 -fprofile-use
-fprofile-correction -fno-reorder-blocks-and-partition -march=native -fno-rtti
-fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED
-O3 -fomit-frame-pointer /var/tmp/moz-build-dir/js/src/shell/tmpD2q9gU.list
-lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id
-Wl,-rpath-link,../../../dist/bin
-Wl,-rpath-link,/var/tmp/moz-build-dir/dist/lib -L../../../dist/bin
-L../../../dist/lib -L/var/tmp/moz-build-dir/dist/lib -lnspr4 -lplc4 -lplds4
../libjs_static.a -lz -Wl,--whole-archive ../../../dist/lib/libmozglue.a
-Wl,--no-whole-archive -rdynamic -lm -ldl -lffi
/var/tmp/moz-build-dir/js/src/shell/tmpD2q9gU.list:
INPUT("Unified_cpp_shell0.o")
INPUT("../editline/Unified_c_editline0.o")

In member function ‘extractBetween’:
lto1: fatal error: Cgraph edge statement index out of range
compilation terminated.

[Bug middle-end/59471] [4.9 Regression] ICE using vector extensions (non-top-level BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
This started failing when the assertion has been added:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01265.html
There is no code to ensure that it won't happen though.
So, either the verification patch should be reverted and SRA adjusted to cope
with this, or something in gimple-expr.[ch] ? will need to be adjusted to
reject it (but e.g. making is_gimple_addressable more expensive might be a
problem).

[Bug libgomp/59337] surprising OMP error message

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 16 15:33:42 2013
New Revision: 206017

URL: http://gcc.gnu.org/viewcvs?rev=206017&root=gcc&view=rev
Log:
PR libgomp/59337
* openmp.c (resolve_omp_atomic): Adjust error message.

* gfortran.dg/gomp/pr59337.f90: New test.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/59337] surprising OMP error message

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Just use
!$OMP ATOMIC
i=i*-1
if you want to negate.

[Bug sanitizer/59136] [4.9 Regression] llvm-symbolizer shouldn't be started always

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136

--- Comment #11 from Jakub Jelinek  ---
Patches have been posted, but haven't been reviewed yet.
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00558.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00964.html

Various tsan testcases right now fail because it isn't in.

[Bug middle-end/59521] __builtin_expect not effective in switch

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-16
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug libstdc++/59436] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436

H.J. Lu  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #8 from H.J. Lu  ---
On Linux/x86, I got

spawn -ignore SIGHUP /export/gnu/import/git/gcc-test-ia32corei7/bld/./gcc/xg++
-shared-libgcc -B/export/gnu/import/git/gcc-test-ia32corei7/bld/./gcc
-nostdinc++
-L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/libsupc++/.libs
-B/usr/4.9.0/i686-linux/bin/ -B/usr/4.9.0/i686-linux/lib/ -isystem
/usr/4.9.0/i686-linux/include -isystem /usr/4.9.0/i686-linux/sys-include
-B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libstdc++-v3/src/.libs
-fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0
-ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE
-DLOCALEDIR="." -nostdinc++
-I/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/include/i686-linux
-I/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/include/backward
-I/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/testsuite/util
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc
-std=gnu++0x -S -o stdc++.s^M
In file included from /usr/include/features.h:375:0,^M
 from /usr/include/assert.h:36,^M
 from
/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/include/cassert:43,^M
 from
/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/include/precompiled/stdc++.h:33:^M
/usr/include/complex.h:112:1: internal compiler error: tree check: expected
tree_vec, have error_mark in get_innermost_template_args, at cp/pt.c:581^M
 __END_DECLS^M
 ^^M
0x8938b68 tree_check_failed(tree_node const*, char const*, int, char const*,
...)^M
../../src-trunk/gcc/tree.c:9192^M
0x81a83b2 tree_check^M
../../src-trunk/gcc/tree.h:2707^M
0x81a83b2 get_innermost_template_args(tree_node*, int)^M
../../src-trunk/gcc/cp/pt.c:581^M
0x81aab84 get_template_innermost_arguments(tree_node const*)^M
../../src-trunk/gcc/cp/pt.c:3044^M
0x8155e7b get_template_innermost_arguments_folded^M
../../src-trunk/gcc/cp/cp-lang.c:213^M
0x847cf6d gen_generic_params_dies^M
../../src-trunk/gcc/dwarf2out.c:10546^M
0x8499dc8 gen_scheduled_generic_parms_dies^M
../../src-trunk/gcc/dwarf2out.c:20999^M
0x8499dc8 dwarf2out_finish^M
../../src-trunk/gcc/dwarf2out.c:23914^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M

[Bug sanitizer/59136] [4.9 Regression] llvm-symbolizer shouldn't be started always

[glider at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136

--- Comment #12 from Alexander Potapenko  ---
I wonder if https://code.google.com/p/address-sanitizer/issues/detail?id=253 is
relevant here. In the case TSan tests do fork() (which I'm not expecting from
them, however) the parent and the child will share the same symbolizer, which
will just fail to multiplex their queries.

[Bug gcov-profile/59527] [4.9 Regression] ICE: in fixup_reorder_chain, at cfgrtl.c:3739 during PGO Firefox build

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 31447
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31447&action=edit
unreduced testcase

 % g++ -w -r -nostdlib -fprofile-use -fprofile-correction -march=amdfam10
-fno-exceptions -std=gnu++0x -O3 test.ii
In file included from /var/tmp/moz-build-dir/js/src/Unified_cpp_9.cpp:101:0:
/var/tmp/mozilla-central/js/src/vm/Stack.cpp: In member function
‘js::ScriptFrameIter& js::ScriptFrameIter::operator++()’:
/var/tmp/mozilla-central/js/src/vm/Stack.cpp:717:1: internal compiler error: in
fixup_reorder_chain, at cfgrtl.c:3739

[Bug middle-end/59471] [4.9 Regression] ICE using vector extensions (non-top-level BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR)

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471

--- Comment #3 from Martin Jambor  ---
It should be easy to make SRA safely cope with BIT_FIELD_REFs,
REALPART_EXPRs and IMAGPART_EXPRs under a VIEW_CONVERT_EXPR (as
opposed to those under a COMPONENT_REF, ARRAY_REF, MEM_REF or
similar).  I'd prefer it over detecting the other cases if it is
enough to relax the verification in this way.

I just wonder why do we have VIEW_CONVERT_EXPRs of BIT_FIELD_REFs at
all, can't we fold them just to one B_F_R with the expected final
type?  Or does it have some different semantics?

[Bug preprocessor/20262] __LINE__ implementation flaky.

[aaw at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262

Ollie Wild  changed:

   What|Removed |Added

 CC||aaw at gcc dot gnu.org

--- Comment #4 from Ollie Wild  ---
We recently ran into this issue in a context where __LINE__ was being used to
produce goto labels inside a macro-wrapped block of code.  The code in question
compiled fine with Clang/LLVM but produced a compiler error with GCC.

I've read through the standard (in this case, C++11), and as I read it
"presumed source line" is used to allow for the possibility of modifying the
source line via #line directives (which it says immediately thereafter in a
footnote), not as general consent to be liberal with line numbering. 
Regardless, using the true physical line conforms to the principle of least
surprise.

Would anyone be opposed to revisiting this?

[Bug libstdc++/59514] vector::emplace uses wrong iterator type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59514

--- Comment #1 from Jonathan Wakely  ---
I think this is already fixed on trunk

[Bug tree-optimization/41488] IVOpts cannot coalesce multiple induction variables

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488

--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #10)
> ktkachov,
> 
> It seems to be working fine for me with my arm-eabi cross compiler.  Perhaps
> you could provide some more details:
> 
> make check-gcc RUNTESTFLAGS="tree-ssa.exp=scev-7.c"
> [ ... ]
> 
> In the gcc.sum file I've got:
> 
> Running /home/gcc/GIT/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ...
> PASS: gcc.dg/tree-ssa/scev-7.c (test for excess errors)
> PASS: gcc.dg/tree-ssa/scev-7.c scan-tree-dump-times sccp "Simplify
> PEELED_CHREC into POLYNOMIAL_CHREC" 1
> 
> AFAICT, this issue has been resolved.

You're right, seems I had an inconsistent build tree state. It passes for me
now as well with a clean build. Sorry for the noise.

[Bug libstdc++/59508] std::find could use specialized container's find

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508

--- Comment #5 from Jonathan Wakely  ---
Users can specialize std::set::find to do something different,
e.g. write to a file, and it must not do that if they call std::find.

It's not a matter of whether the type is the library's iterator type or not.

[Bug tree-optimization/59519] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[su at cs dot ucdavis.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519

--- Comment #1 from Zhendong Su  ---
Below is simpler testcase that triggers the same ICE: 



int a, b, c, d;

void
foo ()
{
  for (; d; d++)
for (b = 0; b < 14; b++)
  {
c |= 1;
if (a)
  break;
  }
}

[Bug bootstrap/59528] New: Profiledbootstrap should use stage1 compiler during stagefeedback

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59528

Bug ID: 59528
   Summary: Profiledbootstrap should use stage1 compiler during
stagefeedback
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org

I just noticed that recently profiledbootstrap uses stageprofile compiler to
build final binary (i.e. one with instrumentation in). This is not only
wasteful for CPU time, but more importantly will lead to different binary each
time during parallel compilation - at compiling object file X during final
compilation the profile depends on compilation of all before.

We used to rebuild using stage1 compiler for this reason - that is
 1) build stage1 compiler
 2) build stage profile compiler + runtime library that also serves as a train
run
 3) build stage feedback compiler using data stage1 compiler with profile data
collected at 2)

[Bug libstdc++/59436] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436

--- Comment #9 from Jakub Jelinek  ---
Note this must be PCH related, can't reproduce it without PCH even with --param
ggc-min-expand=0 --param ggc-min-heapsize=0.
Unfortunately I only reproduce it two i686 builds ago and don't remember the
exact revision and what patches I had applied back then, so all I can see is
that in the PCH file there is some TEMPLATE_DECL with it's
decl_non_common.arguments set to error_mark_node when it ought to be TREE_LIST.
So, if somebody can reproduce it right now with their current tree, it would be
nice to debug where during PCH writing the bad value was stored and if it came
from already by that time bogus TEMPLATE_DECL, or if it got broken during the
PCH writing.

[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.9.0
Summary|FAIL:   |[4.9 Regression] FAIL:
   |17_intro/headers/c++200x/st |17_intro/headers/c++200x/st
   |dc++.cc (test for excess|dc++.cc (test for excess
   |errors) |errors)

[Bug libstdc++/59508] std::find could use specialized container's find

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508

--- Comment #6 from Oleg Endo  ---
(In reply to Jonathan Wakely from comment #5)
> Users can specialize std::set::find to do something
> different, e.g. write to a file, and it must not do that if they call
> std::find.
> 
> It's not a matter of whether the type is the library's iterator type or not.

Right.  If, then std::find should not invoke std::set::find (or std::map::find
etc) but the library's internal function to search the rb tree.

Of course users might still provide specializations of std::find for particular
iterator types but that shouldn't be a problem I think.

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

--- Comment #16 from Jan Hubicka  ---
> Executing: c++ -o js -Wall -Wpointer-arith -Woverloaded-virtual
> -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null
> -Wsign-compare -Wno-invalid-offsetof -Wcast-align -flto=4 -fprofile-use
> -fprofile-correction -fno-reorder-blocks-and-partition -march=native -fno-rtti
> -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED
> -O3 -fomit-frame-pointer /var/tmp/moz-build-dir/js/src/shell/tmpD2q9gU.list
> -lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id
> -Wl,-rpath-link,../../../dist/bin
> -Wl,-rpath-link,/var/tmp/moz-build-dir/dist/lib -L../../../dist/bin
> -L../../../dist/lib -L/var/tmp/moz-build-dir/dist/lib -lnspr4 -lplc4 -lplds4
> ../libjs_static.a -lz -Wl,--whole-archive ../../../dist/lib/libmozglue.a
> -Wl,--no-whole-archive -rdynamic -lm -ldl -lffi
> /var/tmp/moz-build-dir/js/src/shell/tmpD2q9gU.list:
> INPUT("Unified_cpp_shell0.o")
> INPUT("../editline/Unified_c_editline0.o")
> 
> In member function ???extractBetween???:
> lto1: fatal error: Cgraph edge statement index out of range
> compilation terminated.

This looks like some kind of LTO streaming corruption.  Are you sure you
rebuilt everything with updated compiler?

Honza

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #10 from Jakub Jelinek  ---
Ok, closing.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469

--- Comment #22 from Jan Hubicka  ---
00010 // This file implements the stickier parts of the SymbolTableListTraits
class,
00011 // and is explicitly instantiated where needed to avoid defining all this
code
00012 // in a widely used header.

I would thus say that libLLVMAsmParser.s misses the explicit instantiation in
it?

Honza

[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436

--- Comment #10 from H.J. Lu  ---
On Linux/x86-64, I got

[hjl@gnu-34 ~]$ cat /tmp/x.cc   
#include 
[hjl@gnu-34 ~]$
...
Starting program: /export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/cc1plus
-quiet -nostdinc++ -nostdinc++ -v -I
/export/gnu/import/git/gcc-test-intel64corei7/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I
/export/gnu/import/git/gcc-test-intel64corei7/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I
/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/libstdc++-v3/libsupc++
-I
/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/libstdc++-v3/include/backward
-I
/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/libstdc++-v3/testsuite/util
-iprefix
/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/
-isystem /export/gnu/import/git/gcc-test-intel64corei7/bld/./gcc/include
-isystem /export/gnu/import/git/gcc-test-intel64corei7/bld/./gcc/include-fixed
-D_GNU_SOURCE -D _GLIBCXX_ASSERT -D _GNU_SOURCE -D _GNU_SOURCE -D LOCALEDIR=.
-isystem /usr/4.9.0/x86_64-unknown-linux-gnu/include -isystem
/usr/4.9.0/x86_64-unknown-linux-gnu/sys-include /tmp/x.cc -quiet -dumpbase x.cc
-mtune=corei7 -march=corei7 -auxbase-strip /tmp/x.s -g -g -O2 -O2 -std=gnu++11
-version -fdiagnostics-color=never -fmessage-length=0 -ffunction-sections
-fdata-sections -o /tmp/x.s
GNU C++ (GCC) version 4.9.0 20131216 (experimental) [trunk revision 206016]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.0 20131216 (experimental) [trunk revision
206016], GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1
..

program received signal SIGSEGV, Segmentation fault.
unlink_from_assembler_name_hash (node=0x100472aca0, 
with_clones=with_clones@entry=false) at ../../src-trunk/gcc/symtab.c:251
251  gcc_assert (*slot == node);
Missing separate debuginfos, use: debuginfo-install glibc-2.17-20.0.fc19.x86_64
gmp-5.1.1-2.0.fc19.x86_64 libmpc-1.0.1-1.fc19.x86_64 mpfr-3.1.1-2.fc19.x86_64
zlib-1.2.7-10.fc19.x86_64
(gdb) p slot
$1 = (void **) 0x0

[Bug tree-optimization/34723] Summing variable should be initialized to the first member before the loop

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723

--- Comment #3 from Jeffrey A. Law  ---
Andrew, no.

4.2 didn't muck things up at all.  The 4.2 code is clearly better (unless
you're vectorizing the loop).

What's happening is the IV code changes the loop structure enough that
VRP2/DOM2 are unable to peel the iteration off the loop.  

In gcc-4.2, just prior to VRP2 we have:
  # BLOCK 2 freq:1000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # SUCC: 3 [100.0%]  (fallthru,exec)

 # BLOCK 3 freq:1
  # PRED: 3 [90.0%]  (dfs_back,true,exec) 2 [100.0%]  (fallthru,exec)
  # ivtmp.43_3 = PHI ;
  # val_16 = PHI ;
:;
  D.1880_7 = MEM[symbol: table, index: ivtmp.43_3]{table[i]};
  D.1881_8 = (unsigned char) D.1880_7;
  val.1_9 = (unsigned char) val_16;
  D.1883_10 = val.1_9 + D.1881_8;
  val_11 = (char) D.1883_10;
  ivtmp.43_5 = ivtmp.43_3 + 1;
  if (ivtmp.43_5 != 10) goto ; else goto ;
  # SUCC: 3 [90.0%]  (dfs_back,true,exec) 4 [10.0%]  (loop_exit,false,exec)


VRP threads the jump through the backedge for the first iteration of the loop
resulting in:
 # BLOCK 2 freq:1000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  goto  ();
  # SUCC: 5 [100.0%]  (fallthru,exec)

  # BLOCK 3 freq:9000
  # PRED: 5 [100.0%]  (fallthru) 3 [88.9%]  (true,exec)
  # ivtmp.43_3 = PHI ;
  # val_16 = PHI ;
:;
  D.1880_7 = MEM[symbol: table, index: ivtmp.43_3]{table[i]};
  D.1881_8 = (unsigned char) D.1880_7;
  val.1_9 = (unsigned char) val_16;
  D.1883_10 = val.1_9 + D.1881_8;
  val_11 = (char) D.1883_10;
  ivtmp.43_5 = ivtmp.43_3 + 1;
  if (ivtmp.43_5 != 10) goto ; else goto ;
  # SUCC: 3 [88.9%]  (true,exec) 4 [11.1%]  (loop_exit,false,exec)

  # BLOCK 4 freq:1000
  # PRED: 3 [11.1%]  (loop_exit,false,exec)
  # val_2 = PHI ;
:;
  D.1884_13 = (int) val_2;
  return D.1884_13;
  # SUCC: EXIT [100.0%]

  # BLOCK 5 freq:1000
  # PRED: 2 [100.0%]  (fallthru,exec)
  # ivtmp.43_17 = PHI <0(2)>;
  # val_1 = PHI <0(2)>;
:;
  D.1880_18 = MEM[symbol: table, index: ivtmp.43_17]{table[i]};
  D.1881_19 = (unsigned char) D.1880_18;
  val.1_20 = (unsigned char) val_1;
  D.1883_21 = val.1_20 + D.1881_19;
  val_22 = (char) D.1883_21;
  ivtmp.43_23 = ivtmp.43_17 + 1;
  goto  ();
  # SUCC: 3 [100.0%]  (fallthru)

Which will ultimately compile down to the efficient code where the first
iteration has been peeled off.

If we look at the trunk, DOM2/VRP2 have had the order changed, so if we look at
the code immediately prior to DOM2 we have:

 :
  ivtmp.10_16 = (unsigned long) &table;
  _12 = (unsigned long) &MEM[(void *)&table + 10B];
  goto ;

  :

  :
  # val_14 = PHI 
  # ivtmp.10_18 = PHI 
  _13 = (void *) ivtmp.10_18;
  _4 = MEM[base: _13, offset: 0B];
  _5 = (unsigned char) _4;
  val.0_6 = (unsigned char) val_14;
  _7 = _5 + val.0_6;
  val_8 = (char) _7;
  ivtmp.10_17 = ivtmp.10_18 + 1;
  if (ivtmp.10_17 != _12)
goto ;
  else
goto ;

Note how the test to go back to the top of the loop has changed.  It's no
longer testing a simple integer counter, which threading handled nicely. 
Instead it's a more complex test involving two objects.  And neither DOM2 nor
VRP2 are able to untangle it to get the code we want.

ISTM this  should have a regression marker and attached to the jump threading
meta-bug.  



_

[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436

--- Comment #11 from H.J. Lu  ---
It is PCH related. Stage1 and stage2 cc1plus can compile the same input.
But stage3 cc1plus fails.

[Bug tree-optimization/34723] [4.7/4.8/4.9 Regression] Summing variable should be initialized to the first member before the loop

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

[Bug rtl-optimization/59466] Slow code generation by LRA for memory addresses on PPC

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59466

--- Comment #1 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Dec 16 18:24:54 2013
New Revision: 206023

URL: http://gcc.gnu.org/viewcvs?rev=206023&root=gcc&view=rev
Log:
2013-12-16  Vladimir Makarov  

PR rtl-optimization/59466
* emit-rtl.c (change_address_1): Don't validate address for LRA.
* recog.c (general_operand): Accept any memory for LRA.
* lra.c (lra_set_insn_recog_data): Add an assert.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c
trunk/gcc/lra.c
trunk/gcc/recog.c

[Bug gcov-profile/59527] [4.9 Regression] ICE: in fixup_reorder_chain, at cfgrtl.c:3739 during PGO Firefox build

[tejohnson at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527

--- Comment #2 from Teresa Johnson  ---
I will take a look and report back. -freorder-blocks-and-partition was
recently enabled by default, which presumably exposed this issue.
Thanks,
Teresa

On Mon, Dec 16, 2013 at 8:21 AM, octoploid at yandex dot com
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527
>
> --- Comment #1 from Markus Trippelsdorf  ---
> Created attachment 31447
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31447&action=edit
> unreduced testcase
>
>  % g++ -w -r -nostdlib -fprofile-use -fprofile-correction -march=amdfam10
> -fno-exceptions -std=gnu++0x -O3 test.ii
> In file included from /var/tmp/moz-build-dir/js/src/Unified_cpp_9.cpp:101:0:
> /var/tmp/mozilla-central/js/src/vm/Stack.cpp: In member function
> ‘js::ScriptFrameIter& js::ScriptFrameIter::operator++()’:
> /var/tmp/mozilla-central/js/src/vm/Stack.cpp:717:1: internal compiler error: 
> in
> fixup_reorder_chain, at cfgrtl.c:3739
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436

--- Comment #12 from H.J. Lu  ---
(In reply to H.J. Lu from comment #11)
> It is PCH related. Stage1 and stage2 cc1plus can compile the same input.
> But stage3 cc1plus fails.

It is very sensitive PCH load address.

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[BugMaster at narod dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807

Anton Mitrofanov  changed:

   What|Removed |Added

 CC||BugMaster at narod dot ru

--- Comment #18 from Anton Mitrofanov  ---
This patch is ok for mingw32 target but may produce incorrect code for x86_64
linux target in case of saving/restoring both rax and r10. In that case during
restoring of rax register (in "if (r10_live && eax_live)" path of
http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.c?r1=205860&r2=205859&pathrev=205860)
we will make move from incorrect address [rsp + allocate - UNITS_PER_WORD]
while the saved value will be at address [rsp + allocate + UNITS_PER_WORD].
Here is possible code that can be generated (by looking at current gcc source
code):

// suppose rsp == 1000 here
push rax // rsp == 992 ; [992] == rax
push r10 // rsp == 984 ; [984] == r10
mov rax, 400 // where 400 is allocate value
call allocate_stack
sub rsp, rax // rax == 400 so rsp == 584
mov r10, [rsp + 400] // 584 + 400 == 984 ; r10 = [984]
mov rax, [rsp + 400 - 8] // 584 + 400 - 8 == 976 ; rax = [976] <- WRONG

Instead the last instruction should be

mov rax, [rsp + 400 + 8] // 584 + 400 + 8 == 992 ; rax = [992]

Sorry, I can't write test case to trigger this code path so I will leave this
comment here and not create new bug report (if you want you can move it to new
bug report).

[Bug target/53987] [SH] Unnecessary zero-extension before cmp/eq

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987

--- Comment #3 from Oleg Endo  ---
(In reply to Oleg Endo from comment #2)
> As of rev 204180 (4.9) this problem still exists.
> As far as I understand, the actual root of the problem is that the 'unsigned
> char' mem loads into regs are neither sign nor zero extended.

I've tried doing the following to enforce sign extension of memory loads <
SImode:

Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md(revision 205971)
+++ gcc/config/sh/sh.md(working copy)
@@ -5958,7 +5958,18 @@

 (define_expand "zero_extendsi2"
   [(set (match_operand:SI 0 "arith_reg_dest")
-(zero_extend:SI (match_operand:QIHI 1 "zero_extend_operand")))])
+(zero_extend:SI (match_operand:QIHI 1 "general_extend_operand")))]
+  ""
+{
+  if (!zero_extend_operand (operands[1], mode))
+{
+  rtx tmp = gen_reg_rtx (SImode);
+  emit_insn (gen_extendsi2 (tmp, operands[1]));
+  emit_insn (gen_zero_extendsi2 (operands[0],
+   gen_lowpart (mode, tmp)));
+  DONE;
+}
+})

 (define_insn_and_split "*zero_extendsi2_compact"
   [(set (match_operand:SI 0 "arith_reg_dest" "=r")

However, this doesn't fix the problem.
According to CSiBE (-m4 -ml -O2 -mpretend-cmove) there are a few cases where
register allocation is a bit better, but there are also some code size
increases (e.g. interference with the tst #imm,r0 patterns).  There's a code
size decrease of 228 bytes on the whole set.

Nevertheless, having the explicit sign_extend mem loads could be useful.  For
example knowing that a mem load sign extends the cmpeq insn could be hoisted
above the extension insns before register allocation.
On SH2A it's probably better to not allow zero extending mem loads in the
expander and defer the movu.{b|w} insn selection until the combine pass. 
Otherwise the original test case will always use zero extending mem loads, even
though sign extending ones would suffice (16 bit insns vs 32 bit insns).

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807

--- Comment #19 from H.J. Lu  ---
(In reply to Anton Mitrofanov from comment #18)
> This patch is ok for mingw32 target but may produce incorrect code for
> x86_64 linux target in case of saving/restoring both rax and r10. In that
> case during restoring of rax register (in "if (r10_live && eax_live)" path
> of
> http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.
> c?r1=205860&r2=205859&pathrev=205860) we will make move from incorrect
> address [rsp + allocate - UNITS_PER_WORD] while the saved value will be at
> address [rsp + allocate + UNITS_PER_WORD]. Here is possible code that can be
> generated (by looking at current gcc source code):
> 
> // suppose rsp == 1000 here
> push rax // rsp == 992 ; [992] == rax
> push r10 // rsp == 984 ; [984] == r10
> mov rax, 400 // where 400 is allocate value
> call allocate_stack
> sub rsp, rax // rax == 400 so rsp == 584
> mov r10, [rsp + 400] // 584 + 400 == 984 ; r10 = [984]
> mov rax, [rsp + 400 - 8] // 584 + 400 - 8 == 976 ; rax = [976] <- WRONG
> 
> Instead the last instruction should be
> 
> mov rax, [rsp + 400 + 8] // 584 + 400 + 8 == 992 ; rax = [992]
> 

There are

  if (eax_live)
{
  insn = emit_insn (gen_push (eax));
  allocate -= UNITS_PER_WORD;
...
  if (r10_live)
{
  r10 = gen_rtx_REG (Pmode, R10_REG);
  insn = emit_insn (gen_push (r10));
  allocate -= UNITS_PER_WORD;
...
 if (r10_live && eax_live)
{
  t = plus_constant (Pmode, stack_pointer_rtx, allocate);
  emit_move_insn (gen_rtx_REG (word_mode, R10_REG),
  gen_frame_mem (word_mode, t));
  t = plus_constant (Pmode, stack_pointer_rtx,
 allocate - UNITS_PER_WORD);
  emit_move_insn (gen_rtx_REG (word_mode, AX_REG),
  gen_frame_mem (word_mode, t));
}

They look OK to me.

[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #8 from Markus Trippelsdorf  ---
Honza,

I've tested your patch from comment 7 and it doesn't work.
However your suggestion "to simply return NULL when inner_binfo is NULL"
does seem to work fine. I've successfully build Chromium with it.

diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index f5b5926504c7..c0fce4cde069 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -648,6 +648,8 @@ record_target_from_binfo (vec  &nodes,
 {
   tree inner_binfo = get_binfo_at_offset (type_binfo,
  offset, otr_type);
+  if (!inner_binfo)
+   return;
   /* For types in anonymous namespace first check if the respective vtable
 is alive. If not, we know the type can't be called.  */
   if (!flag_ltrans && anonymous)
@@ -661,7 +663,6 @@ record_target_from_binfo (vec  &nodes,
  if (!vnode || !vnode->definition)
return;
}
-  gcc_assert (inner_binfo);
   if (!pointer_set_insert (matched_vtables, BINFO_VTABLE (inner_binfo)))
{
  tree target = gimple_get_virt_method_for_binfo (otr_token,
inner_binfo);

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[BugMaster at narod dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807

--- Comment #20 from Anton Mitrofanov  ---
I was talking about:

 if (r10_live && eax_live)
{
  t = plus_constant (Pmode, stack_pointer_rtx, allocate);
  emit_move_insn (gen_rtx_REG (word_mode, R10_REG),
  gen_frame_mem (word_mode, t));
  t = plus_constant (Pmode, stack_pointer_rtx,
 allocate - UNITS_PER_WORD);
  emit_move_insn (gen_rtx_REG (word_mode, AX_REG),
  gen_frame_mem (word_mode, t));
}

And especially:
  t = plus_constant (Pmode, stack_pointer_rtx,
 allocate - UNITS_PER_WORD);

[Bug libstdc++/59529] New: fix experimental/string_view end-of-string edge cases

[bigotp at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59529

Bug ID: 59529
   Summary: fix experimental/string_view end-of-string edge cases
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bigotp at acm dot org

Created attachment 31448
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31448&action=edit
Patch and test update

Per http://isocpp.org/files/papers/N3762.html#string.view.ops, for a given
string_view sv:

   stringview sv{"text"};
   auto rv = sv.substr(sv.size());

rv should be a string view starting at sv.end() with size zero.  In the current
implementation this code improperly raises std::out_of_range.

Related to this, basic_string_view constructors with length zero and a valid
str should not be re-mapped to the internal empty string.

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[BugMaster at narod dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807

--- Comment #21 from Anton Mitrofanov  ---
It should be:
  t = plus_constant (Pmode, stack_pointer_rtx,
 allocate + UNITS_PER_WORD);

[Bug libstdc++/59530] New: Incorrect check on string_view operator[]

[bigotp at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59530

Bug ID: 59530
   Summary: Incorrect check on string_view operator[]
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bigotp at acm dot org

Created attachment 31449
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31449&action=edit
Patch and test update

Per http://isocpp.org/files/papers/N3762.html#string.view.ops, string_view's
operator[](size()) is undefined, unlike basic_string_view.

[Bug libstdc++/59531] New: string_view overrun in copy operation

[bigotp at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59531

Bug ID: 59531
   Summary: string_view overrun in copy operation
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bigotp at acm dot org

Created attachment 31450
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31450&action=edit
Patch and test case

The terminating value for the string_view copy operation is wrong, resulting in
buffer overruns.

[Bug preprocessor/20262] __LINE__ implementation flaky.

[gromer at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262

Geoff Romer  changed:

   What|Removed |Added

 CC||gromer at google dot com

--- Comment #5 from Geoff Romer  ---
The issue isn't the flexibility in "presumed", it's the flexibility in "source
line": the standard defines line number in terms of the "current token", but
gives no explicit guidance about which token is considered "current" in a case
like this, where the preprocessor is arguably expanding two different macros at
the same time.

[Bug target/18469] configure incorrectly defines gid_t

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18469

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #3 from Kai Tietz  ---
Issue still exists for ia64 and cygwin/mingw targets on 4.9.

The following files are including auto-host.h header:
- config/i386/cygming-crtbegin.c
- config/i386/cygming-crtend.c
- config/i386/cygming-crtend.c
- config/i386/cygwin.S
- config/ia64/crtbegin.S
- config/ia64/crtend.S
- crtstuff.c

In config/ia64/t-ia64-elf there is a tweak for finding this include-file.

The macros required in crtstuff.c are:
- HAVE_GAS_HIDDEN
- HAVE_LD_EH_FRAME_HDR

The cygwin/mingw part uses:
- DEFAULT_USE_CXA_ATEXIT
- HAVE_LD_RO_RW_SECTION_MIXING
- HAVE_GAS_WEAK
- HAVE_GAS_CFI_SECTIONS_DIRECTIVE

The macros required in ia64 are:
- HAVE_INITFINI_ARRAY_SUPPORT
- USE_GAS_SYMVER

So a lot of infrastructure of gcc needs to be ported to libgcc for detecting
and probs for ld vs. gold, and as.

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Even better something that uses it and that even declares the original:
extern int j;
static int i __attribute__((weakref("j")));

int
foo (void)
{
  return &i ? i : 0;
}

This ICEs with cc1plus even at -O2, since r199971.  The problem is that
node->alias_target is IDENTIFIER_NODE, some places cope with it being
IDENTIFIER_NODE (in fact, I don't see where it would become something
different), but some places just blindly assume it must be a DECL_P.

[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226

--- Comment #9 from Jan Hubicka  ---
> Honza,
> 
> I've tested your patch from comment 7 and it doesn't work.
> However your suggestion "to simply return NULL when inner_binfo is NULL"
> does seem to work fine. I've successfully build Chromium with it.

Good to know. I am however not sure if it is safe - this scenario happens in
"diamond"
shaped virtual inheritance and here we know we visited the base in question on
different
path. But I wonder if we can encounter different types of thunks.

I put more complete attempt to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252

Honza

[Bug libstdc++/59514] vector::emplace uses wrong iterator type

[chrissakalis at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59514

Chris Sakalis  changed:

   What|Removed |Added

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

--- Comment #2 from Chris Sakalis  ---
As Jonathan Wakely correctly said, it is fixed in trunk.

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945

--- Comment #5 from Jan Hubicka  ---
> Even better something that uses it and that even declares the original:
> extern int j;
> static int i __attribute__((weakref("j")));
> 
> int
> foo (void)
> {
>   return &i ? i : 0;
> }
> 
> This ICEs with cc1plus even at -O2, since r199971.  The problem is that
> node->alias_target is IDENTIFIER_NODE, some places cope with it being
> IDENTIFIER_NODE (in fact, I don't see where it would become something
> different), but some places just blindly assume it must be a DECL_P.

It is IDENTIFIER_NODE until it is "resolved" into a target symbol that
is a decl (and one gets proper reference edge in symbol table). 
For normal aliases the identifier_node gets turned into a decl after
compilation unit is finalized (via resolve_alias). External weakrefs may
be never resolved...

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #17 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #16)
> > In member function ???extractBetween???:
> > lto1: fatal error: Cgraph edge statement index out of range
> > compilation terminated.
> 
> This looks like some kind of LTO streaming corruption.  Are you sure you
> rebuilt everything with updated compiler?

Just double-checked. And yes, unfortunately it's 100% reproducible.

[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305

--- Comment #4 from Jack Howarth  ---
Created attachment 31452
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31452&action=edit
assembly file for gcc.dg/atomic/c11-atomic-exec-5.c  -O0 on darwin12

[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305

--- Comment #3 from Jack Howarth  ---
Created attachment 31451
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31451&action=edit
preprocessed source for gcc.dg/atomic/c11-atomic-exec-5.c  -O0 on darwin12

[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305

--- Comment #5 from Jack Howarth  ---
Added preprocessed source and assembly file generated with...

/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131216/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c
-B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libatomic/
-L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libatomic/.libs
-latomic -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -std=c11
-pedantic-errors -pthread -D_POSIX_C_SOURCE=200809L -lm -m32 -o
./c11-atomic-exec-5.exe --save-temps

on x86_64-apple-darwin12. Can someone confirm that we have both support for
floating-point exceptions and the required hook on darwin? If so, I suspect we
are tickling a pthread bug on darwin.

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945

--- Comment #6 from Jan Hubicka  ---
OK, somewhat confusing on the testcase above is that j is defined, but C++ FE
never consider it uses and thus never passes it to middle-end.

The problem is that C++ FE chose to first assemble alias:
#0  assemble_alias (decl=, target=
) at ../../gcc/varasm.c:5682
#1  0x00ca94cc in rest_of_decl_compilation (decl=, 
top_level=1, at_end=0) at ../../gcc/passes.c:205
#2  0x00610745 in make_rtl_for_nonlocal_decl (decl=, 
init=, asmspec=0x0) at ../../gcc/cp/decl.c:5909
#3  0x00613173 in cp_finish_decl (decl=,
init=
, init_const_expr_p=false, asmspec_tree=, flags=1)
at ../../gcc/cp/decl.c:6480
#4  0x0073291d in cp_parser_init_declarator (parser=0x77048000, 
decl_specifiers=0x7fffe2f0, checks=0x0,
function_definition_allowed_p=true, 
member_p=false, declares_class_or_enum=0,
function_definition_p=0x7fffe37f, 
maybe_range_for_decl=0x0) at ../../gcc/cp/parser.c:16804
#5  0x00729785 in cp_parser_simple_declaration (parser=0x77048000, 
function_definition_allowed_p=true, maybe_range_for_decl=0x0)
at ../../gcc/cp/parser.c:11195
#6  0x00729573 in cp_parser_block_declaration (parser=0x77048000,
statement_p=
false) at ../../gcc/cp/parser.c:11076
#7  0x007292ee in cp_parser_declaration (parser=0x77048000)
at ../../gcc/cp/parser.c:10973
#8  0x00728e68 in cp_parser_declaration_seq_opt (parser=0x77048000)
at ../../gcc/cp/parser.c:10859
#9  0x0071cfdd in cp_parser_translation_unit (parser=0x77048000)
at ../../gcc/cp/parser.c:4018
#10 0x007519b4 in c_parse_file () at ../../gcc/cp/parser.c:31322
#11 0x008b5e5d in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1056
#12 0x00daf45f in compile_file () at ../../gcc/toplev.c:547
#13 0x00db14da in do_compile () at ../../gcc/toplev.c:1887
#14 0x00db1649 in toplev_main (argc=3, argv=0x7fffe6a8)
at ../../gcc/toplev.c:1963
#15 0x0155cb50 in main (argc=3, argv=0x7fffe6a8) at
../../gcc/main.c:36

and then finalize variable

#0  varpool_finalize_decl (decl=) at
../../gcc/cgraphunit.c:824
#1  0x00ca96ca in rest_of_decl_compilation (decl=, 
top_level=1, at_end=0) at ../../gcc/passes.c:238
#2  0x00610745 in make_rtl_for_nonlocal_decl (decl=, 
init=, asmspec=0x0) at ../../gcc/cp/decl.c:5909

It should do just one of these.

Index: passes.c
===
--- passes.c(revision 206013)
+++ passes.c(working copy)
@@ -187,6 +187,8 @@ rest_of_decl_compilation (tree decl,
   int top_level,
   int at_end)
 {
+  bool finalize = true;
+
   /* We deferred calling assemble_alias so that we could collect
  other attributes such as visibility.  Emit the alias now.  */
   if (!in_lto_p)
@@ -203,6 +205,7 @@ rest_of_decl_compilation (tree decl,
 DECL_EXTERNAL (decl) = 0;
 TREE_STATIC (decl) = 1;
 assemble_alias (decl, alias);
+finalize = false;
   }
   }

@@ -234,7 +237,7 @@ rest_of_decl_compilation (tree decl,
  rebuild it.  */
   if (in_lto_p && !at_end)
 ;
-  else if (TREE_CODE (decl) != FUNCTION_DECL)
+  else if (finalize && TREE_CODE (decl) != FUNCTION_DECL)
 varpool_finalize_decl (decl);
 }

[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305

--- Comment #6 from Dominique d'Humieres  ---
> on x86_64-apple-darwin12. Can someone confirm that we have both support 
> for floating-point exceptions and the required hook on darwin? 

I cannot answer these questions.

> If so, I suspect we are tickling a pthread bug on darwin.

But as said in comment 2, the test succeeds on a loaded machine, i.e., with
-j=n, where n is the number of available threads. So I share the suspicion.

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265

--- Comment #18 from Jan Hubicka  ---
> Just double-checked. And yes, unfortunately it's 100% reproducible.

Can not think of much of reason for this.  How much off the index is? Just
slightly or is it completely random number?

Honza
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.