[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Martin Liška --- (In reply to Segher Boessenkool from comment #7) > Why? Is there any advantage to that? The probability of having a collision > anywhere in the repo is nihil with ten digits already, and anywhere in the > world ever with twelve. Why do we want thirty-two? Well, I'm not a fan of git gcc-descr. But my impression was that Jakub wants to use it. I speak about: $ git gcc-descr --full HEAD r10-6232-g091fe099ba9093b8577ad4a10b56e18c6ea3daea > > [ Maybe I missed some mail thread, sorry if so. ]
[Bug analyzer/93450] New: ICE in real_maxval, at real.c:2593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93450
Bug ID: 93450
Summary: ICE in real_maxval, at real.c:2593
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/ -fanalyzer:
void
ed (int);
double
bg (void)
{
double kl = __builtin_huge_val ();
ed (0);
return kl;
}
% gcc-10.0.0 -fanalyzer -c mp0tmliq.c
during IPA pass: analyzer
mp0tmliq.c: In function 'bg':
mp0tmliq.c:7:10: internal compiler error: in real_maxval, at real.c:2593
7 | double kl = __builtin_huge_val ();
| ^~
0x684060 real_maxval(real_value*, int, machine_mode)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/real.c:2593
0x12d8415 generic_simplify_336
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/build/gcc/generic-match.c:15447
0x1360c09 generic_simplify_EQ_EXPR
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/build/gcc/generic-match.c:52777
0xa467b0 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/fold-const.c:10105
0xa50a29 fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/fold-const.c:13088
0x10f791c ana::constant_svalue::eval_condition(ana::constant_svalue*,
tree_code, ana::constant_svalue*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/region-model.cc:674
0x10f16b9 ana::sm_state_map::set_state(ana::region_model*, ana::svalue_id,
unsigned int, ana::svalue_id)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/program-state.cc:272
0x10f1817 ana::sm_state_map::purge_for_unknown_fncall(ana::exploded_graph
const&, ana::state_machine const&, gcall const*, tree_node*,
ana::region_model*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/program-state.cc:370
0x10e44d2 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::state_change*) const
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:1039
0x10e4e61 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:2439
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 target/93449] New: PCC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 Bug ID: 93449 Summary: PCC: Missing conversion builtin from vector to _Decimal128 and vice versa Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jens.seifert at de dot ibm.com Target Milestone: --- I am currently porting an application from AIX to PPCLE and found that I am lacking compiler builtins for transforming vector input into _Decimal128 and vice versa. This can be done on PowerPC using xxlor + xxpermdi (2 instructions on >= Power7). The conversion routines __builtin_denbcdq/__builtin_ddedpdq are based on _Decimal128 input and output. The missing piece is vector to _Decimal128 and vice versa. Background: >From and to vector register I can load/store variable length BCD decimals. BCD Decimal can be converted to _Decimal128. Then I can perform multiply and divide. Then can be converted back to BCD, but then again I want to store a BCD decimal which might not be 16-byte in size.
[Bug c++/93448] New: PPC: missing builtin for DFP quantize(dqua,dquai,dquaq,dquaiq)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448 Bug ID: 93448 Summary: PPC: missing builtin for DFP quantize(dqua,dquai,dquaq,dquaiq) Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jens.seifert at de dot ibm.com Target Milestone: --- I am currently porting an application to PPCLE and found that I am lacking compiler builtins for decimal floating point quantize on _Decimal128/_Decimal64. Any plans to add them ? Any workarounds ? E.g. did I miss a inline asm constraint for _Decimal128 register even/odd pair ?
[Bug c++/90691] [9/10 regression] -Wsign-compare false-positive with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90691 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #11 from Jason Merrill --- Any update?
[Bug c++/90966] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:16155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90966 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90992 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #11 from Jason Merrill --- Note that the patch doesn't address the original complaint, which was that we shouldn't say that Automatic::Automatic(size_t) could be noexcept when it calls NotNoexcept() which is noexcept(false). But the diagnostic is correct when it says that the constructor does not throw; since we can see the definition of NotNoexcept(), we can tell that even though it is declared noexcept(false), it in fact does not throw. So I don't think that the attached minimal testcase shows an actual false positive.
[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90992 --- Comment #10 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:40bf3f1fd058028988b2625f89efe6bb811a4185 commit r10-6239-g40bf3f1fd058028988b2625f89efe6bb811a4185 Author: Jason Merrill Date: Sun Jan 26 21:34:33 2020 -0500 c++: Testsuite adjustments for PR 90992. It occurred to me that the NotNoexcept class is irrelevant to the issue I was fixing, so let's remove it.
[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90992 --- Comment #9 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5035cd662459b09605370f2ba41b2238119c69b1 commit r10-6238-g5035cd662459b09605370f2ba41b2238119c69b1 Author: Jason Merrill Date: Sun Jan 26 00:37:24 2020 -0500 c++: Fix -Wnoexcept handling of system headers (PR90992). The immediate issue here was that the second warning didn't depend on the first one, so if the first location was in a system header, we'd mysteriously give the second by itself. It's also the case that the thing we care about being in a system header is the function that we want to suggest adding 'noexcept' to, not the noexcept-expression; it's useful to suggest adding noexcept to a user function to satisfy a noexcept-expression in a system header. PR c++/90992 * except.c (maybe_noexcept_warning): Check DECL_IN_SYSTEM_HEADER and temporarily enable -Wsystem-headers. Change second warning to conditional inform.
[Bug target/83832] [RX] Improve bittests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83832
--- Comment #2 from Oleg Endo ---
bset, bclr, bnot insns can be utiized with inline asm:
asm volatile ("bclr %1,%0.B"
: "+Q" (*(volatile unsigned char*)byte_addr) : "ir" (bitnum) :
"memory");
When the bitnum is not a constant and passed in a register, it should be taken
into account that only the lower 3 bits will be used, i.e. it effectively does
an "bitnum & 3" operation. It should be encoded in the pattern so that
explicit ands get eliminated.
[Bug target/83832] [RX] Improve bittests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83832 --- Comment #1 from Oleg Endo --- Another bit test case I ran into (on GCC 8) is something like unsigned int bleh = (i & 4) == 0 ? 0 : 3; An optimized result would be something like tst #4,r1 stz #0,r14 stnz #3,r14 This would take 3 cycles to execute, which is minimal. The same can be done with a smaller code size: mov.l #0,r14 tst #4,r1 stnz #3,r14 It seems it kind of works for some cases, but not for all the cases. For example, inverting the condition in the above example: unsigned int bleh = (i & 4) != 0 ? 0 : 3; results in: 66 4e mov.l #4, r14 53 2e and r2, r14 66 3e mov.l #3, r14 fd 74 fe 00 stnz#0, r14 But then swapping the constants to unsigned int bleh = (i & 4) != 0 ? 3 : 0; again falls back to cbranch code: 66 4e mov.l #4, r14 53 2e and r2, r14 14 beq.s 0f 66 3e mov.l #3, r14 03 nop 0:
[Bug libstdc++/78714] std::get_time / std::time_get::get does not accept full month name in %b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78714 Howard Hinnant changed: What|Removed |Added CC||howard.hinnant at gmail dot com --- Comment #1 from Howard Hinnant --- Here is a hopefully helpful algorithm for scanning a list of "keywords" for a match: https://github.com/HowardHinnant/date/blob/master/include/date/date.h#L4695-L4797 The keywords can be prefixes of one another, and the scan will match the longest possible keyword. The scan is case-insensitive. Here is how it can be used: https://github.com/HowardHinnant/date/blob/master/include/date/date.h#L4695-L4797 Here is how this bug is impacting real-world code, and estimates on how the impact will increase with C++20: https://github.com/HowardHinnant/date/wiki/FAQ#week_day_parse_bug https://github.com/HowardHinnant/date/issues/539
[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 #17 from Jan Hubicka --- I further hacked the script to record only values that are useful, where useful means with greater count then all / TOPN_VALUES / 2. I use same test in GCC itself (that was bug in original luxou's patch that it required count to be at least 50% so we did more then two speculations only when the number of targets was precisely 2 and probability precisely 50%). I also added special case for those calls which have only one target. Now I get: == Stats for all == stats for indirect_call: total: 160441 freq: 833372200 not executed at all: 134836 invalid: 0 (0.00%) freq:0 (0.00%) only one target: 20036 (12.49%) freq:108329394 (13.00%) tracked values: 0 values: 111 times (0.07%) freq:14162014 (1.70%) 1 values: 2963 times (1.85%) freq: 594520090 (71.34%) 2 values: 2284 times (1.42%) freq: 111578254 (13.39%) 3 values: 185 times (0.12%) freq: 2525320 (0.30%) 4 values: 26 times (0.02%) freq: 2257128 (0.27%) stats for topn: total: 6620 freq: 16471134 not executed at all: 6236 invalid: 0 (0.00%) freq:0 (0.00%) only one target: 196 (2.96%) freq:3535103 (21.46%) tracked values: 0 values: 39 times (0.59%) freq: 5340350 (32.42%) 1 values: 84 times (1.27%) freq: 6006897 (36.47%) 2 values: 59 times (0.89%) freq: 1547519 (9.40%) 3 values:6 times (0.09%) freq: 41265 (0.25%) 4 values:0 times (0.00%) freq: 0 (0.00%) == Stats for mainline == stats for indirect_call: total: 160441 freq: 865715132 not executed at all: 134862 invalid: 156 (0.10%) freq:64839775 (7.49%) only one target: 1255 (0.78%) freq:604290 (0.07%) tracked values: 0 values:14939 times (9.31%) freq: 356592480 (41.19%) 1 values: 8535 times (5.32%) freq: 377193150 (43.57%) 2 values: 660 times (0.41%) freq:66082791 (7.63%) 3 values: 15 times (0.01%) freq: 133242 (0.02%) 4 values: 19 times (0.01%) freq: 269404 (0.03%) stats for topn: total: 6620 freq: 16793729 not executed at all: 6235 invalid: 10 (0.15%) freq:1307937 (7.79%) only one target: 10 (0.15%) freq:1300 (0.01%) tracked values: 0 values: 182 times (2.75%) freq: 9195915 (54.76%) 1 values: 156 times (2.36%) freq: 6111713 (36.39%) 2 values: 26 times (0.39%) freq: 173054 (1.03%) 3 values:1 times (0.02%) freq:3810 (0.02%) 4 values:0 times (0.00%) freq: 0 (0.00%) So with 4 targets we seem to be able to track 98.3% of trained branhces while with reproducible merging this drops to 45% I will send you the hacked script
[Bug tree-optimization/93447] New: Value range propagation not working at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93447
Bug ID: 93447
Summary: Value range propagation not working at -Os
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
I have a lot of cases where I'd like to translate boolean conditions to negated
errno codes (possibly wrapped in an struct or a trivial union).
If this translation is inlinable, I'd expect that undoing it to get a boolean
again (bool => negated errno => bool) would eliminate the roundtrip.
GCC indeed does this at -O2 and -O3, but the optimization's failing to kick in
at -Os, leading to code size increases.
Clang succeeds at eliminating the roundrip at -Os (and it does this
optimization already at -O1).
A simple example that generates unnecessary code at -Os:
#include
_Bool addb_simple(int A, int B, int *Rp)
{
int ec=0;
if(__builtin_add_overflow(A,B,Rp))
ec = -ERANGE;
return !!ec;
}
https://gcc.godbolt.org/z/tGkbtD
Thanks for looking into it!
[Bug tree-optimization/93017] FAIL: gcc.dg/graphite/interchange-1.c scan-tree-dump graphite "tiled"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93017 --- Comment #5 from Romain Geissler --- Ah actually I see this on branch gcc 8 as well, with ISL 0.21. And apparently it is not making "make check" return an error code, so it's very possible that I had this error before without noticing it.
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #36 from Andrew Pinski --- MIPS is still broken. I might look into MIPS brokenness next week.
[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 Marek Polacek changed: What|Removed |Added Summary|[9/10 Regression] ICE |[9 Regression] ICE during |during GIMPLE pass: sanopt |GIMPLE pass: sanopt with |with -fsanitize=address |-fsanitize=address |-fdump-tree-sanopt |-fdump-tree-sanopt --- Comment #4 from Marek Polacek --- Fixed on trunk so far.
[Bug sanitizer/93436] [9/10 Regression] ICE during GIMPLE pass: sanopt with -fsanitize=address -fdump-tree-sanopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93436 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:ab6cd364eda21d3d24a4df0072c588cc68ff61e0 commit r10-6235-gab6cd364eda21d3d24a4df0072c588cc68ff61e0 Author: Marek Polacek Date: Sat Jan 25 19:02:11 2020 -0500 sanopt: Avoid crash on anonymous parameter [PR93436] Here we crash when using -fsanitize=address -fdump-tree-sanopt because the dumping code uses IDENTIFIER_POINTER on a null DECL_NAME. Instead, we can print "" in such a case. Or we could avoid printing that diagnostic altogether. 2020-01-26 Marek Polacek PR tree-optimization/93436 * sanopt.c (sanitize_rewrite_addressable_params): Avoid crash on null DECL_NAME.
[Bug tree-optimization/93017] FAIL: gcc.dg/graphite/interchange-1.c scan-tree-dump graphite "tiled"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93017 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #4 from Romain Geissler --- Hi, I am seeing similar fails on current release branch gcc 9 as well, using ISL 0.21. Some months ago with the same ISL version and branch gcc 9 I did not see such failures. Cheers, Romain
[Bug bootstrap/92002] [10 regression] -Wuninitialized warning in gcc/wide-int.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92002 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Jakub Jelinek --- > -Wno-error=uninitialized might be more appropriate for the workaround. In fact one needs both -Wno-error=uninitialized and -Wno-error=maybe-uninitialized
[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 #16 from Martin Liška --- (In reply to Jan Hubicka from comment #15) > This is frequency scaled by #of executions: > > == Stats for /aux/hubicka/firefox2019-trunktest == > stats for indirect_call: > total: 160451 > invalid: 542 (0.34%) freq:276193364 (33.87%) > tracked values: > 0 values: 134367 times (83.74%) freq:1338929 (0.16%) > 1 values:21514 times (13.41%) freq: 264147030 (32.39%) > 2 values: 3151 times (1.96%) freq: 136985793 (16.80%) > 3 values: 866 times (0.54%) freq: 136555223 (16.75%) > 4 values: 11 times (0.01%) freq: 248712 (0.03%) > > stats for topn: > total: 7140 > invalid: 24 (0.34%) freq:2147128 (15.00%) > tracked values: > 0 values: 6776 times (94.90%) freq:2107083 (14.72%) > 1 values: 242 times (3.39%) freq: 6758801 (47.22%) > 2 values: 79 times (1.11%) freq: 2233704 (15.60%) > 3 values: 19 times (0.27%) freq: 1067609 (7.46%) > 4 values:0 times (0.00%) freq: 0 (0.00%) > > So this makes invalidation rate quite high. Hm, you are right. Can you please send me the updates Python script? I would be interested in changing N to a higher number. And we may make a hacked version of gcov runtime to print which values are collected for each topn and indirect call and what is result of merging. We can use it to verify that merging works fine. I'll prepare a patch tomorrow and run it on the GCC bootstrap.
[Bug c++/93083] copy deduction rejected when doing CTAD for NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083
Martijn Otto changed:
What|Removed |Added
CC||martijntje at martijnotto dot
nl
--- Comment #1 from Martijn Otto ---
The problem with deducing N is a stubborn one. I have run into the same issue
and tried to fix it by adding a constexpr size() method to explicitly provide
the size, but it doesn't seem to help and fails with the same error message
about being unable to deduce N:
template
struct FixedString
{
char buf[N + 1]{};
constexpr FixedString(char const* s) {
for (unsigned i = 0; i != N; ++i) buf[i] = s[i];
}
auto operator<=>(const FixedString&) const = default;
constexpr operator char const*() const { return buf; }
constexpr static unsigned size() noexcept { return N; }
};
template FixedString(char const (&)[N]) -> FixedString;
template
struct name_list
{
template
using add_name = name_list<
names...,
FixedString{ name }
>;
};
int main()
{
using names =
name_list<>
::add_name<"Zaphod Beeblebrox">;
}
[Bug c++/92601] [9/10 Regression] error: type variant differs by TYPE_NEEDS_CONSTRUCTING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92601 --- Comment #1 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:091fe099ba9093b8577ad4a10b56e18c6ea3daea commit r10-6232-g091fe099ba9093b8577ad4a10b56e18c6ea3daea Author: Jason Merrill Date: Sat Jan 25 23:09:57 2020 -0500 checking: avoid verify_type_variant crash on incomplete type. Here, we end up calling gen_type_die_with_usage for a type that's in the middle of finish_struct_1, after we set TYPE_NEEDS_CONSTRUCTING on it but before we copy all the flags to the variants--and, significantly, before we set its TYPE_SIZE. It seems reasonable to only look at TYPE_NEEDS_CONSTRUCTING on complete types, since we aren't going to try to create an object of an incomplete type any other way. PR c++/92601 * tree.c (verify_type_variant): Only verify TYPE_NEEDS_CONSTRUCTING of complete types.
[Bug c++/93446] New: Improve -Wconversion warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93446
Bug ID: 93446
Summary: Improve -Wconversion warning message
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Code:
void foo() {
char c = 255;
}
GCC:
warning: conversion from 'int' to 'char' changes value from '255' to
'\377' [-Wconversion]
Clang:
warning: implicit conversion from 'int' to 'char' changes value from 255 to -1
[-Wconstant-conversion]
It would be great if GCC could match Clang here and show -1 instead of very
user unfriendly value \377.
[Bug other/93445] New: Misnamed git tags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93445 Bug ID: 93445 Summary: Misnamed git tags Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: joseph at codesourcery dot com Target Milestone: --- All annotated tags in the git repository have the wrong name: $ git cat-file -p releases/gcc-9.2.0 object a0c06cc27d2146b7d86758ffa236516c6143d62c type commit tag gcc_9_2_0_release tagger Jakub Jelinek 1565595539 +0200 Tagging source as tags/gcc_9_2_0_release
[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 Alexander Monakov changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9/10 Regression] |unswitching introduces |ssa-loop-im introduces |unconditional use of|unconditional use of |uninitialized variable |uninitialized variable --- Comment #1 from Alexander Monakov --- Actually, scratch that. I should have double-checked the order of arguments to dominated_by_p (and the tree dump). This code is not to blame. The problem starts earlier when tree-ssa-loop-im moves _7 = (int) y_21(D); out of the loop, making the access unconditional when it was conditional in the loop and actually unreachable at runtime. (editing the subject to reflect this, but keeping the regression marker)
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #127 from dave.anglin at bell dot net --- On 2020-01-25 9:16 p.m., peter.bisroev at groundlabs dot com wrote: > As can be seen above, stage1 binaries are just under 9 times the size of final > -O2 compiled binaries. I believe you have mentioned that this is due the use > of > -O0 for stage1 compilation. But is such increase as seen above expected? The stage1 sizes are much larger than I would have expected. However, I wouldn't worry about it since the compiler can rebuild itself. There must be a long pattern in ia64.md that's used a lot. Let's focus on issues important for c++.
[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 #15 from Jan Hubicka --- This is frequency scaled by #of executions: == Stats for /aux/hubicka/firefox2019-trunktest == stats for indirect_call: total: 160451 invalid: 542 (0.34%) freq:276193364 (33.87%) tracked values: 0 values: 134367 times (83.74%) freq:1338929 (0.16%) 1 values:21514 times (13.41%) freq: 264147030 (32.39%) 2 values: 3151 times (1.96%) freq: 136985793 (16.80%) 3 values: 866 times (0.54%) freq: 136555223 (16.75%) 4 values: 11 times (0.01%) freq: 248712 (0.03%) stats for topn: total: 7140 invalid: 24 (0.34%) freq:2147128 (15.00%) tracked values: 0 values: 6776 times (94.90%) freq:2107083 (14.72%) 1 values: 242 times (3.39%) freq: 6758801 (47.22%) 2 values: 79 times (1.11%) freq: 2233704 (15.60%) 3 values: 19 times (0.27%) freq: 1067609 (7.46%) 4 values:0 times (0.00%) freq: 0 (0.00%) So this makes invalidation rate quite high.
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 --- Comment #8 from Alexander Monakov --- Pasted that to new PR 93444 (should have done that right away, sorry).
[Bug tree-optimization/93444] New: [8/9/10 Regression] unswitching introduces unconditional use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
Bug ID: 93444
Summary: [8/9/10 Regression] unswitching introduces
unconditional use of uninitialized variable
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: ch3root at openwall dot com
Target Milestone: ---
Splitting out bug 93301 comments 6 and 7.
__attribute__((noipa))
static int opaque(int i) { return i; }
int main()
{
short x = opaque(1);
short y;
opaque(x - 1);
while (opaque(1)) {
__builtin_printf("x = %d; x - 1 = %d\n", x, opaque(1) ? x - 1 : 5);
if (opaque(1))
break;
if (x - 1 == y)
opaque(y);
}
}
Prints "x = 1; x - 1 = 5" at -O3.
Loop unswitching introduces an unconditional use of an uninitialized variable
which otherwise is conditional and 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.
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
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.
[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 #14 from Jan Hubicka --- > This seems reasonable well, 542/(21514+3151+866+11) = 2%. I think one needs to consider only calls that was trained and have at least two possible targets. With this metric it is more like 542/(3151+866+11) = 13% and it is really more about dynamic counts rather than static counts - I guess it would be nice to update your script to print weighted data by "all" counter. Also Firefox is actually quite easy testcase for merging since there are only 10 runs. The original indirect call does not seem to be handled, so I am benchmarking over the hacked gcc again: https://treeherder.mozilla.org/#/jobs?repo=try=286542225=4215cf907668d3b61e455c8d0c917689a83afdc1 But I do anticipate that build to crash on the speculative_call_info ICE I mentioned earlier. Lets see.
[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 #13 from Martin Liška --- (In reply to Jan Hubicka from comment #12) > This is stat for Firefox with current mainline. > > == Stats for firefox2019-trunktest == > stats for indirect_call: > total: 160451 > invalid: 542 > tracked values: > 0 values: 134367 times (83.74%) > 1 values:21514 times (13.41%) > 2 values: 3151 times (1.96%) > 3 values: 866 times (0.54%) > 4 values: 11 times (0.01%) This seems reasonable well, 542/(21514+3151+866+11) = 2%. > > stats for topn: > total: 7140 > invalid: 24 > tracked values: > 0 values: 6776 times (94.90%) > 1 values: 242 times (3.39%) > 2 values: 79 times (1.11%) > 3 values: 19 times (0.27%) > 4 values:0 times (0.00%) Apparently, these have very low coverage. Do we have a valid indirect call counter for teh original test-case?
[Bug c++/93443] gcc/cp/coroutines.cc:3555:23: runtime error: load of value 255, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93443 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-26 Version|9.0 |10.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug c++/93443] New: gcc/cp/coroutines.cc:3555:23: runtime error: load of value 255, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93443
Bug ID: 93443
Summary: gcc/cp/coroutines.cc:3555:23: runtime error: load of
value 255, which is not a valid value for type 'bool'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: iains at gcc dot gnu.org
Blocks: 63426
Target Milestone: ---
I see the following UBSAN which one can easily reproduce with:
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 81fb8c924a7..0c4014c27da 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3533,10 +3533,12 @@ morph_fn_to_coro (tree orig, tree *resumer, tree
*destroyer)
logically doing things related to the end of the function. */
/* done, we just need the return value. */
bool no_warning;
+ bool no_warning_initialized = false;
if (same_type_p (TREE_TYPE (gro), fn_return_type))
{
/* Already got the result. */
r = check_return_expr (DECL_RESULT (orig), _warning);
+ no_warning_initialized = true;
}
else
{
@@ -3552,6 +3554,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree
*destroyer)
}
r = build_stmt (input_location, RETURN_EXPR, DECL_RESULT (orig));
+ gcc_assert (no_warning_initialized);
TREE_NO_WARNING (r) |= no_warning;
r = maybe_cleanup_point_expr_void (r);
add_stmt (r);
$ g++ co-yield-03-tmpl.C -fcoroutines -c
co-yield-03-tmpl.C: In instantiation of ‘looper f() [with T = int]’:
co-yield-03-tmpl.C:105:25: required from here
co-yield-03-tmpl.C:99:1: internal compiler error: in morph_fn_to_coro, at
cp/coroutines.cc:3557
99 | }
| ^
0xb1389f morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
../../gcc/cp/coroutines.cc:3557
0xc43e5e finish_function(bool)
../../gcc/cp/decl.c:16853
0x103d3a1 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:25524
0x103e1e6 instantiate_pending_templates(int)
../../gcc/cp/pt.c:25620
0xc90f2a c_parse_final_cleanups()
../../gcc/cp/decl2.c:4871
0x13223d9 c_common_parse_file()
../../gcc/c-family/c-opts.c:1208
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/93442] New: lambda in if constexpr fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93442
Bug ID: 93442
Summary: lambda in if constexpr fails to compile
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at dominicp dot de
Target Milestone: ---
the following code:
--
struct bar {
int foo(){return 0;}
};
int foobar() {
if constexpr(true) {
return 0;
} else {
return [](){
return bar{};
}().foo();
}
}
---
is rejected with following error:
---
: In function 'int foobar()':
:11:10: error: invalid use of 'void'
9 | return [](){
|~
10 | return bar{};
| ~
11 | }().foo();
| ~^~
:11:13: error: expected ';' before 'foo'
11 | }().foo();
| ^~~
| ;
:11:13: error: 'foo' was not declared in this scope
11 | }().foo();
| ^~
-
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #6 from Alexander Cherepanov ---
(In reply to Alexander Cherepanov from comment #2)
> But my guess is that the C++ rules will not help. The problem is the
> internal inconsistency so everything will blow up independently of any
> external rules.
Well, the following example should illustrate what I mean. The uninitialized
variable `y` is only used in dead code:
--
#include
__attribute__((noipa)) // imagine it in a separate TU
static int opaque(int i) { return i; }
int main()
{
short x = opaque(1);
short y;
opaque(x - 1);
while (opaque(1)) {
printf("x = %d; x - 1 = %d\n", x, opaque(1) ? x - 1 : 5);
if (opaque(1))
break;
if (x - 1 == y)
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
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200126 (experimental)
--
There is some defence in tree-ssa-loop-unswitch.c against loop unswitching on
undefined values but, as you wrote in comment 1, it's probably not that easy.
[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 #12 from Jan Hubicka --- This is stat for Firefox with current mainline. == Stats for firefox2019-trunktest == stats for indirect_call: total: 160451 invalid: 542 tracked values: 0 values: 134367 times (83.74%) 1 values:21514 times (13.41%) 2 values: 3151 times (1.96%) 3 values: 866 times (0.54%) 4 values: 11 times (0.01%) stats for topn: total: 7140 invalid: 24 tracked values: 0 values: 6776 times (94.90%) 1 values: 242 times (3.39%) 2 values: 79 times (1.11%) 3 values: 19 times (0.27%) 4 values:0 times (0.00%)
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
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?
[Bug c/93441] New: _Generic selections ought to be treated as parenthesized expressions as far as -Wlogical-not-parentheses is concerned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93441 Bug ID: 93441 Summary: _Generic selections ought to be treated as parenthesized expressions as far as -Wlogical-not-parentheses is concerned Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pskocik at gmail dot com Target Milestone: --- int x [ _Generic(0,int: !0) < 10 ]; //falsely triggers -Wlogical-not-parentheses int y [ (_Generic(0,int: !0)) < 10 ]; //OK
[Bug tree-optimization/93440] scalar unrolled loop makes vectorized code unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93440 --- Comment #1 from ikonomisma at googlemail dot com --- Created attachment 47712 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47712=edit Minimal example c++ source code to trigger unreachable SIMD vector code
[Bug tree-optimization/93440] New: scalar unrolled loop makes vectorized code unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93440
Bug ID: 93440
Summary: scalar unrolled loop makes vectorized code unreachable
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ikonomisma at googlemail dot com
Target Milestone: ---
Created attachment 47711
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47711=edit
generated assemby code, showing unreachable SIMD vector code for
transform_reduce
With gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC) on x86-64, "-O3
-std=gnu++17 -march=core-avx2" emits both SIMD vectorized code and an unrolled
loop for "std::transform_reduce". The unrolled loop prevents the SIMD
vectorized code from executing for reasonable vector sizes. In contrast,
"std::inner_product" produces reachable vectorized code.
Minimal reproducing c++ code:
#include
#include
#include
auto workingvector(std::vector const& a, std::vector const& b)
{
return std::inner_product(cbegin(a), cend(a), cbegin(b), 0,
std::plus<>{}, std::multiplies<>{});
}
auto brokenvector(std::vector const& a, std::vector const& b)
{
return std::transform_reduce(cbegin(a), cend(a), cbegin(b), 0,
std::plus<>{},std::multiplies<>{});
}
Details:
The generated assembly for the "transform_reduce" checks for short vectors with
a signed comparison, so the vectorized code is *technically* reachable (for
completely infeasible vector sizes on a 64-bit address-space). If the vector
size is large enough for the unrolled scalar loop, the scalar loop processes
the entire vector, never allowing the SIMD vector code to execute.
[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense
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
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200126 (experimental)
--
[Bug tree-optimization/93439] New: [9/10 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439 Bug ID: 93439 Summary: [9/10 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6277 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf) ICEs when compiling the following testcase, reduced from gcc/testsuite/gfortran.dg/pr68251.f90, w/ -O2 -floop-parallelize-all -floop-unroll-and-jam -ftree-parallelize-loops=2: module ai integer, parameter :: dp = 8 contains subroutine qu(ja, nq, en, p5) real(kind = dp) :: nq(ja), en(ja), p5(ja) call tl(ja, nq, en, p5) end subroutine qu subroutine tl(ja, nq, en, p5) real(kind = dp) :: nq(9), en(9 * ja), p5(3 * ja) do mc = 1, ja do mb = 1, 9 do ma = 1, 3 p5((mc - 1) * 3 + ma) = p5((mc - 1) * 3 + ma) - 1 end do end do end do end subroutine tl end module ai % powerpc-e300c3-linux-gnu-gfortran-10.0.0-alpha20200119 -O2 -floop-parallelize-all -floop-unroll-and-jam -ftree-parallelize-loops=2 -c q5isrzrh.f90 during GIMPLE pass: unrolljam f951: internal compiler error: in gimple_duplicate_bb, at tree-cfg.c:6277 0x69ed73 gimple_duplicate_bb /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/tree-cfg.c:6277 0xa02382 duplicate_block(basic_block_def*, edge_def*, basic_block_def*, copy_bb_data*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cfghooks.c:1089 0xa02b57 copy_bbs(basic_block_def**, unsigned int, basic_block_def**, edge_def**, unsigned int, edge_def**, loop*, basic_block_def*, bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cfghooks.c:1357 0xa0eeef duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vec*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cfgloopmanip.c:1302 0x1012cd8 gimple_duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vec*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/tree-ssa-loop-manip.c:933 0xa11e9c loop_version(loop*, void*, basic_block_def**, profile_probability, profile_probability, profile_probability, profile_probability, bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cfgloopmanip.c:1702 0x1013421 tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*, tree_niter_desc*, void (*)(loop*, void*), void*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/tree-ssa-loop-manip.c:1278 0x1692a08 tree_loop_unroll_and_jam /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimple-loop-jam.c:59 (While my target here is powerpc, the ICE is not target-specific.)
[Bug target/93412] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_add_overflow() at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93412 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/93412] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_add_overflow() at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93412
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a9947bac0799b0c91e21b7c612b80cd0b54016f0
commit r10-6230-ga9947bac0799b0c91e21b7c612b80cd0b54016f0
Author: Jakub Jelinek
Date: Sun Jan 26 12:12:36 2020 +0100
i386: Fix up *{add,sub}v4_doubleword patterns (PR target/93412)
In the *{add,sub}v4_doubleword patterns, we don't really want to see a
VOIDmode last operand, because it then means invalid RTL
(sign_extend:{TI,POI} (const_int ...)) or so, and therefore something we
don't really handle in the splitter either. We have
*{add,sub}v4_doubleword_1 pattern for those and that is what combine
will match, the problem in this testcase is just that it was only RA that
propagated the constant into the instruction.
In the similar *{add,sub}v4 patterns, we make sure not to accept
VOIDmode operand and similarly to these have _1 suffixed variant that
allows
constants.
2020-01-26 Jakub Jelinek
PR target/93412
* config/i386/i386.md (*addv4_doubleword, *subv4_doubleword):
Use nonimmediate_operand instead of x86_64_hilo_general_operand and
drop from constraint of last operand.
* gcc.dg/pr93412.c: New test.
[Bug target/93430] [10 Regression] ICE in final_scan_insn_1, at final.c:3073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93430 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/93430] [10 Regression] ICE in final_scan_insn_1, at final.c:3073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93430
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:322db86f4b4df1261308e8a02e69018d9cea98e9
commit r10-6229-g322db86f4b4df1261308e8a02e69018d9cea98e9
Author: Jakub Jelinek
Date: Sun Jan 26 12:10:48 2020 +0100
i386: Fix up *avx_vperm_broadcast_v4df [PR93430]
Apparently my recent patch which moved the *avx_vperm_broadcast* and
*vpermil* patterns before vpermpd broke the following testcase, the
define_insn_and_split matched always but the splitter condition only split
it if not -mavx2 for V4DFmode, basically relying on the vpermpd pattern to
come first.
The following patch fixes it by moving that part of SPLIT-CONDITION into
CONDITION, so that when it is not met, we just don't match the pattern
and thus match the later vpermpd pattern in that case.
Except, for { 0, 0, 0, 0 } permutation, there is actually no reason to do
that, vbroadcastsd from memory seems to be slightly cheaper than vpermpd
$0.
2020-01-26 Jakub Jelinek
PR target/93430
* config/i386/sse.md (*avx_vperm_broadcast_): Disallow for
TARGET_AVX2 and V4DFmode not in the split condition, but in the
pattern condition, though allow { 0, 0, 0, 0 } broadcast always.
* gcc.dg/pr93430.c: New test.
* gcc.target/i386/avx2-pr93430.c: New test.
[Bug analyzer/93438] New: ICE in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93438
Bug ID: 93438
Summary: ICE in operator[], at vec.h:867
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-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling the following testcase w/ -fanalyzer:
void
tw (int **la, int pk)
{
int *ow = *la;
int jo = !!pk;
if (jo == 0)
*la =
tw (, pk);
}
% gcc-10.0.0-alpha20200119 -fanalyzer -c yxwf0zfa.c
during IPA pass: analyzer
yxwf0zfa.c: In function 'tw':
yxwf0zfa.c:8:9: internal compiler error: in operator[], at vec.h:867
8 | *la =
| ^
0x719d3a vec::operator[](unsigned int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/vec.h:867
0x71adee vec::operator[](unsigned int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/tree.h:3392
0x71adee vec::operator[](unsigned int) const
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/vec.h:1424
0x71adee stack_region::get_frame_rid(unsigned int) const
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.h:1367
0x71adee region_model::get_lvalue_1(path_var, region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:4665
0x11007d3 region_model::get_lvalue(path_var, region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:4712
0x11009d4 region_svalue::merge_values(region_svalue const&, region_svalue
const&, svalue_id*, tree_node*, model_merger*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:509
0x1100bd0 model_merger::can_merge_values_p(svalue_id, svalue_id, svalue_id*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:6717
0x1100f01 map_region::can_merge_p(map_region const*, map_region const*,
map_region*, region_id, model_merger*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:1906
0x11012be stack_region::can_merge_p(stack_region const*, stack_region const*,
model_merger*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:2657
0x110178c stack_region::can_merge_p(stack_region const*, stack_region const*,
model_merger*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/vec.h:1411
0x110178c root_region::can_merge_p(root_region const*, root_region const*,
root_region*, model_merger*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:3057
0x11018d2 region_model::can_merge_with_p(region_model const&, region_model*,
svalue_id_merger_mapping*) const
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:6343
0x10ef42e program_state::can_merge_with_p(program_state const&, extrinsic_state
const&, program_state*) const
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/program-state.cc:909
0x10df5a3 exploded_graph::get_or_create_node(program_point const&,
program_state const&, state_change*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:1892
0x10e21e9 exploded_graph::process_node(exploded_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2450
0x10e29b2 exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2253
0x10e3039 impl_run_checkers(logger*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3570
0x10e3ad3 run_checkers()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3624
0x10d9558 execute
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/analyzer-pass.cc:84
