On 23/08/12 15:35, Gustavo Sverzut Barbieri wrote: > On Thu, Aug 23, 2012 at 9:14 AM, Enlightenment SVN < > no-re...@enlightenment.org> wrote: > >> Log: >> Eo: Fixed issue with eo_add ops. >> >> This "fix" is actually just making sure gcc doesn't optimise things >> wrong. If anyone has an idea how to do it better, please let me know. >> klass is usually a function and needs to be evaluated before the call to >> eo_add_internal. >> > ... > >> - (void) klass; \ >> - eo_add_internal(klass, parent, eo_constructor(), ## __VA_ARGS__, >> EO_NOOP); \ >> + volatile const Eo_Class *_tmp_klass = klass; \ >> + eo_add_internal((const Eo_Class *) _tmp_klass, parent, >> eo_constructor(), ## __VA_ARGS__, EO_NOOP); \ >> }) >> >> > this makes no sense. How would gcc give the result of a function as > parameter to another function without calling it first? It should always > happen, are you sure it's not? > > f(g()) will always evaluate g() before, get its return and give as > parameter for f(). > >
The problem is that eo_constructor and some of the other __VA_ARGS__ actually use vars that depend on "klass" being called first. The C standard doesn't define parameter evaluation order so I have to explicitly call it before, but for some reason, gcc with -O2 removed my call before eo_add_internal and only issued the function call after the other parameters have been evaluated which caused the annoying bug. Get my problem? -- Tom. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
