[Bug libstdc++/93502] std::regex_match uses stack space proportional to input string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93502 --- Comment #5 from Jonathan Wakely --- (In reply to Richard Biener from comment #3) > Another question would be whether it's easy for the programmer to direct > std::regex_match to use the heap? No that's not possible.
[Bug libstdc++/93502] std::regex_match uses stack space proportional to input string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93502 --- Comment #4 from Jonathan Wakely --- (In reply to Nadav Har'El from comment #2) > Maybe you mean it is a dup of > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 ? Yes that's what I was thinking of. > But I'm not sure. I honestly don't understand the conclusion there that ".*" > is implemented recursively. Why would such a simple case, easily converted > to a deterministic finite automaton with no memory usage at all - need > recursion? Nobody said it *needs* recursion, that's just how it's implemented today.
[Bug target/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.4 --- Comment #3 from Richard Biener --- Just to quote x = x >> __builtin_bswap64 (-a) | x << (-__builtin_bswap64 (-a) & 31); with a == ~0. The right shift argument is > 31 which makes its behavior undefined. Does adding a & 31 help?
[Bug target/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505 --- Comment #4 from Zdenek Sojka --- (In reply to Andrew Pinski from comment #1) > I think this code is undefined Thank you for having a look. -fsanitize=undefined doesn't complain. x = x >> __builtin_bswap64 (-a) | x << (-__builtin_bswap64 (-a) & 31); a == 0, so -a == 0, so bswap(-a) == 0, so -bswap(-a) == 0, so everything should be OK (in the non-reduced testcase, there were & 31 in the right-hand operand of both shifts, so it was always defined) (In reply to Richard Biener from comment #3) > Just to quote > > x = x >> __builtin_bswap64 (-a) | x << (-__builtin_bswap64 (-a) & 31); > > with a == ~0. The right shift argument is > 31 which makes its behavior > undefined. Does adding a & 31 help? a == 0, x == ~0
[Bug target/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505 --- Comment #5 from Zdenek Sojka --- Created attachment 47738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47738&action=edit only partially reduced testcase, with always defined shifts It also needs more flags to reproduce: -Os -fno-expensive-optimizations -fno-forward-propagate -fno-inline -fno-ipa-vrp -fno-tree-bit-ccp -fno-tree-ter (not all of those are needed; switching to -Og might help to reduce the number of needed flags) I've just deleted my gcc repo + binaries, so I can't test it atm.
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it's old (at least 4.8.0+).
[Bug fortran/93498] [9/10 Regression] ICE in gfc_resolve_findloc, at fortran/iresolve.c:1844 since r9-3688-g01ce9e31a02c8039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93498 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Known to work||8.3.0 Target Milestone|--- |9.3 Summary|ICE in gfc_resolve_findloc, |[9/10 Regression] ICE in |at fortran/iresolve.c:1844 |gfc_resolve_findloc, at ||fortran/iresolve.c:1844 ||since ||r9-3688-g01ce9e31a02c8039 Ever confirmed|0 |1 Known to fail||10.0, 9.2.0 --- Comment #2 from Martin Liška --- Confirmed, started with r9-3688-g01ce9e31a02c8039.
[Bug fortran/93499] ICE in gfc_zero_size_array, at fortran/arith.c:1686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93499 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, all my releases ICE (4.8.0+).
[Bug fortran/93500] ICE in gfc_numeric_ts, at fortran/expr.c:891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93500 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, all releases I have ICE (4.8.0+).
[Bug fortran/93501] [10 regression] gfortran.dg/pr93473.f90 ICEs starting with r10-6295
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93501 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #25 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2595f25cdaf4f16d04a1078a487b2ecc126cae29
commit r10-6344-g2595f25cdaf4f16d04a1078a487b2ecc126cae29
Author: Jakub Jelinek
Date: Thu Jan 30 09:35:03 2020 +0100
fortran: Fix up ISO_Fortran_binding_15.f90 failures [PR92123]
This is something that has been discussed already a few months ago, but
seems to have stalled. Here is Paul's patch from the PR except for the
TREE_STATIC hunk which is wrong, and does the most conservative fn spec
tweak for the problematic two builtins we are aware of (to repeat what is
in
the PR, both .wR and .ww are wrong for these builtins that transform one
layout of an descriptor to another one; while the first pointer is properly
marked that we only store to what it points to, from the second pointer
we copy and reshuffle the content and store into the first one; if there
wouldn't be any pointers, ".wr" would be just fine, but as there is a
pointer and that pointer is copied to the area pointed by first argument,
the pointer effectively leaks that way, so we e.g. can't optimize stores
into what the data pointer in the descriptor points to). I haven't
analyzed other fn spec attributes in the FE, but think it is better to
fix at least this one we have analyzed.
2020-01-30 Paul Thomas �
Jakub Jelinek
PR fortran/92123
* trans-decl.c (gfc_get_symbol_decl): Call gfc_defer_symbol_init for
CFI descs.
(gfc_build_builtin_function_decls): Use ".w." instead of ".ww" or ".wR"
for gfor_fndecl_{cfi_to_gfc,gfc_to_cfi}.
(convert_CFI_desc): Handle references to CFI descriptors.
Co-authored-by: Paul Thomas
[Bug target/91824] unnecessary sign-extension after _mm_movemask_epi8 or __builtin_popcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91824 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b285bebe6ad1e9f6416f0eb6cb69edc44db7813c commit r10-6345-gb285bebe6ad1e9f6416f0eb6cb69edc44db7813c Author: Jakub Jelinek Date: Thu Jan 30 09:39:05 2020 +0100 i386: Optimize popcnt followed by zero/sign extension [PR91824] Like any other instruction with 32-bit GPR destination operand in 64-bit mode, popcntl also clears the upper 32 bits of the register (and other bits too, it can return only 0 to 32 inclusive). During combine, the zero or sign extensions of it show up as paradoxical subreg of the popcount & 63, there 63 is the smallest power of two - 1 mask that can represent all the 0 to 32 inclusive values. 2020-01-30 Jakub Jelinek PR target/91824 * config/i386/i386.md (*popcountsi2_zext): New define_insn_and_split. (*popcountsi2_zext_falsedep): New define_insn. * gcc.target/i386/pr91824-1.c: New test.
[Bug target/91824] unnecessary sign-extension after _mm_movemask_epi8 or __builtin_popcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91824
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d37c81f476c17d292943189335d745c3fb817b7d
commit r10-6346-gd37c81f476c17d292943189335d745c3fb817b7d
Author: Jakub Jelinek
Date: Thu Jan 30 09:41:00 2020 +0100
i386: Optimize {,v}{,p}movmsk{b,ps,pd} followed by sign extension [PR91824]
Some time ago, patterns were added to optimize move mask followed by zero
extension from 32 bits to 64 bit. As the testcase shows, the intrinsics
actually return int, not unsigned int, so it will happen quite often that
one actually needs sign extension instead of zero extension. Except for
vpmovmskb with 256-bit operand, sign vs. zero extension doesn't make a
difference, as we know the bit 31 will not be set (the source will have 2
or
4 doubles, 4 or 8 floats or 16 or 32 chars).
So, for the floating point patterns, this patch just uses a code iterator
so that we handle both zero extend and sign extend, and for the byte one
adds a separate pattern for the 128-bit operand.
2020-01-30 Jakub Jelinek
PR target/91824
* config/i386/sse.md
(*_movmsk_zext): Renamed to ...
(*_movmsk_ext): ... this. Use
any_extend code iterator instead of always zero_extend.
(*_movmsk_zext_lt): Renamed to ...
(*_movmsk_ext_lt): ... this.
Use any_extend code iterator instead of always zero_extend.
(*_movmsk_zext_shift): Renamed to
...
(*_movmsk_ext_shift): ... this.
Use any_extend code iterator instead of always zero_extend.
(*sse2_pmovmskb_ext): New define_insn.
(*sse2_pmovmskb_ext_lt): New define_insn_and_split.
* gcc.target/i386/pr91824-2.c: New test.
[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 #21 from Martin Liška ---
(In reply to Jan Hubicka from comment #20)
> And thanks for the gcov-analysis improvemnets. It is quite handy tool now :)
Good to hear.
> and it is interesting to know where the many-target calls are. Clearly there
> is not much to win on walk_tree, but I guess it all depends whether program
> has a clal that is important or not.
>
> == Stats for firefox-gcda/ ==
> stats for indirect_call:
> total: 160441 freq: 855229359
> not executed at all: 134863
> invalid: 541 (0.34%) freq:283079441 (33.10%)
> only one target: 20073 (12.51%) freq:212875999 (24.89%)
> useful values (with not one target):
> 0 values: 86 times (0.05%) freq:12966679 (1.52%)
> 1 values: 2698 times (1.68%) freq: 266471761 (31.16%)
> 2 values: 2077 times (1.29%) freq:79089916 (9.25%)
> 3 values: 102 times (0.06%) freq: 74 (0.09%)
> 4 values:1 times (0.00%) freq: 8 (0.00%)
>
> Top 10 invalid counters:
> freq: 16.51%: [141240244, 0, -1, 0, 0, 0, 0, 0, 0]
> freq: 1.63%: [13975904, 0, -1, 5684106, 16, 1665101193, 1253058,
> 1825880508, 18401625]
> freq: 1.14%: [9754922, 0, -1, 0, 0, 0, 0, 0, 0]
> freq: 1.02%: [8735262, 0, -1, 0, 0, 1236703056, 236175, 0, 0]
> freq: 1.02%: [8705490, 0, -1, 0, 0, 0, 0, 0, 0]
> freq: 0.96%: [8202145, 0, -1, 0, 0, 610851079, 9411, 0, 0]
> freq: 0.82%: [7017709, 0, -1, 0, 0, 0, 0, 0, 0]
> freq: 0.53%: [4542412, 0, -1, 0, 0, 0, 0, 754726, 423371]
> freq: 0.47%: [4049191, 1442160442, -1, 0, 0, 0, 0, 0, 0]
> freq: 0.45%: [3874984, 0, -1, 0, 0, 0, 0, 0, 0]
>
>
> stats for topn:
> total: 6620 freq: 16644468
> not executed at all: 6236
> invalid: 27 (0.41%) freq:2384107 (14.32%)
> only one target: 196 (2.96%) freq:3618218 (21.74%)
> useful values (with not one target):
> 0 values: 32 times (0.48%) freq: 4727351 (28.40%)
> 1 values: 73 times (1.10%) freq: 5762016 (34.62%)
> 2 values: 54 times (0.82%) freq: 138553 (0.83%)
> 3 values:2 times (0.03%) freq: 14223 (0.09%)
> 4 values:0 times (0.00%) freq: 0 (0.00%)
>
> Top 10 invalid counters:
> freq: 4.81%: [801313, 0, -1, 8, 386462, 0, 0, 0, 0]
> freq: 3.08%: [512299, 0, -1, 2048, 564657, 8192, 166154, 128, 8816]
> freq: 2.53%: [421331, 1784, -1, 0, 0, 0, 0, 0, 0]
> freq: 2.42%: [402980, 16, -1, 0, 0, 0, 0, 0, 0]
> freq: 0.45%: [75216, 0, -1, 47, 174422, 0, 0, 0, 0]
> freq: 0.23%: [37551, 0, -1, 0, 0, 0, 0, 0, 0]
> freq: 0.23%: [37551, 0, -1, 0, 0, 0, 0, 0, 0]
> freq: 0.17%: [28092, 0, -1, 0, 0, 47, 39898, 0, 0]
> freq: 0.06%: [9703, 0, -1, 47, 13860, 0, 0, 2, 6264]
> freq: 0.06%: [9561, 0, -1, 0, 0, 16, 7612, 4, 9640]
>
>
> and hacked libgcov build:
>
> == Stats for firefox-gcda-hacked/ ==
> stats for indirect_call:
> total: 160441 freq: 851736881
> not executed at all: 134832
> invalid: 0 (0.00%) freq:0 (0.00%)
> only one target: 20051 (12.50%) freq:106338877 (12.48%)
> useful values (with not one target):
> 0 values: 108 times (0.07%) freq:15676696 (1.84%)
> 1 values: 2944 times (1.83%) freq: 595969787 (69.97%)
> 2 values: 2307 times (1.44%) freq: 127252058 (14.94%)
> 3 values: 177 times (0.11%) freq: 6339867 (0.74%)
> 4 values: 22 times (0.01%) freq: 159596 (0.02%)
>
> Top 10 invalid counters:
> Traceback (most recent call last):
> File "/aux/hubicka/gcov-dump-analysis.py", line 100, in
> print(' freq: %.2f%%: %s' % (100 * all_invalid[i][0] / sum,
> all_invalid[i]))
It's fixed, pull latest version of the script.
>
> I guess we do not need rest of the dump.
> It is interesting that 1 useful value target goes up from 34% to 69%, so we
> seem to lose almost half of useful speculation info still.
That's suspicious for 1 useful value.
>
> I am not sure why the "only one useful target" stat changes significantly.
> Maybe here is some bug in detection of it?
Can you please attach somewhere gcov data for both these runs?
I'm going to take numbers on gcc bootstrap for these 2 variants.
[Bug tree-optimization/93504] Missed reassociation with constants and not of that constant with IORs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93504
--- Comment #4 from Marc Glisse ---
/* (x & ~m) | (y & m) -> ((x ^ y) & m) ^ x */
I guess several transformations like this one which match (unary m) could do
with a second version for the case where m is constant (and thus (unary m) is
already constant folded). That is, unless we come up with a trick to avoid that
duplication, like (untested)
(match (my_not @0)
(bit_not @0))
(match (my_not @0)
INTEGER_CST@0
(with { @0 = fold_unary (BIT_NOT_EXPR, TREE_TYPE(@0), @0); }
(if (true
although that's hackish, the commutative version is redundant, it builds a tree
unnecessarily, the conditions (single_use?) to make the transformation worth it
may be different, etc.
[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 #22 from Martin Liška --- For GCC I see the frequency of only one target aligned: == Stats for before == stats for indirect_call: total: 9210 freq: 5943636909 not executed at all: 6249 invalid: 669 (7.26%) freq:2219809025 (37.35%) only one target: 1786 (19.39%) freq:2260086892 (38.03%) useful values (with not one target): 0 values: 23 times (0.25%) freq:48191810 (0.81%) 1 values: 271 times (2.94%) freq: 1136761204 (19.13%) 2 values: 180 times (1.95%) freq: 200890480 (3.38%) 3 values: 32 times (0.35%) freq:77897498 (1.31%) 4 values:0 times (0.00%) freq: 0 (0.00%) Top 10 invalid counters: freq: 10.25%: [609379302, 0, -1, 0, 0, 0, 0, 0, 0] freq: 5.46%: [324403834, 0, -1, 0, 0, 0, 0, 0, 0] freq: 2.91%: [172847042, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.71%: [101514216, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.34%: [79624322, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.94%: [55632805, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.94%: [55597131, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.94%: [55597131, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.84%: [49651232, 0, -1, 0, 0, 0, 0, 0, 0] freq: 0.83%: [49464348, 0, -1, 0, 0, 0, 0, 0, 0] stats for topn: total: 1514 freq: 1761607630 not executed at all: 1030 invalid: 194 (12.81%) freq:1013865281 (57.55%) only one target: 149 (9.84%) freq:362258875 (20.56%) useful values (with not one target): 0 values:9 times (0.59%) freq: 4461379 (0.25%) 1 values: 75 times (4.95%) freq: 287705112 (16.33%) 2 values: 50 times (3.30%) freq:91245278 (5.18%) 3 values:7 times (0.46%) freq: 2071705 (0.12%) 4 values:0 times (0.00%) freq: 0 (0.00%) Top 10 invalid counters: freq: 27.67%: [487364997, 0, -1, 0, 0, 0, 0, 0, 0] freq: 3.84%: [67628999, 0, -1, 0, 0, 0, 0, 0, 0] freq: 3.40%: [59963262, 0, -1, 0, 0, 0, 0, 168, 10778] freq: 2.48%: [43755335, 0, -1, 0, 0, 0, 0, 0, 0] freq: 2.40%: [42351035, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.31%: [23145472, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.27%: [22324265, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.06%: [18684932, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.05%: [18472316, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.00%: [17554178, 0, -1, 0, 0, 8, 8986, 0, 0] == Stats for norepro/ == stats for indirect_call: total: 9210 freq: 5943646470 not executed at all: 6249 invalid: 0 (0.00%) freq:0 (0.00%) only one target: 1786 (19.39%) freq:2260089402 (38.03%) useful values (with not one target): 0 values: 132 times (1.43%) freq: 1348815836 (22.69%) 1 values: 571 times (6.20%) freq: 1909318242 (32.12%) 2 values: 407 times (4.42%) freq: 294668554 (4.96%) 3 values: 65 times (0.71%) freq: 130754436 (2.20%) 4 values:0 times (0.00%) freq: 0 (0.00%) stats for topn: total: 1514 freq: 1761608637 not executed at all: 1030 invalid: 0 (0.00%) freq:0 (0.00%) only one target: 149 (9.84%) freq:362258979 (20.56%) useful values (with not one target): 0 values: 76 times (5.02%) freq: 634460484 (36.02%) 1 values: 156 times (10.30%) freq: 592617317 (33.64%) 2 values: 84 times (5.55%) freq: 152569156 (8.66%) 3 values: 17 times (1.12%) freq:19702684 (1.12%) 4 values:2 times (0.13%) freq: 17 (0.00%)
[Bug d/92309] Assignment to anonymous union member corrupts sibling members in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92309 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/92311] Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92311 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/92323] bogus -Warray-bounds after unrolling despite __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92323 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- @Martin: Can we close this?
[Bug c++/92319] Macro expansion using the __VAOPT__ construct is incorrect when the variadic argument expands to nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92319 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Yes, please attach a reproducer.
[Bug tree-optimization/92706] SRA confuses FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92706 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- SRA works as expected now. Yay (looking at PR92645).
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 Bug 92645 depends on bug 92706, which changed state. Bug 92706 Summary: SRA confuses FRE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92706 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[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 #23 from Jan Hubicka --- This is stat for clang build with current mainline. half of invalidated counters is pretty high (as expected given large number of runs merged) == Stats for instrumented-gcc-new/ == stats for indirect_call: total: 102165 freq: 60781948847 not executed at all: 72377 invalid: 1721 (1.68%) freq:30235974099 (49.74%) only one target: 19386 (18.98%) freq:17554601991 (28.88%) useful values (with not one target): 0 values: 204 times (0.20%) freq:52073690 (0.09%) 1 values: 3155 times (3.09%) freq: 11344960859 (18.67%) 2 values: 5066 times (4.96%) freq: 1157879910 (1.90%) 3 values: 249 times (0.24%) freq: 436333894 (0.72%) 4 values:7 times (0.01%) freq: 124404 (0.00%) Top 10 invalid counters: freq: 12.58%: [7645935709, 0, -1, 0, 0, 0, 0, 0, 0] freq: 2.89%: [1755945623, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.88%: [1145226846, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.74%: [1057032227, 0, -1, 0, 0, 0, 0, 824621899, 2864] freq: 1.73%: [1054336214, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.69%: [1028958758, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.49%: [902957867, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.19%: [725051923, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.19%: [725051857, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.19%: [721257840, 0, -1, 0, 0, 0, 0, 0, 0] stats for topn: total: 23701 freq: 29841033474 not executed at all: 15770 invalid: 2470 (10.42%) freq:19610046414 (65.72%) only one target: 2265 (9.56%) freq:823109011 (2.76%) useful values (with not one target): 0 values: 338 times (1.43%) freq: 405060750 (1.36%) 1 values: 1163 times (4.91%) freq: 3855619321 (12.92%) 2 values: 1372 times (5.79%) freq: 5138220249 (17.22%) 3 values: 319 times (1.35%) freq: 8977585 (0.03%) 4 values:4 times (0.02%) freq: 144 (0.00%) Top 10 invalid counters: freq: 7.02%: [2096153456, 0, -1, 0, 0, 0, 0, 0, 0] freq: 6.31%: [1882301682, 0, -1, 0, 0, 0, 0, 0, 0] freq: 4.71%: [1406881034, 0, -1, 0, 0, 0, 0, 0, 0] freq: 4.71%: [1406881034, 0, -1, 0, 0, 0, 0, 0, 0] freq: 3.64%: [1085403277, 0, -1, 0, 0, 0, 0, 0, 0] freq: 3.46%: [1031727871, 0, -1, 0, 0, 0, 0, 2, 1760] freq: 3.01%: [897712838, 0, -1, 0, 0, 0, 0, 0, 0] freq: 2.10%: [628131579, 0, -1, 0, 0, 0, 0, 0, 0] freq: 1.74%: [518993181, 0, -1, 0, 0, 0, 0, 128, 19] freq: 1.71%: [509908530, 0, -1, 0, 0, 0, 0, 0, 0]
[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 #24 from Jan Hubicka --- You can get gcda files from the treeherder links https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GacHgozaSRWbybgeUGzHVQ/runs/0/artifacts/public/build/profdata.tar.xz https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/U_iQth7cR8efefeH_Dc_bA/runs/0/artifacts/public/build/profdata.tar.xz
[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 #25 from Jan Hubicka --- I wonder if that is because of parallel updates. There is quite a lot of time between prunning and streaming out. If Firefox forks while other threads are running, it will mess up the streamed data quite badly. Is there way to stop other threads?
[Bug fortran/92325] -fdump-tree-original and char(kind=4) initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92325 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/92327] insufficient diagnosis on the incompatibility type of auto template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92327 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug middle-end/92330] Wstrict-overflow documentation does not say that it is deprecated and has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92330 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- @Manual: Are you still planning to update the documentation?
[Bug c++/92332] invalid optimization in certain situations involving placement new on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92332 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- @Andrew: May I close it as invalid?
[Bug rtl-optimization/92331] ICE on incorrect code with VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92331 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug c++/92340] Qualifiers check fails when inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92340
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2020-01-30
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Martin Liška ---
Using current master, I see:
$ g++ pr92340.cc -c
pr92340.cc: In function ‘void f1()’:
pr92340.cc:12:6: error: passing ‘const C’ as ‘this’ argument discards
qualifiers [-fpermissive]
12 | c.f();
| ^
pr92340.cc:5:8: note: in call to ‘void C::f()’
5 | void f() {}
|^
pr92340.cc: In function ‘int main()’:
pr92340.cc:16:5: error: expected primary-expression before ‘int’
16 | f1();
| ^~~
Clang says:
$ clang++ pr92340.cc -c
pr92340.cc:12:2: error: 'this' argument to member function 'f' has type 'const
C', but function is not marked const
c.f();
^
pr92340.cc:5:8: note: 'f' declared here
void f() {}
^
pr92340.cc:16:2: error: 'f1' does not name a template but is followed by
template arguments
f1();
^ ~
pr92340.cc:9:6: note: non-template declaration found by name lookup
void f1() {
^
2 errors generated.
What's wrong about this?
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #8 from Karen --- Thanks for the explanation. In fact it doesn't work even for -D_XOPEN_SOURCE=700 as the latest POSIX edition doesn't specify the aligned_alloc function. On the other hand I don't observe that _XOPEN_SOURCE affects the __cplusplus macro: % cat
[Bug fortran/92358] libgfortran/io/async.c:548:37: warning: unused parameter 'cmp'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92358 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I also can't see the issue.
[Bug c++/92374] Unable to link relocatable object when GCC is configured with "--disable-comdat"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92374 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/92381] missing -Warray-bounds on negative index with very large magnitude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92381 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/92380] Bogus -Warray-bounds warning with structures, one of which has a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92380 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Martin Liška --- As the debug issue was created, I'm closing this.
[Bug target/92395] m68k-linux-gnu-gcc generates wrong code when the -mshort option is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92395 Martin Liška changed: What|Removed |Added Keywords||easyhack Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/92402] parsing error in lambda trail return type with decltype, statement expressions and structured bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92402 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed.
[Bug c++/92332] invalid optimization in certain situations involving placement new on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92332 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > two things, > One is you are violating C++ aliasing rules I think. Right, you're creating a uint64_t but accessing two uint32_t objects. The uint32_t objects were never initialized, so have indeterminate values. That's why you get warnings about uninitialized data. It would work if you used an array of unsigned char or std::byte, since they have special aliasing rules that allow them to be used to read the bytes of other types. Also the static_cast is undefined, because there is no bar object at that location, just a myarray. > Second is after "operator new", the value that is contained in the pointer > is undefined/unspecified. I don't know what this means. > NOTE in C++2a (or c++20), there is an operator new which has the property of > the value is kept defined. (BUT GCC Does not implement that yet). I don't know what this means either. The code has undefined behaviour though, so closing.
[Bug c++/92413] [temp.explicit] Explicit template instantiations should not define member functions that are not defined at the point of instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- clang++ pr92413.cc -c -std=c++17 pr92413.cc:4:3: error: static_assert failed due to requirement 'sizeof(int) == 1' static_assert(sizeof(int) == 1); ^ 1 error generated. Are you sure clang accepts the code?
[Bug testsuite/92415] new test case g++.dg/cpp2a/spaceship-scalar1-neg.C introduced in r277925 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92415 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- @seurer: Can we close this?
[Bug c++/92434] noexcept couldn't be deduced in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92434 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[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 #26 from Martin Liška --- (In reply to Jan Hubicka from comment #25) > I wonder if that is because of parallel updates. There is quite a lot of > time between prunning and streaming out. If Firefox forks while other > threads are running, it will mess up the streamed data quite badly. Is there > way to stop other threads? No.
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 --- Comment #19 from Richard Biener --- So after the PR92706 fix there's still a lot left on the table.
[Bug middle-end/92455] Unnecessary memory read in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92455 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Martin Liška --- I'll measure impact of the option on SPEC benchmarks.
[Bug c++/93506] New: Create hybrid of -I and -isystem that is like -I but deactivates warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93506 Bug ID: 93506 Summary: Create hybrid of -I and -isystem that is like -I but deactivates warnings Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fiesh at zefix dot tv Target Milestone: --- Being guilty of abusing -isystem a lot to silence warnings in third-party libraries, it would be great if there were a spin off of -I that ignored warnings just like -isystem does but otherwise behaves like -I. (An argument that is brought up sometimes, namely that third-party libraries should fix their warnings, isn't really valid I believe. For example, constexpr variables became implicitly inline in C++17. Before that, one had to define them in translation units. So libraries remaining pre-C++17 compatible will want to do that, while projects that compile in C++17 might prefer warnings about deprecated things being done. Also, from a practicality point of view, it is simply not a meaningful argument.)
[Bug other/92456] libiberty/make-relative-prefix.c: read buffer overflow in split_directories()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92456 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- @Tim: Can you please send the patch to GCC patches mailing list?
[Bug ipa/92497] Aggregate IPA-CP and inlining do not play well together, transformation is lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497 Martin Liška changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 Ever confirmed|0 |1
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/92523] Unhelpful error messages when requires-clause contains function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92523 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Hm, I see that clang accepts the code. So maybe we reject a valid code?
[Bug c++/92541] ICE when concept requires contextual conversion to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92541 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Martin Liška --- @Jonathan: Can we close this one?
[Bug demangler/92544] test-demangle < ../../../gcc/libiberty/testsuite/demangle-expected: FAIL at line 1452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92544 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/92547] FAIL: c-c++-common/goacc/firstprivate-mappings-1.c scan-tree-dump omplower "(?n)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92547 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/93507] Missed abstraction removal in VN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93507 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 Blocks||92645 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 [Bug 92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
[Bug c++/93506] Create hybrid of -I and -isystem that is like -I but deactivates warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93506 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70129 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- For example, see PR 70129 where people are having problems because they're abusing -isystem to get rid of warnings, and that breaks libstdc++ headers. Rather than yet another -I option (which wouldn't be portable) a better solution might be a separate option that you use in addition to -I to mark that path with the "treat as system headers and don't warn" i.e. -I /some/path -fsystem-headers=/some/path This assumes that the "it's a system header path" property is a flag that can be set independently of being in the actual list of system header locations, rather than just implied.
[Bug tree-optimization/93507] New: Missed abstraction removal in VN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93507
Bug ID: 93507
Summary: Missed abstraction removal in VN
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Skia (PR92645) contains abstraction that can be simplified to
unsigned long foo(unsigned int x)
{
unsigned int src = x;
unsigned long dst = 0;
__builtin_memcpy (&dst, &src, sizeof (unsigned int));
return dst;
}
which we should be able to optimize to just zero-extension of x. But we end
up keeping this all the way through assembling:
foo:
.LFB0:
.cfi_startproc
movq$0, -8(%rsp)
movl%edi, -8(%rsp)
movq-8(%rsp), %rax
ret
[Bug ipa/92548] FAIL: gcc.dg/ipa/ipa-sra-12.c scan-ipa-dump-times sra "Will split parameter" 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92548 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469
--- Comment #9 from Jonathan Wakely ---
(In reply to Karen from comment #8)
> Thanks for the explanation.
>
> In fact it doesn't work even for -D_XOPEN_SOURCE=700 as the latest POSIX
> edition doesn't specify the aligned_alloc function.
But it is defined by C11 and C++17, so if you compile with -std=c11 or
-std=c++17 (which will set __STDC_VERSION or __cplusplus respectively) then the
OS should declare aligned_alloc.
> On the other hand I don't observe that _XOPEN_SOURCE affects the __cplusplus
> macro:
I didn't say it changes the value of it, I said it overrides it. Look in
where the declaration of aligned_alloc is guarded by:
#if (__DARWIN_C_LEVEL >= __DARWIN_C_FULL) && \
((defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) || \
(defined(__cplusplus) && __cplusplus >= 201703L))
This means if _DARWIN_C_LEVEL is below "full" (which happens when
_XOPENS_SOURCE is defined) then aligned_alloc will never be declared, even when
the C or C++ language dialect requires it.
In my not so humble opinion that first && should be || instead, so that
aligned_alloc is declared if the level is "full" or greater, **or** if it's
required by the language standard that is in use.
> One can argue, but this can be considered a libstdc++ issue that it is
> affected by the macro that defines the C functions availability.
But you get exactly the same problem compiling this C program with -std=c11,
where libstdc++ is completely irrelevant and there are no GCC headers used:
#define _XOPEN_SOURCE 600
#include
int main() { free(aligned_alloc(4, 4)); }
This warns about aligned_alloc being implicitly declared, because the macOS
header fails to declare it.
This is an Apple bug, please report it to radar.
[Bug c++/92556] [10 Regression] ICE if using dependent name inside lambda expression in simple-requirement since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92556 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|ICE if using dependent name |[10 Regression] ICE if |inside lambda expression in |using dependent name inside |simple-requirement |lambda expression in ||simple-requirement since ||r10-3735-gcb57504a55015891 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started to ICE with r10-3735-gcb57504a55015891, before that we rejected that like clang: pr92556.cc:2:5: error: ‘requires’ does not name a type 2 | requires requires | ^~~~ pr92556.cc: In function ‘int main()’: pr92556.cc:15:14: error: no matching function for call to ‘f()’ 15 | f< int >() ; | ^ pr92556.cc:17:12: error: no matching function for call to ‘f()’ 17 | f< S >() ; |^ $ clang++ pr92556.cc -c -std=c++2a pr92556.cc:2:14: error: expected expression requires requires ^ pr92556.cc:15:5: error: use of undeclared identifier 'f' f< int >() ; ^ pr92556.cc:17:8: error: use of undeclared identifier 'S' f< S >() ; ^ 3 errors generated.
[Bug tree-optimization/93508] New: VN doesn't handle _chk functions or valueize their length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93508
Bug ID: 93508
Summary: VN doesn't handle _chk functions or valueize their
length
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
unsigned int foo(unsigned int x, int *p)
{
unsigned int src = x;
unsigned int dst;
*p = sizeof (unsigned int);
__builtin___memcpy_chk (&dst, &src, *p, 16);
return dst;
}
should be optimized to return x in fre1.
[Bug tree-optimization/93508] VN doesn't handle _chk functions or valueize their length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93508 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 Blocks||92645 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 [Bug 92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
[Bug libgcc/92565] trunk/libgcc/config/libbid/bid_internal.h: 2 * useless assignments ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92565 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug c++/90338] [9/10 Regression] member function pointer non-type template parameter compile fail while matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90338 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini --- Note, this requires -std=c++2a to reproduce. Current trunk is fine, I think I'll add the testcase and remove the 10 Regression marker.
[Bug go/92567] libgo regression in syscall test on ppc64le resulting in timeout due to hang in read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92567 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/92570] clang fails to instantiate std::optional if A is not const copy constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92570 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org, ||redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- @Jonathan: Can you please take a look?
[Bug fortran/92568] OpenMP 5 - implicit mapping of scalar with TARGET/ALLOCATABLE/POINTER attribute: shall be 'tofrom' mapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92568 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505 --- Comment #6 from Zdenek Sojka --- (In reply to Zdenek Sojka from comment #5) > Created attachment 47738 [details] > only partially reduced testcase, with always defined shifts > > It also needs more flags to reproduce: > -Os -fno-expensive-optimizations -fno-forward-propagate -fno-inline > -fno-ipa-vrp -fno-tree-bit-ccp -fno-tree-ter > > (not all of those are needed; switching to -Og might help to reduce the > number of needed flags) > > I've just deleted my gcc repo + binaries, so I can't test it atm. Actually, only -Og is enough even for that testcase: $ powerpc64le-unknown-linux-gnu-gcc -Og testcase-min1.c -static -w && ./a.out (wrong) $ powerpc64le-unknown-linux-gnu-gcc -O0 testcase-min1.c -static -w && ./a.out 0001 (correct)
[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586 Martin Liška changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Martin Liška --- Confirmed, it's very old (at least 4.8.0+).
[Bug c++/93506] Create hybrid of -I and -isystem that is like -I but deactivates warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93506 --- Comment #2 from Jonathan Wakely --- P.S. the name -fsystem-headers was chosen to mirror -Wsystem-headers because those two options would interact. Marking a dir with -fsystem-headers would cause warnings to be suppressed for headers in that path, -Wsystem-headers would re-enable those warnings. Another advantage of a separate option is that it could appear anywhere on the command line, order wouldn't matter (whereas order of -I options is obviously significant). That would allow makefiles to have something like: ifeq(CC,gcc) GCC_SPECIFIC_CPPFLAGS := -fsystem-headers=/dir/one -fsystem-headers=/dir/three endif CPPFLAGS := -I /dir/one -I /dir/two -I /dir/three $(GCC_SPECIFIC_CPPFLAGS) If the feature was available via a new -Isystem flag you'd need to do something like this to preserve order: I_ := -I ifeq(CC,gcc) I_ := -Isystem endif CPPFLAGS := $(I_) /dir/one -I /dir/two $(I_) /dir/three
[Bug fortran/92587] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- For older GCC 8 I see: tensor_recursive.F90:738:36: private TensBodyGetDataDescr 1 Error: Symbol ‘tensbodygetdatadescr’ at (1) has no IMPLICIT type; did you mean ‘tensbodygetdatatype’? tensor_recursive.F90:734:35: private TensBodySetLocation 1 Error: Symbol ‘tensbodysetlocation’ at (1) has no IMPLICIT type; did you mean ‘tensbodygetdatatype’? tensor_recursive.F90:714:38: private TensLayoutGetDataDescr 1 Error: Symbol ‘tenslayoutgetdatadescr’ at (1) has no IMPLICIT type; did you mean ‘tenslayoutgetdatatype’? tensor_recursive.F90:706:37: private TensLayoutSetLocation 1 Error: Symbol ‘tenslayoutsetlocation’ at (1) has no IMPLICIT type; did you mean ‘tenslayoutgetbodysize’? tensor_recursive.F90:768:37: private TensRcrsvGetDataDescr 1 Error: Symbol ‘tensrcrsvgetdatadescr’ at (1) has no IMPLICIT type; did you mean ‘tensrcrsvgetdatatype’? tensor_recursive.F90:769:36: private TensRcrsvSetLocation 1 Error: Symbol ‘tensrcrsvsetlocation’ at (1) has no IMPLICIT type; did you mean ‘tensrcrsvgetlayout’? Is it really a valid code?
[Bug target/92592] Redundant comparison after subtraction on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92592 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/90338] [9/10 Regression] member function pointer non-type template parameter compile fail while matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90338 --- Comment #3 from CVS Commits --- The master branch has been updated by Paolo Carlini : https://gcc.gnu.org/g:b0e9b18ed432c4b7cb9a4b963b65911b4c103cbe commit r10-6347-gb0e9b18ed432c4b7cb9a4b963b65911b4c103cbe Author: Paolo Carlini Date: Thu Jan 30 11:39:04 2020 +0100 Add testcase of PR c++/90338, already fixed in trunk. PR c++/90338 * g++.dg/pr90338.C: New.
[Bug target/92611] auto vectorization failed for type promotation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92611 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/92613] Bogus warning with -cpp and -fpreprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92613 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/92568] OpenMP 5 - implicit mapping of scalar with TARGET/ALLOCATABLE/POINTER attribute: shall be 'tofrom' mapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92568 --- Comment #2 from Jakub Jelinek --- I don't think the TARGET attribute ever matters for the mapping rules. What matters is whether a variable is mentioned in !$omp declare target to/link clauses (for OpenMP 5 there is also some implicit discovery for that). And, while err has TARGET attribute, it isn't mentioned in !$omp declare target, so it should be firstprivate.
[Bug middle-end/92624] inconsistent folding of strcmp calls with unterminated arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92624 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/92628] Make use of TYPE_RESTRICT for function-call pointer-escape analysis – especially for Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92628 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/92630] missing -Wrestrict with attribute access and restrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92630 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/92570] [8/9/10 Regression] clang fails to instantiate std::optional if A is not const copy constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92570 Jonathan Wakely changed: What|Removed |Added Known to work||7.5.0 Summary|clang fails to instantiate |[8/9/10 Regression] clang |std::optional if A is|fails to instantiate |not const copy |std::optional if A is |constructible |not const copy ||constructible Known to fail||10.0, 8.3.0, 9.2.0 --- Comment #2 from Jonathan Wakely --- Marking as a regression, since clang is happy with the libstdc++ headers from GCC 7. I haven't analysed where the bug is yet though.
[Bug target/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- And the original testcase is perfectly valid, so I don't see why we are looking for another one.
[Bug target/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505
--- Comment #7 from Jakub Jelinek ---
Still bisecting it, but I'd say the bug is in expand_binop:
/* If we were trying to rotate, and that didn't work, try rotating
the other direction before falling back to shifts and bitwise-or. */
if (((binoptab == rotl_optab
&& (icode = optab_handler (rotr_optab, mode)) != CODE_FOR_nothing)
|| (binoptab == rotr_optab
&& (icode = optab_handler (rotl_optab, mode)) != CODE_FOR_nothing))
&& is_int_mode (mode, &int_mode))
{
optab otheroptab = (binoptab == rotl_optab ? rotr_optab : rotl_optab);
rtx newop1;
unsigned int bits = GET_MODE_PRECISION (int_mode);
if (CONST_INT_P (op1))
newop1 = gen_int_shift_amount (int_mode, bits - INTVAL (op1));
else if (targetm.shift_truncation_mask (int_mode) == bits - 1)
newop1 = negate_rtx (GET_MODE (op1), op1);
else
newop1 = expand_binop (GET_MODE (op1), sub_optab,
gen_int_mode (bits, GET_MODE (op1)), op1,
NULL_RTX, unsignedp, OPTAB_DIRECT);
temp = expand_binop_directly (icode, int_mode, otheroptab, op0, newop1,
target, unsignedp, methods, last);
if (temp)
return temp;
}
The above is wrong if op1 is or might be 0 and targetm.shift_truncation_mask
(int_mode) != bits - 1,
because for original valid rotate by 0 it will create invalid rotate in the
other direction by bits
which is out of bounds rotation count.
So, I'd say we should either mask the result of subtraction with bits - 1, or
perhaps better
do a negate + and, i.e. -op1 & (bits - 1).
[Bug c++/92652] function call to lambda expression that return true does not satisfy the constraint in requires-clause if using return type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92652 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug rtl-optimization/92656] The zero_extend insn can't be eliminated in the combine pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/92658] x86 lacks vector extend / truncate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/92660] overflow warning message enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92660 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/92568] OpenMP 5 - implicit mapping of scalar with TARGET/ALLOCATABLE/POINTER attribute: shall be 'tofrom' mapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92568 --- Comment #3 from Jakub Jelinek --- Oops, sorry, you are right, have been looking just at OpenMP 4.5, in OpenMP 5 that rule indeed has been added, but it is about all of TARGET/ALLOCATABLE/POINTER.
[Bug c++/92662] change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Martin Liška --- @Michael: Can we close this issue?
[Bug c/92667] spurious missing sentinel in function call with a local sentinel variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92667 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/92672] OpenMP shared clause not respected without pointer to the variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92672 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- @Jakub: Can you please take a look?
[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 92671, which changed state. Bug 92671 Summary: gcc/c/c-parser.c: minor ( and ) tidyup https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92671 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug c/92671] gcc/c/c-parser.c: minor ( and ) tidyup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92671 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Martin Liška --- Then closing as invalid.
[Bug c++/92687] decltype of a structured binding to a tuple component is a reference type inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92687 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, clang accepts the code.
[Bug tree-optimization/92689] Improve stmt_may_clobber_ref_p_1 on constant memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92689 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/92700] wrong "unintialized" warning with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92700 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- @Martin: Can you please take a look?
[Bug c++/92707] type alias on type alias on lambda in unevaluated context does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92707 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 Ever confirmed|0 |1
[Bug c++/92717] precompiled headers non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717 Martin Liška changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #9 from Martin Liška --- I agree that we should document the behavior that ASLR should not be used.
[Bug libgomp/92726] OpenACC: 'NULL'-in -> no-op, and/or 'NULL'-out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92726 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Can we close it now?
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2019-11-30 00:00:00 |2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
