From: David J. <dat...@gm...> - 2007-05-15 13:22:17
|
hello, i think i found a bug in the sdcc pic16 port: struct foo { int a; }; struct foo f={1}; struct foo *g=&f; $ sdcc -c -mpic16 -p18f452 bug.c Internal error: validateLink failed in SPEC_SCLS(cexpr->etype) @ SDCCast.c:1513: expected SPECIFIER, got null-link I would like to fix this bug, does anyone know what might be the cause of this bug? David Janssens |
From: Raphael N. <rn...@we...> - 2007-05-20 18:03:39
Attachments:
init-ptr-struct.patch
|
Hi David, Sorry for the rather late reply... > i think i found a bug in the sdcc pic16 port: Yep, you have. > struct foo *g=&f; > > $ sdcc -c -mpic16 -p18f452 bug.c > Internal error: validateLink failed in SPEC_SCLS(cexpr->etype) @ > SDCCast.c:1513: expected SPECIFIER, got null-link > > I would like to fix this bug, does anyone know what might be the cause > of this bug? The initialized struct foo* g is causing trouble. The workaround is to have g = &f; somewhere early in your program, e.g. in your main(). To avoid the assertion, you may apply the attached patch using patch -p0 < init-ptr-struct.patch in sdcc/src/pic16. It actually fixes this bug and makes it into a missing feature ;-). The patch may also guide you as to where to look for implementing this feature. Patches would be highly appreciated, though if I recall correctly, this bug is related to spurious symbol allocations in the backend, which leaves out requried type information and thus causes this (and other kinds of) trouble. So, this is not likely to require a simple, local fix somewhere in the backend but rather a more or less global approach... I will rework the initialization code over the next months (?) and also try to get rid of these spurious symbols, referencing the `real' ones instead. So do not waste too much time on this one. Regards, Raphael |
From: Borut R. <bor...@si...> - 2007-05-21 16:04:59
|
Raphael, is this something that should be fixed also for the release? Borut Raphael Neider wrote: > Hi David, > > Sorry for the rather late reply... > >> i think i found a bug in the sdcc pic16 port: > > Yep, you have. > >> struct foo *g=&f; >> >> $ sdcc -c -mpic16 -p18f452 bug.c >> Internal error: validateLink failed in SPEC_SCLS(cexpr->etype) @ >> SDCCast.c:1513: expected SPECIFIER, got null-link >> >> I would like to fix this bug, does anyone know what might be the >> cause of this bug? > > The initialized struct foo* g is causing trouble. The workaround is to > have > g = &f; > somewhere early in your program, e.g. in your main(). > > To avoid the assertion, you may apply the attached patch using > patch -p0 < init-ptr-struct.patch > in sdcc/src/pic16. It actually fixes this bug and makes it into a > missing feature ;-). The patch may also guide you as to where to look > for implementing this feature. Patches would be highly appreciated, > though if I recall correctly, this bug is related to spurious symbol > allocations in the backend, which leaves out requried type information > and thus causes this (and other kinds of) trouble. So, this is not > likely to require a simple, local fix somewhere in the backend but > rather a more or less global approach... > > I will rework the initialization code over the next months (?) and > also try to get rid of these spurious symbols, referencing the `real' > ones instead. So do not waste too much time on this one. > > Regards, > Raphael |
From: Raphael N. <rn...@we...> - 2007-05-21 20:15:14
|
Hi Borut, > is this something that should be fixed also for the release? The patch does avoid the assertion and raises an incorrect warning instead: at 5: error 129: pointer types incompatible I would say that this message is more helpful (line 5 is correctly pointing at the problem) than the assertion, so it would probably make sense to include the patch in the release. I did not ask to include it just because I... don't know why, code freeze and all... This patch is very unlikely to break anything, so yeah, why not include it? Shall I proceed? >>> struct foo *g=&f; >>> >>> $ sdcc -c -mpic16 -p18f452 bug.c >>> Internal error: validateLink failed in SPEC_SCLS(cexpr->etype) @ >>> SDCCast.c:1513: expected SPECIFIER, got null-link >>> >> The initialized struct foo* g is causing trouble. The workaround is to >> have >> g = &f; >> somewhere early in your program, e.g. in your main(). >> >> To avoid the assertion, you may apply the attached patch using >> patch -p0 < init-ptr-struct.patch >> in sdcc/src/pic16. It actually fixes this bug and makes it into a >> missing feature ;-). The patch may also guide you as to where to look >> for implementing this feature. Patches would be highly appreciated, >> though if I recall correctly, this bug is related to spurious symbol >> allocations in the backend, which leaves out requried type information >> and thus causes this (and other kinds of) trouble. So, this is not >> likely to require a simple, local fix somewhere in the backend but >> rather a more or less global approach... |
From: Borut R. <bor...@si...> - 2007-05-21 20:41:20
|
Raphael Neider wrote: > Hi Borut, > > >> is this something that should be fixed also for the release? >> > > The patch does avoid the assertion and raises an incorrect warning instead: > at 5: error 129: pointer types incompatible > I would say that this message is more helpful (line 5 is correctly > pointing at the problem) than the assertion, so it would probably make > sense to include the patch in the release. I did not ask to include it > just because I... don't know why, code freeze and all... > > This patch is very unlikely to break anything, so yeah, why not include > it? Shall I proceed? > > Yes if it will be done early enough to be included in the tomorrow snapshot build. It would be probably wise to submit a bug report too. Will you do it? Borut |
From: Raphael N. <rn...@we...> - 2007-05-25 11:17:07
|
Hi, Borut Razem wrote: > It would be probably wise to submit a bug report too. Will you do it? Just for the records: I opened bug report #1723280 (Initialized pointers to structs are not supported) for this. Regards, Raphael |