Thanks Michael, Yes I started looking in struct_decl. Is there a reason why it doesn't use an efficient unordered map for lookup, other than the extra code weight?
I have an extremely efficient, generic map implementation, which is faster than most speedy c++ implementation, see "Performance" at https://github.com/tylov/C99Containers If that (and the cstr string type) is stripped down to its bare minimum, it would be perfect for general symbol tables. The only other fast C map I know of is khash (https://attractivechaos.github.io/klib), however not memory efficient, and the codebase is somewhat bigger. But, looking at tccgen.c, it may be too ambitious to integrate? ps: I haven't really looked much at the core code yet; I do have some compiler tech experience way back from creating an external syntax checker for www.autoitscript.com, using flex and yacc. ( http://www.google.com/search?q=au3check) Cheers, Tyge On Sat, 28 Nov 2020 at 00:32, Michael Matz <matz....@frakked.de> wrote: > Hello, > > On Fri, 27 Nov 2020, Tyge Løvset wrote: > > > Is this a known bug, or regression? > > Known bug. > > > I tried to follow the code in parse_btype() in tccgen.c for the missing > > struct member symbol lookup check, but didn't succeed so far: > > > > } else { > > c = 0; > > flexible = 0; > > while (tok != '}') { > > if (!parse_btype(&btype, &ad1)) { > > skip(';'); > > continue; > > } > > Member lookup is linear, so checking for duplicates is quadratic, so TCC > doesn't bother to do it. The check would belong to struct_decl, not > parse_btype, probably involving find_field before adding it. > > > Ciao, > Michael._______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
