bug#18699: 25.0.50; Windows 7: Odd length text property list

[Eli Zaretskii]

> Date: Mon, 13 Oct 2014 08:31:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18699@debbugs.gnu.org
> 
> The function add_font_entity_to_list is decorated with a GCC attribute
> that should cause GCC to emit a few instructions in the function's
> prologue to ensure the stack is 8-byte aligned.  Do you see that in the
> disassembly of that function?  If not, can you show the preprocessed
> source of the first few line of that function, including its
> definition line?

Here's what I see in the preprocessed source on my machine:

  static int __attribute__((__stdcall__)) 
__attribute__((force_align_arg_pointer))
  add_font_entity_to_list (ENUMLOGFONTEX *logical_font,
      NEWTEXTMETRICEX *physical_font,
      DWORD font_type, LPARAM lParam)
  {
    struct font_callback_data *match_data
      = (struct font_callback_data *) lParam;
    Lisp_Object backend = match_data->opentype_only ? Quniscribe : Qgdi;
    Lisp_Object entity;

The important part is the force_align_arg_pointer attribute.

This is set up in w32term.h, like this:

  #ifdef __GNUC__
  # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__     \
    && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5
  #  define ALIGN_STACK __attribute__((force_align_arg_pointer))
  # else
  #  define ALIGN_STACK
  # endif  /* USE_STACK_LISP_OBJECTS */
  #endif

Is it possible that the MinGW64 compiler somehow trips here?  E.g., is
it possible that, even in a 32-bit build, it defines _W64 or
__x86_64__?  If so, what other preprocessor macros are available in
MinGW64 to distinguish between a 32-bit and a 64-bit build?