[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #11 from rsandifo at gcc dot gnu.org --- (In reply to Wilco from comment #10) > That fixes one of the examples but not pr71727. As the Arm movsi issues > show, there are many mid-end alignment bugs. FTR, I think the pr71727 test is behaving correctly for -fno-common, see the comment I just added to the PR. Andrew's fix in comment 9 looks clearly correct to me (= preapproved). Kind-of surprising we haven't been burnt by this earlier.
[Bug tree-optimization/92822] [10 Regression] vfma_laneq_f32 and vmul_laneq_f32 are broken on aarch64 after r278938
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92822 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #5 from rsandifo at gcc dot gnu.org --- I think this is mostly a target problem. We weren't providing patterns to extract a 64-bit vector from a 128-bit vector, despite that being very much a native operation. Adding those fixes most of the problems. What's left is that: v4sf_b = VEC_PERM_EXPR ; ...extract first half of v4sf_b... gets filled out as: v4sf_b = VEC_PERM_EXPR ; ...extract first half of v4sf_b... and we never recover from the awkwardness of that permute. The easiest fix seems to be to extend a partial duplicate to a full duplicate instead of a partial duplicate followed by a partial blend.
[Bug c/93435] [8/9/10 Regression] Hang with -O2 on innocuous looking code with GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435 Martin Liška changed: What|Removed |Added CC||alan.lawrence at arm dot com Summary|Hang with -O2 on innocuous |[8/9/10 Regression] Hang |looking code with GCC 8.3 |with -O2 on innocuous ||looking code with GCC 8.3 --- Comment #2 from Martin Liška --- Probably started with r6-3380-gd0f4e7fcdbde6134.
[Bug debug/93380] Variable Length Array Evaluation will be wrong or cause GDB to crash due to GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93380 --- Comment #2 from Robert Dumitru --- Hi Andrew, Thank you for your pointing out that. I will report the issue to ARM as well. However, regarding 1 and 2: 1. I understand this looks like a gdb bug, but my investigation pointed me to consider that what gdb does is correct- at least partially. It tries to read the memory to find the size of the array. If the memory is not initialised with the correct value, the size can be huge - hence - virtual memory exhausted bug. I will try and check with a newer gdb. Maybe gdb should know the expression can not be evaluated before right instructions are executed? 2. I checked with gcc 9.2.1 20191025 and the this still happens.
[Bug libstdc++/93426] fix typo in span
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93426
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
Testcase:
// { dg-options "-std=gnu++2a" }
#include
int i[1];
std::span s(i, i+1);
93426.cc:3:19: error: class template argument deduction failed:
3 | std::span s(i, i+1);
| ^
93426.cc:3:19: error: no matching function for call to 'span(int [1], int*)'
...
[Bug c/93435] [8/9/10 Regression] Hang with -O2 on innocuous looking code with GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435 --- Comment #3 from Jakub Jelinek --- I guess the main problem is that SRA turns those ~ 100 statements into ~35 statements and e.g. tree DSE then hangs on that.
[Bug tree-optimization/93411] variable reference to constant array with same elements not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93411 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #2 from Richard Biener --- There's also already a bug about this (can't find it quickly enough). IIRC my concerns were 1) it should be done during propagation to catch 2nd level opportunities 2) for compile-time some pre-computation needs to happen on the CTORs (not sure if I remember that correctly) 3) not sure if the patch allowed non-uniform CTORs but accesses to a uniform subrange
[Bug target/71727] -O3 -mstrict-align produces code which assumes unaligned vector accesses work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71727 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #9 from rsandifo at gcc dot gnu.org --- (In reply to Wilco from comment #8) > (In reply to Martin Liška from comment #7) > > Christophe: Can the bug be marked as resolved? > > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 - it's still failing > since the underlying issues haven't been resolved. I think we just need to change the test. Now that -fno-common is the default (thanks), the definition of the array is local and so its alignment can be changed. And since the test is hard-coded to access the first element, we realise that we can use SIMD accesses if we increase the alignment of the array to 16. I think we should force -fcommon here.
[Bug tree-optimization/93439] [9/10 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Don't have graphite enabled in our bisect seed, so can't (easily) bisect. I can confirm it on the trunk.
[Bug driver/91220] -Q --help=common displays options limited to subsets of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91220 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Should be fixed.
[Bug analyzer/93450] ICE in real_maxval, at real.c:2593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93450 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with addition of -fanalyzer in r10-5950-g757bf1dff5e8cee3.
[Bug sanitizer/93433] sanitizer_linux.cc contains non-Linux-specific code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433 --- Comment #6 from Martin Liška --- (In reply to Roland Illig from comment #4) > Reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433 > Hello. You probably posted a wrong link. I would expect one to LLVM bugzilla.
[Bug analyzer/93451] New: ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93451
Bug ID: 93451
Summary: ICE: qsort checking failed (error: qsort comparator
non-negative on sorted output: 0)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.0.0-alpha20200126 snapshot (g:787c79e559f5f011989b94298346d89542eb9052)
ICEs when compiling the following testcase w/ -O1 -fanalyzer:
void
mt (double);
void
nm (void)
{
double ao = 0.0;
long int es = -1;
mt (ao);
++ao;
mt (ao);
mt (*(double *) );
}
% gcc-10.0.0 -O1 -fanalyzer -c gneu3e9x.c
gneu3e9x.c: In function 'nm':
gneu3e9x.c:10:3: error: qsort comparator non-negative on sorted output: 0
10 | mt (ao);
| ^~~
during IPA pass: analyzer
gneu3e9x.c:10:3: internal compiler error: qsort checking failed
0x790d0b qsort_chk_error
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/vec.c:214
0x790e2a qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*, void*), void*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/vec.c:256
0x180d098 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/sort.cc:270
0x11000c3 vec::qsort(int (*)(void const*,
void const*))
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/vec.h:1125
0x11000c3 vec::qsort(int (*)(void const*, void
const*))
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/vec.h:1997
0x11000c3 ana::region_model::canonicalize(ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/region-model.cc:3756
0x10f4e5a ana::program_state::prune_for_point(ana::exploded_graph&,
ana::program_point const&, ana::state_change*) const
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/program-state.cc:868
0x10e1be7 ana::exploded_graph::get_or_create_node(ana::program_point const&,
ana::program_state const&, ana::state_change*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:1845
0x10e4b79 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:2456
0x10e5342 ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:2259
0x10e59c9 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:3580
0x10e6463 ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:3634
0x10dbf08 execute
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/analyzer-pass.cc:84
[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369 --- Comment #10 from Martin Liška --- (In reply to Jakub Jelinek from comment #9) > Even the git gcc-descr --full output can be shortened, use fewer sha digits I will then shorten it. > if you want, and the non---full output is something meant for the subjects, > r10-1234 is unique, ... but not a git approach (the hash is missing and one can't copy it to console, ...). > will be redirected to the right commit in gitweb by our > redirectors and is shorter than g: followed by 123456789abc.
[Bug tree-optimization/93397] [10 Regression] ICE in vect_create_epilog_for_reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93397 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Guenther : https://gcc.gnu.org/g:1442bc31da61a7f6c7d7c526e0449cfd9a917cd5 commit r10-6241-g1442bc31da61a7f6c7d7c526e0449cfd9a917cd5 Author: Richard Biener Date: Mon Jan 27 10:30:29 2020 +0100 tree-optimization/93397 delay converted reduction chain adjustment The following delays adjusting the SLP graph for converted reduction chains to a point where the SLP build no longer can fail since we otherwise fail to undo marking the conversion as a group. 2020-01-27 Richard Biener PR tree-optimization/93397 * tree-vect-slp.c (vect_analyze_slp_instance): Delay converted reduction chain SLP graph adjustment. * gcc.dg/torture/pr93397.c: New testcase.
[Bug tree-optimization/93397] [10 Regression] ICE in vect_create_epilog_for_reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93397 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/93439] [9/10 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |8.4 --- Comment #2 from Jakub Jelinek --- But I can confirm 7.x works and 8.x ICEs.
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 --- Comment #11 from rguenther at suse dot de --- On Sun, 26 Jan 2020, amonakov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 > > Alexander Monakov changed: > >What|Removed |Added > > CC||amonakov at gcc dot gnu.org > > --- Comment #7 from Alexander Monakov --- > (you mean unreachable code, not dead code) > > Nice find, this is definitely a bug. As you say, loop unswitching introduces > an > unconditional use of an uninitialized variable which otherwise is conditional > and (might be) never executed. The testcase hits a problematic early-out in > is_maybe_undefined: > > /* Uses in stmts always executed when the region header executes > are fine. */ > if (dominated_by_p (CDI_DOMINATORS, loop->header, gimple_bb (def))) > continue; > > the code does not match the comment, checking postdominators might be correct, > but not dominators. > > This was introduced by r245057 for PR71691, so technically a 8/9/10 > regression. > Probably worth splitting into a separate PR as this is more serious and might > be more straightforward to fix than the earlier testcases. Yes, as said, there are cases that need to be looked at and the above is definitely a bug.
[Bug analyzer/93438] ICE in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93438 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with addition of -fanalyzer in r10-5950-g757bf1dff5e8cee3.
[Bug tree-optimization/93434] [8/9/10 Regression] Miscompilation with -O3 starting from 8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93434 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #4 from rsandifo at gcc dot gnu.org --- Mine.
[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:e648e57efca6ce6d751ef8c2038608817b514fb4 commit r10-6247-ge648e57efca6ce6d751ef8c2038608817b514fb4 Author: Richard Sandiford Date: Sat Jan 18 12:41:48 2020 + lra: Stop registers being incorrectly marked live [PR92989] lra_assign has an assert to make sure that no pseudo is allocated to a conflicting hard register. It used to be restricted to !flag_ipa_ra, but in g:a1e6ee38e708ef2bdef4 I'd enabled it for flag_ipa_ra too. It then tripped while building libstdc++ for mips-mti-linux. The failure was due to code at the end of process_bb_lives. For an abnormal/EH edge, we need to make sure that all pseudos that are live on entry to the destination conflict with all hard registers that are clobbered by an abnormal call return. The usual way to do this would be to simulate a clobber of the hard registers, by making them live and them making them dead again. Making the registers live creates the conflict; making them dead again restores the correct live set for whatever follows. However, process_bb_lives skips the second step (making the registers dead again) at the start of a BB, presumably on the basis that there's no further code that needs a correct live set. The problem for the PR is that that wasn't quite true in practice. There was code further down process_bb_lives that updated the live-in set of the BB for some registers, and this live set was "contaminated" by registers that weren't live but that created conflicts. This information then got propagated to other blocks, so that registers that were made live purely to create a conflict at the start of the EH receiver then became needlessly live throughout preceding blocks. This in turn created a fake conflict with pseudos in those blocks, invalidating the choices made by IRA. The easiest fix seems to be to update the live-in set *before* adding the fake live registers. An alternative would be to simulate the full clobber, but that seems a bit wasteful. 2020-01-27 Richard Sandiford gcc/ PR rtl-optimization/92989 * lra-lives.c (process_bb_lives): Update the live-in set before processing additional clobbers.
[Bug rtl-optimization/93170] [10 Regression] wrong code due to use of a call-clobbered register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93170 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:150760dd6dd1899705790183d646fa5fc004554e commit r10-6246-g150760dd6dd1899705790183d646fa5fc004554e Author: Richard Sandiford Date: Sat Jan 18 10:59:10 2020 + cselib: Fix handling of multireg values for call insns [PR93170] g:3bd2918594dae34ae84f mishandled the case in which only the tail end of a multireg hard register is invalidated by the call. Walking all the entries should be both safer and more precise. Avoiding cselib_invalidate_regno also means that we no longer walk the same list multiple times (which is something we did before g:3bd2918594dae34ae84f too). 2020-01-27 Richard Sandiford gcc/ PR rtl-optimization/93170 * cselib.c (cselib_invalidate_regno_val): New function, split out from... (cselib_invalidate_regno): ...here. (cselib_invalidated_by_call_p): New function. (cselib_process_insn): Iterate over all the hard-register entries in REG_VALUES and invalidate any that cross call-clobbered registers. gcc/testsuite/ * gcc.dg/torture/pr93170.c: New test.
[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369 --- Comment #9 from Jakub Jelinek --- Even the git gcc-descr --full output can be shortened, use fewer sha digits if you want, and the non---full output is something meant for the subjects, r10-1234 is unique, will be redirected to the right commit in gitweb by our redirectors and is shorter than g: followed by 123456789abc.
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 --- Comment #10 from rguenther at suse dot de --- On Sun, 26 Jan 2020, ch3root at openwall dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 > > --- Comment #5 from Alexander Cherepanov --- > (In reply to rguent...@suse.de from comment #3) > > But the first use of the undefined value in the comparison makes > > everything wobbly. > > So `if (x == y)` is UB. Or `x == y` is already UB? I'd say "using" an uninitialized value is UB. Both of the above are a use. It possibly affects everything control-dependent (for the if) or value-dependent for the plain compare.
[Bug driver/91220] -Q --help=common displays options limited to subsets of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91220 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:e97a3063fb1936d6c36eeea720134d5675f73091 commit r10-6244-ge97a3063fb1936d6c36eeea720134d5675f73091 Author: Martin Liska Date: Mon Jan 27 11:01:26 2020 +0100 Filter out language specific options from --help=common. PR driver/91220 * opts.c (print_filtered_help): Exclude language-specific options from --help=common unless enabled in all FEs.
[Bug c/93435] Hang with -O2 on innocuous looking code with GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435 Martin Liška changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 Version|unknown |10.0 Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug c/93435] Hang with -O2 on innocuous looking code with GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Created attachment 47713 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47713=edit Perf report Confirmed, also current master is affected. We spend time in pass_dse.
[Bug other/93445] Misnamed git tags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93445 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 Ever confirmed|0 |1
[Bug rtl-optimization/93402] [8/9 Regression] Wrong code when returning padded struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93402 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug gcov-profile/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Component|tree-optimization |gcov-profile Target Milestone|--- |9.3
[Bug fortran/85781] ICE in gfc_build_array_ref, at fortran/trans.c:393
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85781 --- Comment #3 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:86075aa5dd0b1ed3f6c9c67d0d3058c6c5c19d65 commit r10-6240-g86075aa5dd0b1ed3f6c9c67d0d3058c6c5c19d65 Author: Tobias Burnus Date: Mon Jan 27 10:13:27 2020 +0100 fortran] Fix PR 85781, ICE on valid PR fortran/85781 * trans-expr.c (gfc_conv_substring): Handle non-ARRAY_TYPE strings of Bind(C) procedures. PR fortran/85781 * gfortran.dg/bind_c_char_2.f90: New. * gfortran.dg/bind_c_char_3.f90: New. * gfortran.dg/bind_c_char_4.f90: New. * gfortran.dg/bind_c_char_5.f90: New.
[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924 --- Comment #18 from Martin Liška --- I've got more detailed stats for current GCC master with 4 TOPN counters (default) and 8 TOPN counters: $ gcov-dump-analysis.py gcc-4 4 == Stats for gcc-4 == stats for indirect_call: total: 9210 freq: 5945890924 not executed at all: 6248 invalid: 669 (7.26%) freq:2216493157 (37.28%) only one target: 1788 (19.41%) freq:2259048939 (37.99%) useful values (with not one target): 0 values: 23 times (0.25%) freq:48188389 (0.81%) 1 values: 271 times (2.94%) freq: 1144170389 (19.24%) 2 values: 179 times (1.94%) freq: 200108367 (3.37%) 3 values: 32 times (0.35%) freq:77881683 (1.31%) 4 values:0 times (0.00%) freq: 0 (0.00%) Top 10 invalid counters: freq: 10.18%: [605586849, 0, -1, 0, 0, 0, 0, 0, 0] freq: 5.45%: [324297046, 0, -1, 0, 0, 0, 0, 0, 0] freq: 2.91%: [173094875, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.71%: [101484459, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.35%: [80265242, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.94%: [55609315, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.93%: [55570274, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.93%: [55570274, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.83%: [49637863, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.83%: [49463167, 0, -1, 0, 0, 0, 0, 0, 0] stats for topn: total: 1513 freq: 1760102743 not executed at all: 1028 invalid: 192 (12.69%) freq:1012619038 (57.53%) only one target: 147 (9.72%) freq:362167225 (20.58%) useful values (with not one target): 0 values:9 times (0.59%) freq: 4449793 (0.25%) 1 values: 80 times (5.29%) freq: 287605028 (16.34%) 2 values: 50 times (3.30%) freq:91203061 (5.18%) 3 values:7 times (0.46%) freq: 2058598 (0.12%) 4 values:0 times (0.00%) freq: 0 (0.00%) Top 10 invalid counters: freq: 27.71%: [487664454, 0, -1, 0, 0, 0, 0, 0, 0] freq: 3.84%: [67602541, 0, -1, 0, 0, 0, 0, 0, 0] freq: 3.35%: [58977259, 0, -1, 0, 0, 0, 0, 168, 10778] freq: 2.49%: [43823851, 0, -1, 0, 0, 0, 0, 0, 0] freq: 2.41%: [42335473, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.31%: [23140803, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.27%: [22339515, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.06%: [18680508, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.05%: [18468596, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.97%: [17042811, 0, -1, 0, 0, 8, 8986, 0, 0] $ gcov-dump-analysis.py gcc-8 8 == Stats for gcc-8 == stats for indirect_call: total: 9210 freq: 5945896994 not executed at all: 6248 invalid: 86 (0.93%) freq:1411998192 (23.75%) only one target: 1788 (19.41%) freq:2259051432 (37.99%) useful values (with not one target): 0 values:1 times (0.01%) freq: 23730 (0.00%) 1 values: 213 times (2.31%) freq: 1069863050 (17.99%) 2 values: 234 times (2.54%) freq: 559000644 (9.40%) 3 values: 253 times (2.75%) freq: 566516561 (9.53%) 4 values: 282 times (3.06%) freq:68094936 (1.15%) 5 values: 99 times (1.07%) freq:10628476 (0.18%) 6 values:6 times (0.07%) freq: 719973 (0.01%) 7 values:0 times (0.00%) freq: 0 (0.00%) 8 values:0 times (0.00%) freq: 0 (0.00%) Top 10 invalid counters: freq: 10.18%: [605586911, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 723230572, 84092, 1139593113, 84612] freq: 5.45%: [324297850, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] freq: 2.91%: [173094959, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] freq: 1.35%: [80265372, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] freq: 0.83%: [49637931, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] freq: 0.39%: [22933816, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] freq: 0.30%: [17614204, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] freq: 0.24%: [13977669, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] freq: 0.23%: [13907686, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] freq: 0.21%: [12233528, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] stats for topn: total: 1513 freq: 1760099471 not executed at all: 1028 invalid: 133 (8.79%) freq:888710548 (50.49%) only one target: 147 (9.72%) freq:362167643 (20.58%) useful values (with not one target): 0 values:8 times (0.53%) freq:23626986 (1.34%) 1 values: 72 times (4.76%) freq: 171882763 (9.77%) 2 values: 74 times (4.89%) freq: 243855009 (13.85%) 3 values: 34 times (2.25%) freq:44981550 (2.56%) 4 values: 13 times (0.86%) freq:24863705 (1.41%) 5 values:2 times (0.13%) freq: 287 (0.00%) 6 values:1 times (0.07%) freq: 10 (0.00%) 7 values:1 times (0.07%) freq: 10970 (0.00%) 8 values:0 times (0.00%) freq: 0 (0.00%) Top 10 invalid counters: freq: 27.71%: [487664555, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 40, 75356, 64, 99276, 0, 0] freq: 3.84%: [67601993,
[Bug target/93274] target_clones produces symbols with random digits with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93274 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:c2bd2b4664be8b73f8fd58a64dec1e93871797cc commit r10-6242-gc2bd2b4664be8b73f8fd58a64dec1e93871797cc Author: Martin Liska Date: Mon Jan 27 10:48:18 2020 +0100 Do not generate a unique fnname for resolver. PR target/93274 * config/i386/i386-features.c (make_resolver_func): Align the code with ppc64 target implementation. Do not generate a unique name for resolver function. PR target/93274 * gcc.target/i386/pr81213.c: Adjust to not expect a globally unique name.
[Bug c++/93446] Improve -Wconversion warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93446 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Before GCC 8 we just said: c.cc:2:14: warning: conversion to 'char' alters 'int' constant value [-Wconversion] The diagnostic changed with r248431 for PR 80731.
[Bug tree-optimization/93407] Dead partial memset not optimized away (clang does that)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93407 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Can you provide a standalone testcase? The inlined call you show seems to have constant code/mode arguments.
[Bug bootstrap/93409] [10 Regression] gcn libgomp plugin fails to build for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409 Richard Biener changed: What|Removed |Added Target||gcn Target Milestone|--- |10.0
[Bug libstdc++/93426] fix typo in span
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93426 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:389cd88ce797e2a4345eab8db478a3b8eba798e8 commit r10-6248-g389cd88ce797e2a4345eab8db478a3b8eba798e8 Author: Jonathan Wakely Date: Mon Jan 27 10:30:03 2020 + libstdc++: Fix deduction guide for std::span (PR93426) The deduction guide from an iterator and sentinel used the wrong alias template and so didn't work. PR libstdc++/93426 * include/std/span (span): Fix deduction guide. * testsuite/23_containers/span/deduction.cc: New test.
[Bug tree-optimization/93439] [9/10 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439 --- Comment #3 from Jakub Jelinek --- I'd say the bug is that we parallelize a loop (loop 7) which has two inner loops (loop 10 and loop 8) and then have some code to avoid trying to parallelize inner loops of the already parallelized loop, but the skip_loop stuff simply assumes that there can be at most one inner loop of a parallelized loop. Now, I don't know if it is incorrect to try to parallelize a loop with more than one inner loop, or if the skip_loop stuff needs adjusting, so that we don't skip just one, but all inner loops of already parallelized loops.
[Bug libstdc++/93426] fix typo in span
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93426 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed, thanks for the report. For the record, this was a regression introduced by r279000.
[Bug tree-optimization/93444] [8/9/10 Regression] ssa-loop-im introduces unconditional use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- With -O3 -ftree-vectorize -ftree-loop-vectorize I see it started is somewhere in between: r6-3810-g170f473b525d0af69dc4577186762a3519b952a4 and r6-3731-g85339618b6ba3edab19d8bd98eb19d8c5627c276 Revisions in between: 78
[Bug tree-optimization/93444] [8/9/10 Regression] ssa-loop-im introduces unconditional use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444 --- Comment #3 from Andrew Pinski --- (In reply to Martin Liška from comment #2) > With -O3 -ftree-vectorize -ftree-loop-vectorize I see it started is > somewhere in between: > > r6-3810-g170f473b525d0af69dc4577186762a3519b952a4 > and > r6-3731-g85339618b6ba3edab19d8bd98eb19d8c5627c276 > Revisions in between: 78 Most likely: g:a01e93f11b7ce050679951dedae66e40bca6be4d
[Bug libgomp/93219] unused return value in affinity-fmt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #8 from Eric Gallager --- This is one of those cases where it would be helpful to have bug 66425 fixed
[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369 --- Comment #11 from Jakub Jelinek --- (In reply to Martin Liška from comment #10) > > if you want, and the non---full output is something meant for the subjects, > > r10-1234 is unique, > > ... but not a git approach (the hash is missing and one can't copy it to > console, ...). Well, you can, but it can't be used directly by git, but needs to go through git gcc-undescr first. But if the commit has it in some comment in the PR, IMHO it is completely sufficient to have the shortened form in the subject.
[Bug analyzer/93450] ICE in real_maxval, at real.c:2593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93450
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
void bar (int);
double
foo (void)
{
double x = __builtin_huge_val ();
bar (0);
return x;
}
The ICE is because analyzer tries to simplify comparison of integer 0 with the
real Inf constant. That is incorrect, one can only compare comparable types.
Don't see how the 0 is in any way related to the floating point values in this
testcase.
[Bug c++/93442] [8/9/10 Regression] lambda in if constexpr fails to compile since r8-5529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93442 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/93442] [8/9/10 Regression] lambda in if constexpr fails to compile since r8-5529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93442 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||jakub at gcc dot gnu.org, ||nathan at gcc dot gnu.org Target Milestone|--- |8.4 Summary|lambda in if constexpr |[8/9/10 Regression] lambda |fails to compile|in if constexpr fails to ||compile since r8-5529 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r8-5529-gc0a499af71a7cec55590a74b66c386cfcb11aed6 aka PR83406 fix.
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #9 from rguenther at suse dot de ---
On Sun, 26 Jan 2020, ch3root at openwall dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
>
> --- Comment #4 from Alexander Cherepanov ---
> (In reply to Richard Biener from comment #1)
> > guess DOM would also happily propagate equivalences
>
> Yeah, this gives a simpler testcase:
>
> --
> #include
>
> __attribute__((noipa)) // imagine it in a separate TU
> static int opaque(int i) { return i; }
>
> int main()
> {
> unsigned char x = opaque(1);
> unsigned char y;
> (void)
>
> if (x - 1 == y) {
> printf("x = %d; x - 1 = %d\n", x, opaque(1) ? x - 1 : 5);
> opaque(y);
> }
> }
> --
> $ gcc -std=c11 test.c && ./a.out
> x = 1; x - 1 = 0
> $ gcc -std=c11 -O3 test.c && ./a.out
> x = 1; x - 1 = 5
This example simply shows that we're propagating the equivalence
y == x - 1 in the way that the controlled x - 1 becomes y (that's
possibly a QOI issue in this particular case where we _do_ see
that y is not initialized - but as said in general we cannot know)
and that we then optimize condition ? uninit : 5 as 5 (we're
optimistically treating uninit equal to 5 here which is OK).
Note the (void) doesn't do anything but it really looks like
it is required to make the testcase conforming (otherwise you
wouldn't use it?). If it is supposed to make y allocated to memory
then I have to say it doesn't (but yeah, allocating it to memory
would make it's value somewhat stable until we start optimizing
loads from uninitialized memory to a random uninitialized register...).
That said, the stmt doesn't have any persistent effect on GCCs IL
(it's eliminated quickly as not needed).
[Bug target/93274] target_clones produces symbols with random digits with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93274 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- Fixed on trunk, probably not planning to backport.
[Bug tree-optimization/92822] [10 Regression] vfma_laneq_f32 and vmul_laneq_f32 are broken on aarch64 after r278938
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92822 --- Comment #6 from Richard Biener --- (In reply to rsand...@gcc.gnu.org from comment #5) > I think this is mostly a target problem. We weren't providing > patterns to extract a 64-bit vector from a 128-bit vector, > despite that being very much a native operation. > > Adding those fixes most of the problems. What's left is that: > > v4sf_b = VEC_PERM_EXPR ; > ...extract first half of v4sf_b... > > gets filled out as: > > v4sf_b = VEC_PERM_EXPR ; > ...extract first half of v4sf_b... > > and we never recover from the awkwardness of that permute. > The easiest fix seems to be to extend a partial duplicate > to a full duplicate instead of a partial duplicate followed > by a partial blend. The ugliness is that all this "heuristics" need to be in the permutation detection code since we can't encode a "we do not care" value in the permute mask. A way out (with more GIMPLE stmts) would have been to avoid the "do not care" elements. In this particular case we only need the lower part anyway... I'm going to try some heuristic tweaking for PR92819 (not this week but maybe next ...), the simplify_vector_constructor function is already quite complicated and providing testsuite coverage for all paths is hard...
[Bug analyzer/93451] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93451 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with addition of -fanalyzer in r10-5950-g757bf1dff5e8cee3.
[Bug rtl-optimization/87763] [9/10 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #62 from rsandifo at gcc dot gnu.org
---
So to summarise this long PR, for my own sanity if nothing else,
the remaining failures are:
FAIL: gcc.target/aarch64/insv_1.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 0, 8
FAIL: gcc.target/aarch64/insv_1.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 16, 5
FAIL: gcc.target/aarch64/insv_1.c scan-assembler movk\tx[0-9]+, 0x1d6b, lsl 32
FAIL: gcc.target/aarch64/lsl_asr_sbfiz.c scan-assembler sbfiz\tw
For the two bfi ones: are we really sure that the old code is better?
It's a difference between a MOV and a BFI or an AND and an ORR.
The BFI wins (at least for code-size) if we need the same MOV
for something else. But the AND/ORR sequence wins in high register
pressure, since it only needs one register rather than two.
It could also be better if several changes are being made to the
same structure. We can't really expect to make a good choice
between these in a peephole pass like combine.
So IMO we should just accept the BFI changes for these particular
structures and constants. We can then file a new PR for constant
insertions that can't use ORR.
For the MOVK one, I agree with Segher in comment 42 that this
is just a missing pattern. We should also be using MOVK for:
typedef __UINT64_TYPE__ uint64_t;
uint64_t f (uint64_t x) { return (x & ~(uint64_t) 0x) | 0x1234; }
and there's no reason to expect this to be converted into a
zero_extract lhs.
gcc.target/aarch64/lsl_asr_sbfiz.c is IMO due to an overly restrictive
case in simplify-rtx.c, have a patch for that.
[Bug target/86487] [8 Regression] insn does not satisfy its constraints on arm big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487 --- Comment #15 from avieira at gcc dot gnu.org --- Jeff seems to have backported this to gcc-8 already, so I guess we can close this?
[Bug tree-optimization/93404] [10 regression] -O2 and -O2 -flto SPEC2006 and 2017 code size regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93404 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||rguenth at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #2 from Richard Biener --- The init sequence for CODE/MODE is indeed weird. I'd have expected the inits to be merged with the previous zeroing when those args are constants (which they usually are?). Guess the bitfield-ness doesn't play well here. Maybe sth for store-merging (but that runs quite late). Definitely something for a separate bugreport with a shorter testcase.
[Bug bootstrap/93416] [10 Regression] ICE in in tree_cmp, at analyzer/region-model.cc:1851 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93416 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c/93432] variable is used uninitialized, but gcc shows no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432 --- Comment #2 from Richard Biener --- The one involving constants and PHIs. The (late) uninit warning is too late to catch this since we optimized the uninit use away. We probably diagnose it if you initialize z from a function parameter rather than a constant.
[Bug fortran/93427] [10 Regression] Rejects valid with pointer result from recursive function since r10-5722-g4d124378848e82e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93427 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||9.2.0 Target Milestone|--- |10.0 Summary|Rejects valid with pointer |[10 Regression] Rejects |result from recursive |valid with pointer result |function|from recursive function ||since ||r10-5722-g4d124378848e82e5 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-5722-g4d124378848e82e5.
[Bug tree-optimization/93428] [10 Regression] ICE in vect_transform_slp_perm_load since r10-4800-g10a73df76280e128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93428 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/93407] Dead partial memset not optimized away (clang does that)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93407 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug bootstrap/93416] [10 Regression] ICE in in tree_cmp, at analyzer/region-model.cc:1851 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93416 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/93435] [8/9/10 Regression] Hang with -O2 on innocuous looking code with GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435 Richard Biener changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Component|c |tree-optimization Target Milestone|10.0|8.4 --- Comment #4 from Richard Biener --- So SRA probably shouldn't do that. Somehow it passed unsigned HOST_WIDE_INT max_scalarization_size = get_move_ratio (optimize_speed_p) * UNITS_PER_WORD; which is a bit of an odd thing since we test it against if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var))) <= max_scalarization_size) later (UNITS vs. bits). MOVE_RATIO can be as big as 17 on x86_64 (which is also the default), times 8 that's 136 bytes - but we test against bits above, so I don't see how it qualifies... Then tree DSE does have some rate-limiting of its walks as well.
[Bug bootstrap/93409] [10 Regression] gcn libgomp plugin fails to build for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409 Martin Liška changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW URL||https://gcc.gnu.org/ml/gcc- ||patches/2020-01/msg01663.ht ||ml Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/93439] [9/10 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index fd69b366bf4..db46af25d33 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -3226,6 +3226,13 @@ verify_types_in_gimple_reference (tree expr, bool
require_lvalue)
debug_generic_stmt (expr);
return true;
}
+ if (MR_DEPENDENCE_CLIQUE (expr) > 1
+ && MR_DEPENDENCE_CLIQUE (expr) > cfun->last_clique)
+ {
+ error ("invalid clique in %qs", code_name);
+ debug_generic_stmt (expr);
+ return true;
+ }
}
else if (TREE_CODE (expr) == TARGET_MEM_REF)
{
@@ -3245,6 +3252,13 @@ verify_types_in_gimple_reference (tree expr, bool
require_lvalue)
debug_generic_stmt (expr);
return true;
}
+ if (MR_DEPENDENCE_CLIQUE (expr) > 1
+ && MR_DEPENDENCE_CLIQUE (expr) > cfun->last_clique)
+ {
+ error ("invalid clique in %qs", code_name);
+ debug_generic_stmt (expr);
+ return true;
+ }
}
else if (TREE_CODE (expr) == INDIRECT_REF)
{
shows
f951: Error: invalid clique in ‘mem_ref’
MEM [(real(kind=8)[0:D.3937] *)p5.78_5];
# VUSE <.MEM_66>
_57 = MEM [(real(kind=8)[0:D.3937] *)p5.78_5][_56];
...
during GIMPLE pass: fixup_cfg
f951: internal compiler error: verify_gimple failed
0x13f8a41 verify_gimple_in_cfg(function*, bool)
/space/rguenther/src/gcc/gcc/tree-cfg.c:5459
so that's the IL created by parloop outlining which is fed back as new
function to the main optimization pipeline.
I will have a look - the unroll-and-jam ICE is simply the only place this
is verified currently.
[Bug libstdc++/93325] libstdc++ wrongly uses direct clock_gettime syscall on non-glibc, breaks time64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93325 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > In general we can't use link tests in configure, for reasons related to > cross-compilers that I don't understand. As far as I can tell, that's only relevant for bare metal targets, which is why I think link tests are OK for hosted linux* targets.
[Bug target/92692] [9 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692 --- Comment #18 from CVS Commits --- The releases/gcc-9 branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:a708cb25d9284e9234b6457f8260bfc79f09043e commit r9-8180-ga708cb25d9284e9234b6457f8260bfc79f09043e Author: Wilco Dijkstra Date: Fri Jan 17 13:17:21 2020 + [AArch64] Fix shrinkwrapping interactions with atomics (PR92692) The separate shrinkwrapping pass may insert stores in the middle of atomics loops which can cause issues on some implementations. Avoid this by delaying splitting atomics patterns until after prolog/epilog generation. gcc/ PR target/92692 * config/aarch64/aarch64.c (aarch64_split_compare_and_swap) Add assert to ensure prolog has been emitted. (aarch64_split_atomic_op): Likewise. * config/aarch64/atomics.md (aarch64_compare_and_swap) Use epilogue_completed rather than reload_completed. (aarch64_atomic_exchange): Likewise. (aarch64_atomic_): Likewise. (atomic_nand): Likewise. (aarch64_atomic_fetch_): Likewise. (atomic_fetch_nand): Likewise. (aarch64_atomic__fetch): Likewise. (atomic_nand_fetch): Likewise. (cherry picked from commit e5e07b68187b9aa334519746c45b8cffc5eb7e5c)
[Bug tree-optimization/93444] [8/9/10 Regression] ssa-loop-im introduces unconditional use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
--- Comment #6 from rguenther at suse dot de ---
On Mon, 27 Jan 2020, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
>
> --- Comment #5 from Alexander Monakov ---
> The problem is lifting a conditional access. We don't have an example where
> lifting an invariant from an always-executed block in a loop to its preheader
> poses a problem.
>
> LLVM adopted an approach where hoisting must "freeze" the "poisoned" values
> resulting from uninitialized access so they acquire a concrete unpredictable
> value: https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf
Interesting. GCC definitely has "undef", we at least do not explicitely
have "poison" (I'm not fully understanding the difference). GCC also
doesn't really formally define the effect of "undef" operands on any
IL construct (well, or formally define the IL at all ...).
But yeah, if you introduce "freeze" you basically add a proper
definition for something formerly undefined with the semantic
obtaining a stable value.
Not sure if that's really desirable though.
The paper also doesn't go into any detail on undefs that are
"merely" not proven to be not defined. If you take for example
static void foo (int i, int j)
{
if (i == j)
return i;
return j;
}
int main(int argc)
{
int undef;
return foo(argc, undef);
}
if you transform foo to a plain return j; which GCC would do
you only figure after inlining the function that j is actually
undefined. Probably the example is bad.
[Bug sanitizer/89215] UBSAN leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89215 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 Ever confirmed|0 |1
[Bug c++/91023] Unification Fails for parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91023 Martin Liška changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I can confirm it fails since the introduction of -std=c++17. Clang accepts the code.
[Bug c/91046] missing warning about empty translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91046 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/91038] ICE with VLA type and statement expression (gimplify_var_or_parm_decl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91038 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed.
[Bug c/93432] variable is used uninitialized, but gcc shows no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug ipa/93429] Missed IPA-CP on by-ref argument directly passed through from caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93429 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/93431] FAIL: g++.dg/cpp2a/lambda-uneval9.C -std=c++2a (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93431 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/93424] ICE on valid with pointer result from submodule function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93424 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, it's at least as old as GCC 4.8.0.
[Bug fortran/93423] [8/9/10 Regression] ICE on invalid with argument list for module procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93423 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Summary|ICE on invalid with |[8/9/10 Regression] ICE on |argument list for module|invalid with argument list |procedure |for module procedure Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started to ICE with r6-1958-g4668d6f9c00d4767.
[Bug sanitizer/93436] [9 Regression] ICE during GIMPLE pass: sanopt with -fsanitize=address -fdump-tree-sanopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93436 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||10.0
[Bug tree-optimization/93404] [10 regression] -O2 and -O2 -flto SPEC2006 and 2017 code size regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93404 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/93426] fix typo in span
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93426 --- Comment #4 from merukun1125 at docomo dot ne.jp --- Thanks!
[Bug preprocessor/93452] [10 Regression] __has_include changes broke compilation of -fdirectives-only preprocessed sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93452 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|c |preprocessor Target Milestone|--- |10.0
[Bug libstdc++/93325] libstdc++ wrongly uses direct clock_gettime syscall on non-glibc, breaks time64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93325 --- Comment #1 from Jonathan Wakely --- In general we can't use link tests in configure, for reasons related to cross-compilers that I don't understand. But I think link tests should always work for linux* targets, and to be extra cautious we can skip doing it for freestanding builds: --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -1422,21 +1422,15 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [ ac_has_nanosleep=yes ;; gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu) -AC_MSG_CHECKING([for at least GNU libc 2.17]) -AC_TRY_COMPILE( - [#include ], - [ - #if ! __GLIBC_PREREQ(2, 17) - #error - #endif - ], - [glibcxx_glibc217=yes], [glibcxx_glibc217=no]) -AC_MSG_RESULT($glibcxx_glibc217) - -if test x"$glibcxx_glibc217" = x"yes"; then - ac_has_clock_monotonic=yes - ac_has_clock_realtime=yes -fi + # Don't use link test for freestanding library, in case gcc_no_link=yes + if test x"$is_hosted" = xyes; then + # Versions of glibc before 2.17 needed -lrt for clock_gettime. + AC_SEARCH_LIBS(clock_gettime, [rt]) + if test x"$ac_cv_search_clock_gettime" = x"none required"; then + ac_has_clock_monotonic=yes + ac_has_clock_realtime=yes + fi + fi ac_has_nanosleep=yes ac_has_sched_yield=yes ;; For a freestanding build this means we could still end up setting ac_has_clock_monotonic_syscall=yes and defining _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL=1 but we won't try to build src/c++11/chrono.cc for freestanding, so it's harmless.
[Bug c++/91013] member function can have same name as constructor if declared using a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91013 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug preprocessor/91037] #pragma GCC diagnostic ignored "-Wunused-macros" ignored for doubly-defined macro with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91037 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug tree-optimization/93428] [10 Regression] ICE in vect_transform_slp_perm_load since r10-4800-g10a73df76280e128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93428 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Known to work||9.2.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |10.0 Summary|[10 Regression] ICE in |[10 Regression] ICE in |vect_transform_slp_perm_loa |vect_transform_slp_perm_loa |d |d since ||r10-4800-g10a73df76280e128 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Started with r10-4800-g10a73df76280e128.
[Bug c++/93420] Deducing "T C::* const&" from a non-const pointer-to-member-function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93420 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed. Both clang and ICC accept the code.
[Bug tree-optimization/93440] scalar unrolled loop makes vectorized code unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93440 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||rguenth at gcc dot gnu.org Blocks||53947 --- Comment #2 from Richard Biener --- Hmm, I get /home/space/rguenther/install/gcc-9.2/include/c++/9.2.0/pstl/execution_defs.h:155:7: error: no type named ‘type’ in ‘struct std::enable_if’ 155 | using __enable_if_execution_policy = | ^~~~ trying to compile this with the FSF 9.2.0 release. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c/93452] New: [10 Regression] __has_include changes broke compilation of -fdirectives-only preprocessed sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93452
Bug ID: 93452
Summary: [10 Regression] __has_include changes broke
compilation of -fdirectives-only preprocessed sources
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
$ cat a.c
int main () { return 0; }
$ ./xgcc -B ./ -E -fdirectives-only a.c -o a2.c; ./xgcc -B ./ -w -S a2.c -o
a2.s
works just fine in GCC 9 and earlier (the -w is just to shut up warnings about
redefined macros). But it is rejected by the trunk
: error: "__has_include" cannot be used as a macro name
: error: "__has_include_next" cannot be used as a macro name
As -fdirectives-only preprocessing is something that is extremely useful for
preserving token locations, macro origins etc., which normal preprocessing
throws away, I think this is pretty serious.
Can't we just not define __has_include/__has_include_next as macros through
#define at all and just let defined/ifdef/ifndef special case those, or
alternative not print the #define __has_include __has_include in -dD or
-fdirectives-only?
[Bug target/91117] _mm_movpi64_epi64/_mm_movepi64_pi64 generating store+load instead of using MOVQ2DQ/MOVDQ2Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91117 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug sanitizer/91118] ubsan does not work with openmp default (none) directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91118 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r9-3941-g28567c40e2c7c88e. @Jakub: Can you please take a look?
[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272 Andreas Krebbel changed: What|Removed |Added Attachment #47656|0 |1 is obsolete|| --- Comment #3 from Andreas Krebbel --- Created attachment 47714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47714=edit IRA EH fix - only when added at start of BB A probably better version of the fix. This version only reverts the allocation decision if the move is about to be added at the start of an EH basic block.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|10.0|9.3
[Bug fortran/93422] Bogus POINTER attribute mismatch with submodule MODULE PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93422 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- It's very old issue, at least as GCC 4.8.0.
[Bug tree-optimization/93444] [8/9/10 Regression] ssa-loop-im introduces unconditional use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Milestone|--- |8.4
--- Comment #4 from Richard Biener ---
Isn't this kind-of PR39612? I realize that was store-motion and here's
invariant motion.
I also note that more aggressively "optimizing" things like
_7 = (int) y_21(D);
would have allowed propagation of the uninitialized use to a context where
it isn't used invariantly. That is, optimize the above to
_9(D);
introduce an uninit register of 'int' type and optimize (int) y_21(D) to that.
Goes away with useful warnings about the uninit use because _9(D) would be
unnamed (we could use sth named y as well but it would technically be a
different
y).
For the special case of uninitialized SSA names (but not loads from
uninitialized
memory as in PR39612) we can "easily" fix LIM here:
static class loop *
outermost_invariant_loop (tree def, class loop *loop)
{
...
def_stmt = SSA_NAME_DEF_STMT (def);
def_bb = gimple_bb (def_stmt);
if (!def_bb)
return superloop_at_depth (loop, 1);
return NULL if ssa_undefined_value_p (def, true) with a comment explaining
things.
[Bug c/93432] variable is used uninitialized, but gcc shows no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432 --- Comment #3 from Sven --- I'm not sure how you optimize the uninit use away. When running the example, the first printf typically yields a random value. So the uninitialized value is certainly used as a return value.
[Bug preprocessor/93452] [10 Regression] __has_include changes broke compilation of -fdirectives-only preprocessed sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93452 --- Comment #1 from Jakub Jelinek --- Started with r10-6092-gad1a3914ae8d67c94b0d2428e3f9672e7db491a1
[Bug other/91085] fixincludes breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Is this still an issue?
[Bug libstdc++/91018] std::??clusive_scan vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91018 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/91015] Which is correct working on polymorphic assignment...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91015 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please tell me what's expected output of the compiler program?
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #6 from Jakub Jelinek --- I'll have a look.
[Bug c++/93425] [9/10 Regression] Template parameter deduction failure when template parameters have template template parameter since r9-3807-g5d9a0e3b99e31a21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93425 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-27 CC||marxin at gcc dot gnu.org Known to work||8.3.0 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |9.3 Summary|Template parameter |[9/10 Regression] Template |deduction failure when |parameter deduction failure |template parameters have|when template parameters |template template parameter |have template template ||parameter since ||r9-3807-g5d9a0e3b99e31a21 Ever confirmed|0 |1 Known to fail||10.0, 9.2.0 --- Comment #2 from Martin Liška --- Confirmed, started with r9-3807-g5d9a0e3b99e31a21.
[Bug tree-optimization/93327] Performance degradation of povray benchmark from gcc 8.3.1 to gcc 9.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93327 --- Comment #2 from Chen Ming --- Sorry for my late response. I'll confirm and update the compiler options here.
[Bug tree-optimization/93444] [8/9/10 Regression] ssa-loop-im introduces unconditional use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444 --- Comment #5 from Alexander Monakov --- The problem is lifting a conditional access. We don't have an example where lifting an invariant from an always-executed block in a loop to its preheader poses a problem. LLVM adopted an approach where hoisting must "freeze" the "poisoned" values resulting from uninitialized access so they acquire a concrete unpredictable value: https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf
