Viewing Issue Advanced Details Jump to Notes ]
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06335 Interface Major Always Jul 29, 2016, 04:53 Aug 2, 2016, 04:00
Tester Tafoid View Status Public Platform MAME (Official Binary)
Assigned To cuavas Resolution Fixed OS Windows Vista/7/8 (64-bit)
Status [?] Resolved   Driver
Version 0.176 Fixed in Version 0.177 Build Normal
Summary 06335: UI:: Input (general) selection menus do not display correctly or at all
Description Input (general) selection menus do not display correctly or at all.
Input (this machine) still works
Steps To Reproduce
Additional Information Does not manifest in DEBUG=1 build
Also, seems GCC 6.1.0 specific
Regression Version 0.176
Affected Sets / Systems UI:
Attached Files
png file icon general_menu.png (130,300 bytes)  Jul 29, 2016, 04:53 by Tafoid
Example of 0.176 64-bit Binary attempting an option within Input (general)

- Relationships
has duplicate 06344Closed all drivers: Menu INPUT GENERAL not is displayed 
related to 06342Resolvedcrazyc pc (pccga): System crashing while loading 

-  Notes
User avatar
Jul 29, 2016, 06:59
Paste from IRC:
<crazyc> The menu appears offscreen because customtop and custombottom aren't initialized.
* crazyc has quit ()
<cuavas> they're initialised to zero
<cuavas> it uses global_alloc_clear to create menu objects
<cuavas> bit pattern zero is zero in a float
<cuavas> see src/frontend/ui/menu.h:74
<cuavas> that's where it allocates menu objects
<cuavas> I know it's pretty bad practice to be depending on global_alloc_clear
<cuavas> but menu objects have been doing that all along
<cuavas> since before the move to C++
User avatar
Jul 29, 2016, 12:33
Confirmed as 32bit specific.
User avatar
Jul 29, 2016, 13:27
initializing hover, customtop e custombottom to 0 in the menu constructor does seem to fix the problem, though.
User avatar
Jul 29, 2016, 14:42
edited on: Jul 29, 2016, 14:43
Right, if you print customtop in the constructor (for menu_input_general) it equals 1.0. If memory is cleared before the constructorthen I can't explain that. And this is on a 64-bit build BTW.

User avatar
Jul 30, 2016, 02:34
So, can we no longer depend on global_alloc_clear actually giving a zeroed-out object at constructor entry? If that's the case, we're going to have a lot more work on our hands, because far too much of MAME depends on that behaviour.
User avatar
Jul 30, 2016, 04:54
the strange thing is that it's 32bit only.
User avatar
Jul 30, 2016, 05:45
Apparently GCC will optimize away the initial memset unless -flifetime-dse is disabled.
User avatar
Jul 30, 2016, 07:55
Ah here's the wording from the GCC manual:

In C++ the value of an object is only affected by changes within its lifetime: when the constructor begins, the object has an indeterminate value, and any changes during the lifetime of the object are dead when the object is destroyed. Normally dead store elimination will take advantage of this; if your code relies on the value of the object storage persisting beyond the lifetime of the object, you can use this flag to disable this optimization. To preserve stores before the constructor starts (e.g. because your operator new clears the object storage) but still treat the object as dead after the destructor you, can use ‘-flifetime-dse=1’. The default behavior can be explicitly selected with ‘-flifetime-dse=2’. ‘-flifetime-dse=0’ is equivalent to ‘-fno-lifetime-dse’.

So can someone with GCC6 add necessary code to the GENie lua to add -flifetime-dse=1 to build flags when GCC6 or later is detected? Otherwise global_alloc_clear is useless.
User avatar
Jul 30, 2016, 08:03
Attempted fix pushed.
User avatar
Jul 30, 2016, 12:37
> the strange thing is that it's 32bit only.
My 64-bit builds did show the issue and vas's patch does fix it for me.