06335: UI: Input (general) selection menus do not display correctly or at all

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
		Fixed in Git Commit		Github Pull Request #

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
Github Commit

Flags
Regression Version	0.176
Affected Sets / Systems	UI

Attached Files	general_menu.png (130,300 bytes) Jul 29, 2016, 04:53 Uploaded by Tafoid Example of 0.176 64-bit Binary attempting an option within Input (general)

No.12995 cuavas Administrator 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++
No.13005 Osso Moderator Jul 29, 2016, 12:33	Confirmed as 32bit specific.
No.13007 Osso Moderator Jul 29, 2016, 13:27	initializing hover, customtop e custombottom to 0 in the menu constructor does seem to fix the problem, though.
No.13009 crazyc Developer 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.
No.13012 cuavas Administrator 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.
No.13013 Osso Moderator Jul 30, 2016, 04:54	the strange thing is that it's 32bit only.
No.13014 AJR Developer Jul 30, 2016, 05:45	Apparently GCC will optimize away the initial memset unless -flifetime-dse is disabled.
No.13015 cuavas Administrator 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.
No.13016 cuavas Administrator Jul 30, 2016, 08:03	Attempted fix pushed.
No.13017 crazyc Developer 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.