[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 Andrew Pinski changed: What|Removed |Added CC||euloanty at live dot com --- Comment #15 from Andrew Pinski --- *** Bug 97262 has been marked as a duplicate of this bug. ***
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||build
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #14 from David Malcolm --- (In reply to David Malcolm from comment #7) > (In reply to Andrew Pinski from comment #6) > > What I mean is if you ever traversing a hashtable, the hash should not use > > the value of a pointer because it could change between runs. > > Thanks. > > Unfortunately I'm doing that in quite a few places in the new > implementation, I think. > > The new implementation folds instances of symbolic values and regions into > unique instances, and then uses pointer equality on them (which is good), > and also pointer hashing (which is likely bad, and likely leading to > changeable results). > > I suspect what I need to do is to come up with a deterministic hash for each > of these objects that doesn't rely on pointer values, and to use that value > instead, rather than their addresses. Given the uniqueness of > values/regions per analysis run, I think I'll add a globally unique ID per > value/region and base the hash off of that. > > There are a few places I'm hashing based on trees, for constants and types. > Is there a good way to hash those? (avoiding pointer values) In the end I went with a different approach, sorting the objects into a deterministic order whenever dealing with the results of an iteration over an hash_map or hash_set. So the hash value still depends on the pointer value (and thus can change from run to run), but the result of the iteration does not. See e.g. r11-4434.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #13 from David Malcolm --- Thanks; I'm going to mark this bug as resolved, then.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 David Malcolm changed: What|Removed |Added CC||brechtsanders at users dot sourcef ||orge.net --- Comment #12 from David Malcolm --- *** Bug 97614 has been marked as a duplicate of this bug. ***
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #11 from Pekka S --- Hi, that indeed does solve the build issue, though I only tried using --disable-analyzer. I've been using a similar patch up until this point, but retired my local patch in favour of this. Thanks!
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-10-27 --- Comment #10 from David Malcolm --- I've pushed Markus's patch here: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555148.html to master as g:942086bf73ee2ba6cfd7fdacc552940048437a6e though for some reason this bug didn't get auto-notified. My reply to his email is here: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557204.html Does this resolve the build issues seen on MinGW?
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
||i.fi
--- Comment #9 from Pekka S ---
Any updates on this? --disable-analyzer does not unfortunately resolve this
problem as analyzer objects are always built and ENABLE_ANALYZER does not gate
any header files that would be required by the code.
The quick and dirty way of resolving this problem would be:
hashval_t hash () const
{
-return (binding_key::impl_hash () ^ (long)m_region);
+return (binding_key::impl_hash () ^ (long)(uintptr_t)m_region);
}
But perhaps that would simply suppress a valid error if the implementation
expects that no precision is lost.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #8 from Andrew Pinski --- (In reply to David Malcolm from comment #7) > There are a few places I'm hashing based on trees, for constants and types. > Is there a good way to hash those? (avoiding pointer values) Maybe iterative_hash_expr ?
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #7 from David Malcolm --- (In reply to Andrew Pinski from comment #6) > What I mean is if you ever traversing a hashtable, the hash should not use > the value of a pointer because it could change between runs. Thanks. Unfortunately I'm doing that in quite a few places in the new implementation, I think. The new implementation folds instances of symbolic values and regions into unique instances, and then uses pointer equality on them (which is good), and also pointer hashing (which is likely bad, and likely leading to changeable results). I suspect what I need to do is to come up with a deterministic hash for each of these objects that doesn't rely on pointer values, and to use that value instead, rather than their addresses. Given the uniqueness of values/regions per analysis run, I think I'll add a globally unique ID per value/region and base the hash off of that. There are a few places I'm hashing based on trees, for constants and types. Is there a good way to hash those? (avoiding pointer values)
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #6 from Andrew Pinski --- (In reply to David Malcolm from comment #5) > (In reply to Andrew Pinski from comment #4) > > Do we ever transverse the hashtable that use symbolic_binding? If so using > > the pointer value should almost never use really. > > Andrew: sorry, I'm having difficulty parsing and understanding your comment. > Could you rephrase it please? Sory I had a spelling mistake. What I mean is if you ever traversing a hashtable, the hash should not use the value of a pointer because it could change between runs.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #5 from David Malcolm --- (In reply to Andrew Pinski from comment #4) > Do we ever transverse the hashtable that use symbolic_binding? If so using > the pointer value should almost never use really. Andrew: sorry, I'm having difficulty parsing and understanding your comment. Could you rephrase it please?
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #4 from Andrew Pinski --- Do we ever transverse the hashtable that use symbolic_binding? If so using the pointer value should almost never use really.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 David Malcolm changed: What|Removed |Added CC||trass3r at gmail dot com --- Comment #3 from David Malcolm --- *** Bug 96659 has been marked as a duplicate of this bug. ***
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #2 from Markus Böck --- Don't worry there's no rush! It's the master branch after all. Just wanted to make sure people are aware of it as soon as possible.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #1 from David Malcolm --- Thanks for filing this; sorry for not fixing this today, I hope to get to this early next week. If you need a temporary workaround to unbreak your build, the analyzer code can be disabled altogether at configure time when building GCC via --disable-analyzer.
