[Bug c/63591] be more strict when accepting parameter forward declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591 --- Comment #7 from Andreas Schwab sch...@linux-m68k.org --- A function declaration with forward declared parameters it is a prototype, sort of. Not defining the forward declared parameter as a real parameter should probably be flagged as an error.
[Bug tree-optimization/63593] New: ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63593 Bug ID: 63593 Summary: ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 33757 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33757action=edit reduced testcase Compiler output [5.0]: $ gcc -O3 -fno-tree-vectorize testcase.c testcase.c: In function 'foo': testcase.c:5:1: error: incompatible types in PHI argument 0 foo (void) ^ int unsigned int _101 = PHI ivtmp_136(3) testcase.c:5:1: internal compiler error: verify_gimple failed 0xbecd3e verify_gimple_in_cfg(function*, bool) /mnt/svn/gcc-trunk/gcc/tree-cfg.c:5025 0xabbad6 execute_function_todo /mnt/svn/gcc-trunk/gcc/passes.c:1755 0xabc513 execute_todo /mnt/svn/gcc-trunk/gcc/passes.c:1812 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Compiler output [4.9/4.8/4.7]: $ gcc -O3 -fno-tree-vectorize testcase.c testcase.c: In function 'foo': testcase.c:5:1: error: no immediate_use list foo (void) ^ for SSA_NAME: _15 in statement: _5 = PHI pretmp_99(8), _15(4) PHI argument _15 for PHI node _5 = PHI pretmp_99(8), _15(4) testcase.c:5:1: internal compiler error: verify_ssa failed 0xce6d1b verify_ssa(bool) /mnt/svn/gcc-4_9/gcc/tree-ssa.c:1096 0xc60286 verify_loop_closed_ssa(bool) /mnt/svn/gcc-4_9/gcc/tree-ssa-loop-manip.c:601 0xc6069f gimple_duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vecedge_def*, va_heap, vl_ptr*, int) /mnt/svn/gcc-4_9/gcc/tree-ssa-loop-manip.c:772 0xc610d7 tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*, tree_niter_desc*, void (*)(loop*, void*), void*) /mnt/svn/gcc-4_9/gcc/tree-ssa-loop-manip.c:1190 0xbd6a14 tree_predictive_commoning_loop /mnt/svn/gcc-4_9/gcc/tree-predcom.c:2517 0xbd6a14 tree_predictive_commoning() /mnt/svn/gcc-4_9/gcc/tree-predcom.c:2552 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Compiler output [4.6]: $ gcc -O3 -fno-tree-vectorize testcase.c -wrapper valgrind,-q ==21897== Invalid read of size 2 ==21897==at 0x742BBC: is_gimple_reg_type (gimple.c:2818) ==21897==by 0x742BBC: is_gimple_val (gimple.c:2886) ==21897==by 0x8E76E5: verify_gimple_phi (tree-cfg.c:3938) ==21897==by 0x8F3497: verify_stmts (tree-cfg.c:4330) ==21897==by 0xA0A50C: verify_ssa (tree-ssa.c:920) ==21897==by 0x9B6DC3: verify_loop_closed_ssa (tree-ssa-loop-manip.c:456) ==21897==by 0x9B72DC: gimple_duplicate_loop_to_header_edge (tree-ssa-loop-manip.c:622) ==21897==by 0x9B7C9D: tree_transform_and_unroll_loop (tree-ssa-loop-manip.c:1046) ==21897==by 0x945094: tree_predictive_commoning_loop (tree-predcom.c:2543) ==21897==by 0x946390: tree_predictive_commoning (tree-predcom.c:2580) ==21897==by 0x7F5B75: execute_one_pass (passes.c:1556) ==21897==by 0x7F5E74: execute_pass_list (passes.c:1611) ==21897==by 0x7F5E86: execute_pass_list (passes.c:1612) ==21897== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==21897== testcase.c: In function 'foo': testcase.c:5:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r216429 - ICE 4_9 r213788 - ICE 4_8 r213789 - ICE 4_7 r211571 - ICE 4_6 r197894 - ICE
[Bug c/63591] be more strict when accepting parameter forward declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #7) A function declaration with forward declared parameters it is a prototype, sort of. Not defining the forward declared parameter as a real parameter should probably be flagged as an error. Indeed. Still someone has to implement it... Kjetil?
[Bug target/63594] New: [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63594
Bug ID: 63594
Summary: [5 Regression] ICE: in ix86_vector_duplicate_value, at
config/i386/i386.c:39831 with -mavx512f
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Created attachment 33758
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33758action=edit
reduced testcase
Compiler output:
$ gcc -mavx512f testcase.c
testcase.c: In function 'foo_1':
testcase.c:6:11: internal compiler error: in ix86_vector_duplicate_value, at
config/i386/i386.c:39831
__v64qi v1 = {
^
0xe76c32 ix86_vector_duplicate_value
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:39831
0xe82543 ix86_expand_vector_init_duplicate
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:39956
0xec2823 ix86_expand_vector_init(bool, rtx_def*, rtx_def*)
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:40739
0x100628d gen_vec_initv64qi(rtx_def*, rtx_def*)
/mnt/svn/gcc-trunk/gcc/config/i386/sse.md:17488
0x8bcfe6 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/mnt/svn/gcc-trunk/gcc/recog.h:308
0x8bcfe6 store_constructor
/mnt/svn/gcc-trunk/gcc/expr.c:6456
0x8bebc6 expand_constructor
/mnt/svn/gcc-trunk/gcc/expr.c:7873
0x8a3b0a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/mnt/svn/gcc-trunk/gcc/expr.c:9711
0x8b2e83 store_expr(tree_node*, rtx_def*, int, bool)
/mnt/svn/gcc-trunk/gcc/expr.c:5341
0x8ba2da expand_assignment(tree_node*, tree_node*, bool)
/mnt/svn/gcc-trunk/gcc/expr.c:5127
0x7a14d8 expand_gimple_stmt_1
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:3278
0x7a14d8 expand_gimple_stmt
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:3374
0x7a6a56 expand_gimple_basic_block
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:5209
0x7a8b06 execute
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:5815
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Tested revisions:
r216429 - ICE
4_9 r213788 - OK
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488
--- Comment #3 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com ---
Could you please clarify your comment #36
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590#c36) in PR4596? I mean LIM
is now the pass that pushes
memory usage to 1.8GB - all other optimization passes are happy with just
~800MB.
How did you measure lim impact (1,8G)? (Was it by -ftime-report being run
with/without lim optimization? Or was it top? Or some other tool which allow to
see memory footprint for each optimization pass.)
I can see this (for the full test case om 46590). ( I mean based on
-ftime-report we see ~5,5Mb, but this only GC memory, right? ):
MAIN__ main
Analyzing compilation unit
{GC 41969k - 36104k} {GC 72488k - 52189k} {GC 70118k - 55388k}Performing
interprocedural optimizations
*free_lang_data visibility early_local_cleanups {GC 81054k - 73552k}
free-inline-summary whole-program profile_estimate devirt cp inline
pure-const static-var single-use comdatsAssembling functions:
MAIN__ {GC 137793k - 78714k} {GC 107079k - 70685k} {GC 97203k - 77229k} {GC
100487k - 71679k} {GC 148921k - 129443k} {GC 190666k - 128409k} {GC 168488k
- 127341k} main
Execution times (seconds)
phase setup : 0.05 ( 0%) usr 0.01 ( 0%) sys 0.08 ( 0%) wall
107 kB ( 0%) ggc
phase parsing : 13.79 ( 1%) usr 0.15 ( 0%) sys 13.94 ( 1%) wall
41869 kB ( 7%) ggc
phase lang. deferred: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
0 kB ( 0%) ggc
phase opt and generate :2103.63 (99%) usr 89.40 (100%) sys2195.36 (99%) wall
519770 kB (93%) ggc
phase finalize : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
0 kB ( 0%) ggc
garbage collection : 5.42 ( 0%) usr 0.04 ( 0%) sys 5.48 ( 0%) wall
0 kB ( 0%) ggc
callgraph construction : 0.91 ( 0%) usr 0.00 ( 0%) sys 0.88 ( 0%) wall
7644 kB ( 1%) ggc
callgraph optimization : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) wall
0 kB ( 0%) ggc
ipa dead code removal : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
0 kB ( 0%) ggc
ipa cp : 0.18 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall
256 kB ( 0%) ggc
ipa inlining heuristics : 2.54 ( 0%) usr 0.00 ( 0%) sys 2.54 ( 0%) wall
3253 kB ( 1%) ggc
ipa profile : 0.27 ( 0%) usr 0.00 ( 0%) sys 0.27 ( 0%) wall
0 kB ( 0%) ggc
ipa pure const : 0.42 ( 0%) usr 0.00 ( 0%) sys 0.42 ( 0%) wall
0 kB ( 0%) ggc
cfg construction: 0.31 ( 0%) usr 0.01 ( 0%) sys 0.33 ( 0%) wall
2278 kB ( 0%) ggc
cfg cleanup : 1.75 ( 0%) usr 0.05 ( 0%) sys 1.90 ( 0%) wall
752 kB ( 0%) ggc
CFG verifier: 22.85 ( 1%) usr 0.10 ( 0%) sys 22.83 ( 1%) wall
0 kB ( 0%) ggc
trivially dead code : 1.12 ( 0%) usr 0.00 ( 0%) sys 1.10 ( 0%) wall
0 kB ( 0%) ggc
df scan insns : 2.79 ( 0%) usr 0.12 ( 0%) sys 2.92 ( 0%) wall
0 kB ( 0%) ggc
df multiple defs: 0.75 ( 0%) usr 0.01 ( 0%) sys 0.77 ( 0%) wall
0 kB ( 0%) ggc
df reaching defs: 76.35 ( 4%) usr 68.69 (77%) sys 144.67 ( 7%) wall
0 kB ( 0%) ggc
df live regs: 6.93 ( 0%) usr 0.79 ( 1%) sys 7.65 ( 0%) wall
0 kB ( 0%) ggc
df liveinitialized regs: 2.74 ( 0%) usr 0.69 ( 1%) sys 3.41 ( 0%) wall
0 kB ( 0%) ggc
df use-def / def-use chains: 1.04 ( 0%) usr 0.00 ( 0%) sys 1.10 ( 0%)
wall 0 kB ( 0%) ggc
df reg dead/unused notes: 4.37 ( 0%) usr 0.00 ( 0%) sys 4.36 ( 0%) wall
6401 kB ( 1%) ggc
register information: 0.56 ( 0%) usr 0.00 ( 0%) sys 0.55 ( 0%) wall
0 kB ( 0%) ggc
alias analysis : 3.12 ( 0%) usr 0.00 ( 0%) sys 3.15 ( 0%) wall
9226 kB ( 2%) ggc
alias stmt walking : 632.31 (30%) usr 2.05 ( 2%) sys 635.16 (29%) wall
2380 kB ( 0%) ggc
register scan : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall
274 kB ( 0%) ggc
rebuild jump labels : 0.54 ( 0%) usr 0.01 ( 0%) sys 0.54 ( 0%) wall
0 kB ( 0%) ggc
parser (global) : 13.79 ( 1%) usr 0.15 ( 0%) sys 13.94 ( 1%) wall
41869 kB ( 7%) ggc
early inlining heuristics: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
0 kB ( 0%) ggc
inline parameters : 1.06 ( 0%) usr 0.00 ( 0%) sys 1.07 ( 0%) wall
1 kB ( 0%) ggc
integration : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall
0 kB ( 0%) ggc
tree gimplify : 5.23 ( 0%) usr 0.04 ( 0%) sys 5.26 ( 0%) wall
38114 kB ( 7%) ggc
tree eh : 0.14 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall
0 kB ( 0%) ggc
tree CFG construction : 0.49 ( 0%) usr 0.02 ( 0%) sys 0.52 ( 0%) wall
13855 kB ( 2%) ggc
tree CFG cleanup: 93.20 ( 4%) usr 0.37 ( 0%) sys 93.55 ( 4%) wall
3894 kB ( 1%) ggc
tree tail merge : 0.28 ( 0%) usr 0.00 ( 0%)
[Bug c/23144] [4.8/4.9/5 Regression] invalid parameter forward declarations not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23144 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added CC||k.s.matheussen at notam02 dot no --- Comment #17 from Joseph S. Myers jsm28 at gcc dot gnu.org --- *** Bug 63591 has been marked as a duplicate of this bug. ***
[Bug c/63591] be more strict when accepting parameter forward declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Joseph S. Myers jsm28 at gcc dot gnu.org --- As far as I can tell, the bug discussed here is bug 23144. *** This bug has been marked as a duplicate of bug 23144 ***
[Bug c/63567] Linux kernel build error due to non-static initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567 --- Comment #12 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Sun Oct 19 16:47:35 2014 New Revision: 216440 URL: https://gcc.gnu.org/viewcvs?rev=216440root=gccview=rev Log: PR c/63567 * c-typeck.c (output_init_element): Allow initializing objects with static storage duration with compound literals even in C99 and add pedwarn for it. * gcc.dg/pr63567-3.c: New test. * gcc.dg/pr63567-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr63567-3.c trunk/gcc/testsuite/gcc.dg/pr63567-4.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/63567] Linux kernel build error due to non-static initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Marek Polacek mpolacek at gcc dot gnu.org --- Now fixed for real.
[Bug c/63595] New: Segmentation faults inside kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595 Bug ID: 63595 Summary: Segmentation faults inside kernel Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sasha.levin at oracle dot com CC: marxin at gcc dot gnu.org Hi all, I've observed segmentation faults on simple programs, such as: $ mkdir test Segmentation fault Inside a kernel built from the latest master branch. I've bisected the problem down to: commit 52200d03c231f0bddbd4bbc5cd3608c6a1dd4598 Author: marxin marxin@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Oct 16 10:47:55 2014 + IPA ICF pass, part 3/5 * Makefile.in: New object files included. * cgraph.c (cgraph_node::dump): New cgraph_node flag icf_merged is printed. (verify_edge_corresponds_to_fndecl): More sensitive verification of nodes that are merged by IPA ICF. * cgraph.h (cgraph_node::num_references): New function. * cgraphunit.c (cgraph_node::expand_thunk): White space fixed. * common.opt: New options ipa-icf, ipa-icf-functions and ipa-icf-variables introduced. * doc/invoke.texi: Documentation of new options introduced. * ipa-icf-gimple.c: New file. * ipa-icf-gimple.h: New file. * ipa-icf.c: New file. * ipa-icf.h: New file. * lto-cgraph.c (lto_output_node): Streaming of icf_merged flag added. (input_overwrite_node): Likewise. * lto-section-in.c: New icf section added. * lto-streamer.h (enum lto_section_type): Likewise. * opts.c (common_handle_option): New option added. * passes.def: New pass included. * timevar.def: Time variable for IPA ICF added. * tree-pass.h: New IPA ICF pass entry point added. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216305 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/63595] Segmentation faults inside kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |tree-optimization --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is most likely either bug 63569 or bug 63583 (both I filed after creating a reduced testcase).
[Bug c/63592] Linux kernel build failure due to duplicate exported symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63592 --- Comment #2 from Sasha Levin sasha.levin at oracle dot com --- But that... worked previously? Is backward compatibility intended to be broken in this case?
[Bug c/63592] Linux kernel build failure due to duplicate exported symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63592 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Sasha Levin from comment #2) But that... worked previously? Is backward compatibility intended to be broken in this case? GNU 90 and C99 have different extern inline behavior and has been mentioned for the last 5 or so years now. What changed was defaulting to the C99/C11 behavior rather than the GNU90 behavior. This is a kernel bug and should be reported/fixed there instead.
[Bug tree-optimization/63595] Segmentation faults inside kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595 --- Comment #2 from Sasha Levin sasha.levin at oracle dot com --- Thanks. I'll keep an eye on both of them, and will report here if the fix for either of those fixes the segmentation faults I'm seeing. Did you happen to bisect it down to the same commit?
[Bug tree-optimization/63595] Segmentation faults inside kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Sasha Levin from comment #2) Did you happen to bisect it down to the same commit? Yes.
[Bug target/63596] New: Saving of GPR/FPRs for stdarg even though the variable argument is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63596
Bug ID: 63596
Summary: Saving of GPR/FPRs for stdarg even though the variable
argument is not used
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target: aarch64
Take a function like:
int f(int a, ...)
{
return a;
}
Currently with the top of the trunk we get:
f:
subsp, sp, #192
stpx1, x2, [sp, 136]
stpx3, x4, [sp, 152]
stpx5, x6, [sp, 168]
strx7, [sp, 184]
strq0, [sp]
strq1, [sp, 16]
strq2, [sp, 32]
strq3, [sp, 48]
strq4, [sp, 64]
strq5, [sp, 80]
strq6, [sp, 96]
strq7, [sp, 112]
addsp, sp, 192
ret
--- CUT ---
But we can optimize this down to just
f:
ret
--- CUT ---
The .stdarg debug dump says:
f: va_list escapes 0, needs to save 0 GPR units and 0 FPR units.
But nowhere in aarch64.c uses cfun-va_list_gpr_size or cfun-va_list_fpr_size
to figure out how many registers need to be saved.
[Bug target/63594] [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63594 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-19 CC||kyukhin at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Confirmed, adding CC.
[Bug target/63590] wrong code with -mstringop-strategy=vector_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63590 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-19 CC||kyukhin at gcc dot gnu.org Target Milestone|--- |4.9.3 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Confirmed, adding CC.
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #4 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- My gcc version for now: gcc (GCC) 5.0.0 20140908 (experimental)
[Bug c/63597] New: Generate useless trampoline for some nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63597
Bug ID: 63597
Summary: Generate useless trampoline for some nested function
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
In some cases, GCC generate a trampoline for nested functions whereas it is not
needed.
For example, for the code:
extern void h(void (*)(int*), int*);
int f(int x, int y) {
int a;
void g(int *ptr_a) {
*ptr_a = ptr_a[x-a] + ptr_a[y-a];
}
h(g, a);
return a;
}
It generates a trampoline for function g:
movl$-17599, %eax
movl$-17847, %edx
movl%edi, 8(%rsp)
movl%esi, (%rsp)
leaq12(%rsp), %rdi
leaq4(%rsp), %rsi
movw%ax, 12(%rsp)
movl$g.1623, %eax
movl%eax, 2(%rdi)
movq%rsp, 8(%rdi)
movw%dx, 6(%rdi)
movl$-1864106167, 16(%rdi)
callh
whereas function g doesn't use this access and so doesn't need the trampoline:
g.1623:
.LFB1:
.cfi_startproc
movl-4(%rdi), %eax
addl4(%rdi), %eax
movl%eax, (%rdi)
ret
(no use of %r10).
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #5 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- Also, I collect massif data and see no tree-ssa-lim in it (i mean in top contributors). So what do you think? (How did you measured 1,8Gb caused by lim? - this is for me to understand whether this bug is actual or not) Thanks
[Bug c/63597] Generate useless trampoline for some nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63597 Patrick Pelissier patrick.pelissier at gmail dot com changed: What|Removed |Added Version|4.9.2 |4.9.1 --- Comment #1 from Patrick Pelissier patrick.pelissier at gmail dot com --- -O option shall be used to compile the code.
[Bug c/63592] Linux kernel build failure due to duplicate exported symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63592 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #4 from Igor Zamyatin izamyatin at gmail dot com --- The same could be seen for 253.perlbmk and 400.perlbench tests from spec2K/2006 suites
[Bug ipa/63598] New: [5.0 Regression] ICE: in ipa_merge_profiles at ipa-utils.c:396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63598 Bug ID: 63598 Summary: [5.0 Regression] ICE: in ipa_merge_profiles at ipa-utils.c:396 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: mliska at suse dot cz Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Created attachment 33759 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33759action=edit Preprocessed source /opt/gnu/bin/bash ./libtool --tag=CC --mode=compile /test/gnu/gcc/objdir/./gcc /xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11 /bin/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gc c-5.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hp ux11.11/sys-include-DHAVE_CONFIG_H -I. -I../../../gcc/libgomp -I../../../gc c/libgomp/config/posix -I../../../gcc/libgomp -Wall -Werror -frandom-seed=fixed -seed -Wc,-pthread -g -O2 -MT env.lo -MD -MP -MF .deps/env.Tpo -c -o env.lo ../. ./../gcc/libgomp/env.c libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-5.0/hppa2. 0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgomp -I../../../gcc/libgomp/config/posix -I../../../gcc/l ibgomp -Wall -Werror -pthread -frandom-seed=fixed-seed -g -O2 -MT env.lo -MD -MP -MF .deps/env.Tpo -c ../../../gcc/libgomp/env.c -fPIC -DPIC -o .libs/env.o ../../../gcc/libgomp/env.c:1446:1: internal compiler error: Segmentation fault ialias (omp_is_initial_device) ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. (gdb) r Starting program: /test/gnu/gcc/objdir/gcc/cc1 -fpreprocessed env.i -quiet -dumpbase env.c -auxbase-strip .libs/env.o -g -O2 -Wall -Werror -version -frandom-seed=fixed-seed -fPIC -o env.s warning: Private mapping of shared library text was not specified by the executable; setting a breakpoint in a shared library which is not privately mapped will not work. See the HP-UX 11i v3 chatr manpage for methods to privately map shared library text. GNU C (GCC) version 5.0.0 20141019 (experimental) [trunk revision 216441] (hppa2.0w-hp-hpux11.11) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.2, MPC version 1.0 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 5.0.0 20141019 (experimental) [trunk revision 216441] (hppa2.0w-hp-hpux11.11) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.2, MPC version 1.0 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: eaae743d522abd7927ead6970564ef2b Program received signal SIGSEGV, Segmentation fault. 0x0087be3c in _Z18ipa_merge_profilesP11cgraph_nodeS0_ (dst=0x0, src=0x7afbd460) at ../../gcc/gcc/ipa-utils.c:396 396 || !dst-definition) (gdb) bt #0 0x0087be3c in _Z18ipa_merge_profilesP11cgraph_nodeS0_ (dst=0x0, src=0x7afbd460) at ../../gcc/gcc/ipa-utils.c:396 #1 0x008570d4 in _ZN7ipa_icf12sem_function5mergeEPNS_8sem_itemE ( this=0x4035f440, alias_item=0x4035f5d0) at ../../gcc/gcc/ipa-icf.c:652 #2 0x0085e220 in _ZN7ipa_icf18sem_item_optimizer13merge_classesEj ( this=0x4035f300, prev_class_count=33) at ../../gcc/gcc/ipa-icf.c:2241 #3 0x0085b41c in _ZN7ipa_icf18sem_item_optimizer7executeEv (this=0x4035f300) at ../../gcc/gcc/ipa-icf.c:1602 #4 0x0085e85c in ipa_icf::ipa_icf_driver() () at ../../gcc/gcc/ipa-icf.c:2319 #5 0x0085eb5c in _ZN7ipa_icf12pass_ipa_icf7executeEP8function ( this=0x4033aef8) at ../../gcc/gcc/ipa-icf.c:2366 #6 0x00a4e3f4 in _Z16execute_one_passP8opt_pass (pass=0x4033aef8) at ../../gcc/gcc/passes.c:2155 #7 0x00a4f910 in _Z21execute_ipa_pass_listP8opt_pass (pass=0x4033aef8) at ../../gcc/gcc/passes.c:2545 #8 0x0038cfa4 in _ZL10ipa_passesv () at ../../gcc/gcc/cgraphunit.c:2057 #9 0x0038d3d8 in _ZN12symbol_table7compileEv (this=0x7ae2b000) at ../../gcc/gcc/cgraphunit.c:2137 #10 0x0038d894 in _ZN12symbol_table25finalize_compilation_unitEv ( this=0x7ae2b000) at ../../gcc/gcc/cgraphunit.c:2290 #11 0x000982f4 in _Z27c_write_global_declarationsv () at ../../gcc/gcc/c/c-decl.c:10640 #12 0x00bf73b4 in _ZL12compile_filev () at ../../gcc/gcc/toplev.c:569 ---Type return to continue, or q return to quit--- #13 0x00bfb22c in _ZL10do_compilev () at ../../gcc/gcc/toplev.c:1977 #14 0x00bfb540 in toplev_main(int, char**) () at ../../gcc/gcc/toplev.c:2053 #15 0x011f79c4 in main (argc=17, argv=0x7eff0544
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #19 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Sun Oct 19 20:49:27 2014 New Revision: 216443 URL: https://gcc.gnu.org/viewcvs?rev=216443root=gccview=rev Log: PR fortran/48979 * trans-const.c (gfc_build_nan): New function. * trans-const.h (gfc_build_nan): New prototype. * trans-intrinsic.c (gfc_conv_intrinsic_exponent): Handle special values. (gfc_conv_intrinsic_minmaxval): Use gfc_build_nan. (gfc_conv_intrinsic_fraction): Handle special values. (gfc_conv_intrinsic_spacing): Likewise. (gfc_conv_intrinsic_rrspacing): Likewise. (gfc_conv_intrinsic_set_exponent): Likewise. * gfortran.dg/ieee/intrinsics_2.F90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ieee/intrinsics_2.F90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-const.c trunk/gcc/fortran/trans-const.h trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #2 from Martin Liška mliska at suse dot cz ---
Following two functions are merged:
static boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type
boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actorint,
boost::log::value_extractor, void, boost::actor; ValueT = int;
boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
boost::actorboost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun ] (struct actor left, struct attribute_actor right)
static boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type
boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actor{anonymous}::my_class,
boost::log::value_extractor, void, boost::actor; ValueT = int;
boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
boost::actorboost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun ] (struct actor left, struct attribute_actor right)
with following body:
{
struct type D.3826;
struct to_log_fun D.3825;
struct attribute_name D.3824;
int SR.9;
struct actor left;
bb 2:
left = left;
SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
MEM[(struct attribute_name *)D.3824] = SR.9_4;
boost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun::attribute_output_terminalint (D.3826, left, D.3824,
D.3825, 0);
D.3826 ={v} {CLOBBER};
return;
}
As I was debugging ao_ref_alias_sets, there's MEM_REF where we have different
template arguments: attribute_actorint,... vs.
attribute_actor{anonymous}::my_class,
What do you think Richard about these record_types from alias set perspective:
(gdb) p debug_tree(t1)
mem_ref 0x76ab4000
type integer_type 0x76c33690 int public type_6 SI
size integer_cst 0x76c51048 constant 32
unit size integer_cst 0x76c51060 constant 4
align 32 symtab 0 alias set 4 canonical type 0x76c33690 precision
32 min integer_cst 0x76c51000 -2147483648 max integer_cst 0x76c51018
2147483647
pointer_to_this pointer_type 0x76c55738
arg 0 ssa_name 0x76aae678
type reference_type 0x76e20d20 type record_type 0x76de7dc8
attribute_actor
unsigned DI
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 symtab 0 alias set 7 canonical type 0x76e20d20
visited var parm_decl 0x76e1eb00 rightdef_stmt GIMPLE_NOP
version 2
ptr-info 0x76a7e3d8
arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
constant 0
$1 = void
(gdb) p debug_tree(t2)
mem_ref 0x76aa1ac8
type integer_type 0x76c33690 int public type_6 SI
size integer_cst 0x76c51048 constant 32
unit size integer_cst 0x76c51060 constant 4
align 32 symtab 0 alias set 4 canonical type 0x76c33690 precision
32 min integer_cst 0x76c51000 -2147483648 max integer_cst 0x76c51018
2147483647
pointer_to_this pointer_type 0x76c55738
arg 0 ssa_name 0x76a77dc8
type reference_type 0x76e20540 type record_type 0x76ddd888
attribute_actor
unsigned DI
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 symtab 0 alias set 7 canonical type 0x76e20540
visited var parm_decl 0x76e1ea00 rightdef_stmt GIMPLE_NOP
version 2
ptr-info 0x76a7e300
arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
constant 0
these types are called for alias_set comparison, with following record_types:
(gdb) p debug_tree((tree_node*)0x76de7dc8)
record_type 0x76de7dc8 attribute_actor needs-constructing type_5 type_6
SI
size integer_cst 0x76c51048 type integer_type 0x76c33150
bitsizetype constant 32
unit size integer_cst 0x76c51060 type integer_type 0x76c330a8
sizetype constant 4
align 32 symtab 0 alias set 17 canonical type 0x76de7dc8
fields field_decl 0x76de4ed8 D.2798
type record_type 0x76dddb28 actor needs-constructing type_5 type_6
SI size integer_cst 0x76c51048 32 unit size integer_cst 0x76c51060
4
align 32 symtab 0 alias set 15 canonical type 0x76dddb28 fields
field_decl 0x76de01c8 proto_expr_ context namespace_decl 0x76d8d2f8
boost
full-name struct boost::actorboost::log::attribute_terminal
needs-constructor X() X(constX) this=(X) n_parents=0
use_template=1 interface-unknown
pointer_to_this pointer_type 0x76e03930 reference_to_this
reference_type 0x76dff0a8 chain type_decl 0x76de0098
[Bug c/63592] Linux kernel build failure due to duplicate exported symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63592 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Igor Zamyatin from comment #4) The same could be seen for 253.perlbmk and 400.perlbench tests from spec2K/2006 suites That is a bug in the SPEC CPU also. There is a define for __attribute__ which causes the issue. I decided to use -std=gnu90 when compiling SPEC CPU as a portability flag.
[Bug middle-end/63597] Generate useless trampoline for some nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63597 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Well this code is undefined anyways. Plus we don't find out that we don't need the chain until it is too late (RTL expand time). I am going to close this as invalid as x-a and y-a is undefined and does not mean the location will be fixed for the whole time as only a should be considered as being escaping.
[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576 --- Comment #1 from Martin Liška mliska at suse dot cz --- Do you have Honza an idea how to handle correctly situation, where ipa_profile is called before IPA ICF and we mark speculative an edge in: #0 cgraph_edge::make_speculative (this=this@entry=0x769e8c98, n2=0x76933468, direct_count=1776, direct_frequency=optimized out) at ../../gcc/cgraph.c:1027 #1 0x00844d6f in ipa_profile () at ../../gcc/ipa-profile.c:641 #2 (anonymous namespace)::pass_ipa_profile::execute (this=optimized out) at ../../gcc/ipa-profile.c:742 #3 0x0091bee2 in execute_one_pass (pass=pass@entry=0x1bc76b0) at ../../gcc/passes.c:2155 #4 0x0091cbc2 in execute_ipa_pass_list (pass=0x1bc76b0) at ../../gcc/passes.c:2545 #5 0x005e222b in do_whole_program_analysis () at ../../gcc/lto/lto.c:3253 #6 0x005e25e6 in lto_main () at ../../gcc/lto/lto.c:3431 #7 0x009d48f2 in compile_file () at ../../gcc/toplev.c:555 #8 0x009d6bdf in do_compile () at ../../gcc/toplev.c:1977 #9 toplev_main (argc=28, argv=0x1ba4970) at ../../gcc/toplev.c:2053 #10 0x012140dc in main (argc=26, argv=0x7fffdd38) at ../../gcc/main.c:36 Thank you, Martin
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #20 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Fully fixed on trunk.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 Sandra Loosemore sandra at codesourcery dot com changed: What|Removed |Added CC||sandra at codesourcery dot com --- Comment #43 from Sandra Loosemore sandra at codesourcery dot com --- I'm seeing the same errors as in Comment 8 (complaints about arrays with negative sizes) when building a cross for aarch64-linux-gnu from mainline head. I'm confused about the status of this issue -- is there an uncommitted patch out there somewhere?
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #44 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Sandra Loosemore from comment #43) I'm seeing the same errors as in Comment 8 (complaints about arrays with negative sizes) when building a cross for aarch64-linux-gnu from mainline head. I'm confused about the status of this issue -- is there an uncommitted patch out there somewhere? Yes there is a missing patch for aarch64 with the later kernel header files.
[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- speculative edges come in pairs (direct, indirect edge) that is obtained by speculative_call_info. THen you need to sum counts (instead of taking ones from BB) and turn them back to frequencies (because it is profile only counts should be non-0)
[Bug libquadmath/55821] Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55821 Sandra Loosemore sandra at codesourcery dot com changed: What|Removed |Added CC||sandra at codesourcery dot com --- Comment #7 from Sandra Loosemore sandra at codesourcery dot com --- Trying to build an arm-none-linux-gnueabi cross from mainline head, I'm getting this error now: /scratch/sandra/arm-fsf/src/gcc-mainline/libquadmath/libquadmath.texi:369: @include `libquadmath-vers.texi': No such file or directory. /scratch/sandra/arm-fsf/src/gcc-mainline/libquadmath/libquadmath.texi:374: warning: undefined flag: BUGURL. Reverting the patch from r216027 makes it work again. I don't see anything named BUILD_LIBQUADMATH coming out of configure, but in config.log I do see: BUILD_LIBQUADMATH_FALSE='' BUILD_LIBQUADMATH_TRUE='#' Are you sure that this patch was actually tested with a clean build directory where libquadmath-vers.texi was not already present from a previous build?
[Bug ipa/63598] [5.0 Regression] ICE: in ipa_merge_profiles at ipa-utils.c:396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63598 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org --- Introduced in r216305.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #70 from Kazumoto Kojima kkojima at gcc dot gnu.org --- I'd like to apply the revised patches below to sh-lra branch for looking at the problems easily. Oleg, is it OK for you? c#55: Fixup the result of decompose_mem_address when INDEX_REG_CLASS is a single register class. c#59: Introduce target hook which disables the substitution of pseudos with equivalent memory values. c#61: Define SH specific HARD_REGNO_CALLER_SAVE_MODE target macro. c#66: Make *addsi3_compact insn_and_split and add an alternative which will split to (set a c) and (set (plus a b)) after reload. I omit c#29 patch which touches lra-constraints.c and may impact on other targets. That patch would make it hard to compare with other targets. c#55 and c#59 also touch lra-constraints.c but those changes unlikely impact on other targets. Fortunately the test case c#28 doesn't ICE anymore without c#29.
