[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484 --- Comment #6 from Martin Liška --- (In reply to Jakub Jelinek from comment #5) > Author: jakub > Date: Thu May 16 21:45:34 2019 > New Revision: 271299 > > URL: https://gcc.gnu.org/viewcvs?rev=271299=gcc=rev > Log: > PR c++/90484 > * tree-ssa-scopedtables.c (equal_mem_array_ref_p): Don't assert that > sz0 is equal to sz1, instead return false in that case. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/tree-ssa-scopedtables.c Thanks Jakub for the patch. Are you planning to backport that to GCC-9 branch soon?
[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Thu May 16 21:45:34 2019 New Revision: 271299 URL: https://gcc.gnu.org/viewcvs?rev=271299=gcc=rev Log: PR c++/90484 * tree-ssa-scopedtables.c (equal_mem_array_ref_p): Don't assert that sz0 is equal to sz1, instead return false in that case. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-scopedtables.c
[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 46365 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46365=edit gcc10-pr90484.patch Untested fix, so far just verified on gcc-9-branch that without it it ICEs and with it it doesn't.
[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484 --- Comment #3 from Richard Biener --- (In reply to Jakub Jelinek from comment #2) > I bet the above mentioned commit just tweaked things so that we now compare > in a hash table something we didn't compare before. > equal_mem_array_ref_p is called with: > t0 > MEM[(struct BorderValue *) + 16B].m_isAuto > with > size bitsizetype> constant 8> > unit-size sizetype> constant 1> > align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type > 0x7fffe32ccb28 precision:1 min max > > > type, and > t1 > MEM[(bool *)this_59(D) + 722B] > with a const bool type. > As both types are unsigned integral types with precision 1, they are > considered compatible. > But because one is a COMPONENT_REF and m_isAuto is 1-bit bitfield, we get > sz0 and max0 1-bit (for COMPONENT_REFs we use DECL_SIZE of the FIELD_DECL, > so 1-bit), while the other is a MEM_REF with bool type and we use mode size > of the QImode. > types_compatible_p guarantees that the mode is the same and precision is the > same, but it doesn't apply we use the mode or precision in both cases. > > So, the > /* Types were compatible, so this is a sanity check. */ > gcc_assert (known_eq (sz0, sz1)); > looks bogus to me, either we should just punt if the sizes aren't equal, or > we should ignore the sizes (just remove the assert). Since we hash the size the correct thing to do is return false for maybe_ne (sz0, sz1) > I believe this bug is latent since r232559, before that change it used to > handle just MEM_REF and ARRAY_REF and for those get_ref_base_and_extent uses > always the TYPE_SIZE for BLKmode types or mode size otherwise, so for > types_compatible_p necessarily the same thing.
[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I bet the above mentioned commit just tweaked things so that we now compare in a hash table something we didn't compare before. equal_mem_array_ref_p is called with: t0 MEM[(struct BorderValue *) + 16B].m_isAuto with constant 8> unit-size constant 1> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe32ccb28 precision:1 min max > type, and t1 MEM[(bool *)this_59(D) + 722B] with a const bool type. As both types are unsigned integral types with precision 1, they are considered compatible. But because one is a COMPONENT_REF and m_isAuto is 1-bit bitfield, we get sz0 and max0 1-bit (for COMPONENT_REFs we use DECL_SIZE of the FIELD_DECL, so 1-bit), while the other is a MEM_REF with bool type and we use mode size of the QImode. types_compatible_p guarantees that the mode is the same and precision is the same, but it doesn't apply we use the mode or precision in both cases. So, the /* Types were compatible, so this is a sanity check. */ gcc_assert (known_eq (sz0, sz1)); looks bogus to me, either we should just punt if the sizes aren't equal, or we should ignore the sizes (just remove the assert). I believe this bug is latent since r232559, before that change it used to handle just MEM_REF and ARRAY_REF and for those get_ref_base_and_extent uses always the TYPE_SIZE for BLKmode types or mode size otherwise, so for types_compatible_p necessarily the same thing.
[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-15 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed with -m32.
[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484 Martin Liška changed: What|Removed |Added Target||i586-linux-gnu Known to work||8.3.0 Version|unknown |9.1.0 Keywords||ice-on-valid-code CC||jason at gcc dot gnu.org Host||i586-linux-gnu Target Milestone|--- |9.2 Known to fail||10.0, 9.1.0
