On 20 January 2016 at 17:43, Iain Buclaw <ibuc...@gdcproject.org> wrote:
> On 20 January 2016 at 17:40, Matthias Klose <d...@debian.org> wrote:
>>
>> On 20.01.2016 16:56, Iain Buclaw wrote:
>>>
>>> On 20 January 2016 at 10:48, Peter De Wachter <pdewa...@gmail.com> wrote:
>>>
>>>> Package: gdc-6
>>>> Version: 6-20160117-1
>>>> Severity: normal
>>>>
>>>> Dear Maintainer,
>>>>
>>>> This program fails to compile in this gdc snapshot:
>>>>
>>>> void main() {
>>>> real[] a = [-1];
>>>> }
>>>>
>>>> It is accepted by both gdc-5 and the dmd reference compiler.
>>>>
>>>>
>>> I'm sure I would have noticed if this was happening in upstream gdc.
>>> However I don't want to be quick to point towards some local debian patch
>>> causing the problem. Are there debug builds to test?
>>
>>
>> DEB_BUILD_OPTIONS="nocheck nolang=ada,java,objc,obj-c++ gccdebug
>> parallel=8" dpkg-buildpackage ...
>>
>
> Thanks, just building now...
OK, I've finally been able to reproduce using this compiler to build
itself. Previously I was using an older snapshot of a couple weeks.
It looks like something has gone awry with the "fake" real_value type.
Increasing or Decreasing the stub static array by 1 makes the problem gone.
---
// Including gcc/real.h presents too many problems, so
// just statically allocate enough space for REAL_VALUE_TYPE.
#define REALSZ (16 + sizeof (long))/sizeof (long)
#if 1
int exp[2]; // OK
#else
int exp[3]; // Bad
#endif
long sig[REALSZ];
---
Now, when using int[3] in the original code, there is 4 bytes of
padding added after it. But this shouldn't be a problem... unless
perhaps GCC has started passing the fake type in registers instead of
on the stack, hmm.
In any case, I know at least how to make it not fail. Having it as
one array is probably the right way to go though.
Iain.
