[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 Yury Gribov changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ygribov at gcc dot gnu.org
[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 Yury Gribov changed: What|Removed |Added Attachment #53458|0 |1 is obsolete|| Attachment #53493|0 |1 is obsolete|| --- Comment #12 from Yury Gribov --- Created attachment 53530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53530=edit Final patch Attached patch passes bootstrap (regular and asan) and regtesting and, as explained above, results in very small <1% reduction of optimizations. If there are no objections, I'll post it to gcc-patches.
[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 --- Comment #10 from Yury Gribov --- Created attachment 53458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53458=edit Very draft patch (In reply to Jakub Jelinek from comment #7) > Perhaps either a quick check that for base ptrs that live in memory > gimple_vuse is the same for both statements or if not, do walk_aliased_vdefs > with low constant limit? > We'd want to stop if we reach the vdef of the stmt in base_checks vector > (then we didn't find anything that could clobber it and can therefore use > the cached check) or when we see a stmt that may clobber it (then we can't > use the cached check). Something like this? It does not help with b.1_2 in attached reprocase though, because alias oracle considers *b.0_1 = 2; to clobber it. I'm trying to collect statistics how many checks this optimization removes during bootstrap-asan but I'm getting crashes when asan-bootstrapping on unchanged trunk. Is this possible?
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 Yury Gribov changed: What|Removed |Added CC||ygribov at gcc dot gnu.org --- Comment #29 from Yury Gribov --- > > 1. it can only merge two directories at one time. So, for multiple > > directories, for example "n", we have to invoke gcov-tool merge n-1 times in > > order to merge all of them? > > Yep. I guess one can write a simple bash script that does that. I've added one at https://github.com/yugr/maintainer-scripts/blob/master/gcov-tool-many
[Bug libgomp/103276] [openacc] Trying to map already mapped data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276 --- Comment #5 from Yury Gribov --- Created attachment 51823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51823=edit Runnable reprocase I've attached another reprocase which reproduces the error at runtime (but let me reiterate that the original minirepro is easier to analyze). It can be compiled with /home/y.gribov/install/gcc-master/usr/local/bin/gfortran repro.f90 -O2 -ffree-form -fopenacc -foffload-options=-march=gfx908 It crashes at runtime with libgomp: Trying to map into device [0x7fffd8d0..0x7fffd928) object when [0x7fffd918..0x7fffd920) is already mapped Problem reproduces both on devel/omp/gcc-11 (commit f85ed229, Nov 10) and master (commit 0136f25a, Nov 10).
[Bug libgomp/103276] [openacc] Trying to map already mapped data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276
--- Comment #4 from Yury Gribov ---
(In reply to Andrew Pinski from comment #3)
> No the gimple is wrong. is taking the address of the argument. It
> should just be var here if you what the reference points to rather than the
> address of the decl holding the pointer.
Thank you, makes sense. In that case the problem occurs at OMP lowering:
voidD.27 copyin_simple (struct simple & restrict varD.3961)
{
var.0_1 = varD.3961;
{
D.3965.D.3963 = var.0_1;
D.3965.varD.3964 =
#pragma omp target oacc_enter_exit_data map(to:*var.0_1 [len: 8])
map(alloc:varD.3961 [pointer assign, bias: 0])
[Bug libgomp/103276] [openacc] Trying to map already mapped data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276 Yury Gribov changed: What|Removed |Added CC||ygribov at gcc dot gnu.org --- Comment #2 from Yury Gribov --- This might be by chance, it could be fixed in mainline - or your example is too much simplified. > At least as is it cannot fail as there is no main program but just a module. I see. But is a runtime crash really mandatory here? It requires a bit of luck so that address ranges of local variable in copyin_simple overlaps local variables in another call. And even if it does, the crash will not be very stable across branches (because stack layouts change, etc.). My main goal was to provide a minimal self-explanatory usecase - there is a clear reference to local stack object passed to GOACC_enter_exit_data which is missing in the original code...
[Bug middle-end/102310] New: ICE in visit_ref_for_mod_analysis with OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310 Bug ID: 102310 Summary: ICE in visit_ref_for_mod_analysis with OpenACC Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ygribov at gcc dot gnu.org Target Milestone: --- Created attachment 51455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51455=edit Reprocase Attached code crashes with kernel.f90:30:11: internal compiler error: in visit_ref_for_mod_analysis, at ipa-prop.c:2846 30 | END PROGRAM | ^ 0xa2ea60 visit_ref_for_mod_analysis /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:2846 0xa2ea60 visit_ref_for_mod_analysis /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:2837 0x992861 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*)) /home/y.gribov/src/gcc-11/gcc/gimple-walk.c:806 0xa3c1a2 ipa_analyze_params_uses_in_bb /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:2870 0xa3c1a2 analysis_dom_walker::before_dom_children(basic_block_def*) /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:2953 0x14eb815 dom_walker::walk(basic_block_def*) /home/y.gribov/src/gcc-11/gcc/domwalk.c:309 0xa3786d ipa_analyze_node(cgraph_node*) /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:3024 0x156d357 ipcp_generate_summary /home/y.gribov/src/gcc-11/gcc/ipa-cp.c:6001 0xb45f6c execute_ipa_summary_passes(ipa_opt_pass_d*) /home/y.gribov/src/gcc-11/gcc/passes.c:2248 0x83b68b ipa_passes /home/y.gribov/src/gcc-11/gcc/cgraphunit.c:2181 0x83b68b symbol_table::compile() /home/y.gribov/src/gcc-11/gcc/cgraphunit.c:2291 0x83d91b symbol_table::compile() /home/y.gribov/src/gcc-11/gcc/cgraphunit.c:2271 0x83d91b symbol_table::finalize_compilation_unit() /home/y.gribov/src/gcc-11/gcc/cgraphunit.c:2539 when compiled with OpenACC-accelerated toolchain targeting GCN. It crashes on master and releases/gcc-11 branches. Compile flags: gfortran -ffree-form -ffree-line-length-none -O2 -fopenacc kernel.f90 Target compiler has been built with configure --target=amdgcn-amdhsa --enable-languages=c,lto,fortran --disable-sjlj-exceptions --with-newlib --enable-as-accelerator-for=x86_64-pc-linux-gnu --with-build-time-tools=/home/y.gribov/install/amdgcn-amdhsa-9.0/bin --disable-libquadmath Host compiler has been build with configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-offload-targets=amdgcn-amdhsa=/home/y.gribov/install/gcc-master/usr/local --disable-bootstrap --disable-multilib
