"Eli Zaretskii" <eliz@gnu.org> writes:
Date: Sun, 15 Dec 2024 10:55:49 +0000
From: Pip Cet <pipcet@protonmail.com>
Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
"Eli Zaretskii" <eliz@gnu.org> writes:
CC igc.o
igc.c: In function 'weak_hash_table_entry':
igc.c:4102:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
4102 | client = (mps_addr_t)entry.intptr;
| ^
igc.c:4107:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
4107 | client = (mps_addr_t)real_ptr;
| ^
The warnings are real, because mps_addr_t is a 'void *', so a 32-bit
data type, whereas entry.intptr is EMACS_UINT, so an unsigned 64-bit
type.
Oh, sorry for causing those.
The intended behavior is to truncate the integer and use the 32 LSB
bits, which is safe on the machines MPS is ported to, and is expressed
using a cast to mps_addr_t. So the code behaves correctly, but is
incorrect because it causes a compiler warning.
What about the (hypothetical) case of big-endian systems?
Not a problem here, but there is some good news concerning the
"hypothetical" part: I'm testing 32-bit builds on a sparc system, so
it's no longer hypothetical (thanks again to the cfarm people for giving
me an account).
The bad news is that while MPS works when Emacs is run normally in a
non-wide-int build, running Emacs in GDB does not work: the siginfo_t
information passed to the SIGSEGV handler isn't preserved. Currently,
the --with-wide-int build infloops rather than crashing or working, but
I can't attach a debugger, so I'll have to learn how to trigger (and
find) a core dump on this system.
It's possible this problem is an unavoidable vicious cycle: since
small integers are easily confused with pointers on this system, more
objects are "ambiguously" recognized as reachable even though they
aren't actually reachable; that causes more objects to be retained,
which causes more integer values to be treated as potential pointers,
resulting in even more retained objects, until finally we run out of
virtual memory. At least that would explain the 2 GB core file...
What's the preferred way of avoiding a compiler warning in this case?
A simple double cast (first to uintptr_t, then to mps_addr_t) should
work, right?
I'll defer to Paul (CC'ed), but my personal preference is also to
explicitly reset the ignored bits by bitwise AND.
Either way sounds good to me, and I expect both ways will result in
future compiler warnings (hopefully, these future compilers will also
have a better way of indicating that a cast from a 64-bit integer to a
32-bit pointer is intended here).
However, profiling doesn't work, whereas it did
in the "normal" 32-bit build. (Note that SIGPROF is emulated on
Windows, so maybe that emulation somehow causes this problem when wide
ints are used with MPS.)
Thanks for letting me know! That certainly sounds like a regression we
should fix. What kind of problem are we talking about?
However, I repeated the test now, and I see that the profile does
work. I guess yesterday wins my personal record of producing
irreproducible results: this one and the one with
completion-at-point-functions in another discussion.
Sorry for the noise.
No problem at all, and thank you!
Pip