Unittest fails in tango.text.convert.Layout using gdc

I get tango.core.Exception.AssertException@Layout.d(589): false. GDC on Mac OS X.

Which release? Line 589 will not currently give you that msg

Rev [2590]

huh?

http://dsource.org/projects/tango/browser/trunk/tango/text/convert/Layout.d

is not 2590?

BTW: Layout passes the unittest on Win32, which is why I'm asking which version. Do you have any debugging capability for this, Carlos?

I meant I was using Tango rev [2590], which includes rev [2465] for Layout.d.

I can debug it with dbg. The most relevant information from a debugging session seems to be this:

Breakpoint 3, _D5tango4text7convert6Layout13__T6LayoutTaZ6Layout5mungeMFAaAaC8TypeInfoPaZAa (this=@0x407ff0, result={length = 384, ptr = 0xbfffeca4 "???h"}, format={length = 0, ptr = 0x0}, type=@0x2e2d4, p=0xbffff10c "") at Layout.d:417
417                                 return unknown (result, format, type, p);

Which is in Layout.munge. So, apparently that switch is not working too well because if I print type.classinfo.name[9], I get b. Maybe a GDC codegen bug? Can somebody else confirm?

oh, man :(

hang on ... your original message indicates it emits false ... not the default?

Ok, turns out that the debugger was wrong and it wasn't going to line 417. The whole thing seems to be an architecture problem.

It is now line 766, and is still a problem in

gdc (GCC) 4.1.3 20070831 (prerelease gdc 0.25, using dmd 1.021) (Ubuntu 0.25-4.1.2-16ubuntu1)

can you communicate this to David Friedman, please?

The problem seems to be from the fact that variadic arguments of some types can only be accessed using va_arg!(Type)(_argptr) template instead of casting _argptr directly.

The attached patch seems to solve the problem (at least the 1.23f thingy).

Marius: Thanks for the patch, however it ignores the fact that the X86_64 block actually is a workaround for http://d.puremagic.com/issues/show_bug.cgi?id=1805.

The other codepath not using stdarg works perfectly for DMD, and mostly for GDC on 32 bit targets. It does disclose some interesting artifacts though that we're not yet certain of, and that may make it possible to find a workaround for the issue of the failing unittest.

The interesting artifact mentioned above is that the failing unittest actually works for 32 bit x86 if formatting is done through the x86_86 code path. No idea what I should conclude from that. Fixing bugzilla 1805 for GDC would resolve all these issues though.

This now works also for x86 - using the same workaround for all platforms when using GDC (see #1015).