[Bug analyzer/96608] New: Build failure due to cast to type long on MinGW

[Bug analyzer/96608] New: Build failure due to cast to type long on MinGW

[markus.boeck02 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

            Bug ID: 96608
           Summary: Build failure due to cast to type long on MinGW
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: markus.boeck02 at gmail dot com
  Target Milestone: ---

Current trunk (revision 808f4dfeb3a95f50f15e71148e5c1067f90a126d) fails when
using the MinGW target due to a few casts to the type long which is 32 bit on
Windows. Following compiler errors appear:

In file included from ../../gcc/analyzer/checker-path.cc:51:
../../gcc/analyzer/store.h: In member function 'hashval_t
ana::symbolic_binding::hash() const':
../../gcc/analyzer/store.h:271:41: error: cast from 'const ana::region*' to
'long int' loses precision [-fpermissive]
  271 |     return (binding_key::impl_hash () ^ (long)m_region);
      |                                         ^~~~~~~~~~~~~~

With the same error appearing roughly 10 times through the code base.
Compiler used was GCC 10.2.1.

Compilation command:
x86_64-w64-mingw32-g++-10  -fno-PIE -c   -fdebug-prefix-map=/mnt/c=C: -g
-march=nehalem -O3 -I/mnt/c/GCC-Build/NewestLinux/Libraries/include -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag  -fno-common  -DHAVE_CONFIG_H -I. -Ianalyzer
-I../../gcc -I../../gcc/analyzer -I../../gcc/../include
-I../../gcc/../libcpp/include
-I/mnt/c/GCC-Build-Array/gcc/build-target-i686/./gmp
-I/mnt/c/GCC-Build-Array/gcc/gmp
-I/mnt/c/GCC-Build-Array/gcc/build-target-i686/./mpfr/src
-I/mnt/c/GCC-Build-Array/gcc/mpfr/src -I/mnt/c/GCC-Build-Array/gcc/mpc/src 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace
-I/mnt/c/GCC-Build-Array/gcc/build-target-i686/./isl/include
-I/mnt/c/GCC-Build-Array/gcc/isl/include
-I/mnt/c/GCC-Build/NewestLinux/Libraries/include -o analyzer/checker-path.o -MT
analyzer/checker-path.o -MMD -MP -MF analyzer/.deps/checker-path.TPo
../../gcc/analyzer/checker-path.cc

[Bug analyzer/96608] Build failure due to cast to type long on MinGW

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
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.

[Bug analyzer/96608] Build failure due to cast to type long on MinGW

[markus.boeck02 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

--- Comment #2 from Markus Böck <markus.boeck02 at gmail dot com> ---
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

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trass3r at gmail dot com

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
*** Bug 96659 has been marked as a duplicate of this bug. ***

[Bug analyzer/96608] Build failure due to cast to type long on MinGW

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

--- Comment #7 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[pexu@gcc-bugzilla.mail.kapsi.fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

Pekka S <pexu@gcc-bugzilla.mail.kapsi.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pexu@gcc-bugzilla.mail.kaps
                   |                            |i.fi

--- Comment #9 from Pekka S <pexu@gcc-bugzilla.mail.kapsi.fi> ---
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

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2020-10-27

--- Comment #10 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
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

[pexu@gcc-bugzilla.mail.kapsi.fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

--- Comment #11 from Pekka S <pexu@gcc-bugzilla.mail.kapsi.fi> ---
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

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brechtsanders at users dot sourcef
                   |                            |orge.net

--- Comment #12 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
*** Bug 97614 has been marked as a duplicate of this bug. ***

[Bug analyzer/96608] Build failure due to cast to type long on MinGW

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|WAITING                     |RESOLVED

--- Comment #13 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks; I'm going to mark this bug as resolved, then.

[Bug analyzer/96608] Build failure due to cast to type long on MinGW

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

--- Comment #14 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
           Keywords|                            |build

[Bug analyzer/96608] Build failure due to cast to type long on MinGW

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |euloanty at live dot com

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 97262 has been marked as a duplicate of this bug. ***