GCC 11+ __attr_dealloc problems

[stephenrkell]

The prototype of reallocarray in the stdlib.h of at least some versions (Ubuntu?) of glibc 2.35 causes an interesting problem... the function is mentioned in its own __attr_dealloc attribute. The header breaks the reference cycle by prototyping the function twice: once with plain free declared as the dealloc function, and once then with reallocarray. This is not being merged correctly by CIL.

So really this is a CIL bug -- but my fork doesn't have its own issue tracker, and I don't want to report it upstream now that Gabriel has said he considers it unmaintained, so recording the bug here for now.

[stephenrkell]

The workaround is to use GCC 10 or earlier, because these attributes are disabled at this GNUC prereq level.

[stephenrkell]

I wonder whether @probablytom's recent attribute fixes may have improved things here or may suggest the right way to do so. The minimal-ish test case is something like...

extern void *myrealloc(void *__ptr) __attribute__ ((__malloc__ (__builtin_free, 1)));
/* Add also as its own deallocator. */
extern void *myrealloc(void *__ptr) __attribute__ ((__malloc__ (myrealloc, 1)));

void *myrealloc(void *__ptr) { return (void*)0; }

... where the final CIL dump should record two malloc attributes on the function, with different arguments. Can current CIL even represent that, I wonder?

And then on the output side, the necessity of the cycle-breaking trick in GCC is also going to make life interesting when we want to output the CIL as C code... we must somehow detect a cycle between the attribute and the attribute-bearing function, and then output multiple prototypes in order to break the cycle.

And our example here is a 1-cycle, but is a 2-cycle possible? Argh! It's doable though... maybe by threading some "deferred prototypes" through the printer.

[stephenrkell]

Suggestion: just focus on 1-cycles, i.e. self-reference, for now.

Experiment worth doing: for a 2-cycle, i.e. mutually attribute-referring functions, does the compiler require them to be forward-declared? If this issue just affects self-reference then that would be nice, although that seems optimistic.

[stephenrkell]

@difcsi reports that this does not surface on Ubuntu 25.10, using gcc 15 and presumably a recent glibc.

[difcsi]

@stephenrkell this might be because we turned off all the relevant testing/metadatagen due to the dwarf 5 issues. I'll try to reproduce with the snippet above!

[stephenrkell]

I can confirm that this works fine for me, i.e. the above snippet gives us the following out of CIL.

/* Generated by CIL v. 1.7.3 */
/* print_CIL_Input is true */

#line 1 "/tmp/test3.c"
void *myrealloc(void *__ptr )  __attribute__((__malloc__(__builtin_free,1))) ;
void *myrealloc(void *__ptr )  __attribute__((__malloc__(__builtin_free,1), __malloc__(myrealloc,1))) ; /* has total 3 decls */ 
#line 5
void *myrealloc(void *__ptr )  __attribute__((__malloc__(__builtin_free,1))) ;
void *myrealloc(void *__ptr )  __attribute__((__malloc__(__builtin_free,1), __malloc__(myrealloc,1))) ; /* attrs: extra prototype dump */
#line 5 "/tmp/test3.c"
void *myrealloc(void *__ptr ) /* comes from pVDecl with beginsFunDef; vinline is really false and the varinfo, magic 69950958330304, also has 3 entries in vvardecls */ 
{ 


  {
#line 5
  return ((void *)0);
}
}

I have confirmed this both on a few-months-old CIL revision and on our fork's current head. So I am scratching my head about why I reported a bug on this. It was definitely causing a failure to compile at some point, but I regrettably did not record it properly.

It could be that my own changes of ebf2f49 (which I had totally forgotten making!) suffice for this minimal example but not for the real glibc 2.35 headers?

The answer would be to drop the CircleCI config's forcing of GCC 10 and see what breaks.

[stephenrkell]

@difcsi but this should be orthogonal to DWARF 5. I hope we did not disable any aspect of testing that is pushing the test cases through CIL.

[difcsi]

Oh, this is a header issue!

They haven't changed the header; the cycle is still present, but CIL seems to be working with it. At least, it isn't crashing.

But this may be related to #179.

[difcsi]

The answer would be to drop the CircleCI config's forcing of GCC 10 and see what breaks.

See #177

[difcsi]

I can confirm that this works fine for me, i.e. the above snippet gives us the following out of CIL.

Same output on GLIBC 2.42! Can CIL the header too!

/* Generated by CIL v. 1.7.3 */
/* print_CIL_Input is true */

#line 229 "/usr/lib/gcc/x86_64-linux-gnu/15/include/stddef.h"
typedef unsigned long size_t;
#line 695 "/usr/include/stdlib.h"
extern  __attribute__((__nothrow__)) void *( __attribute__((__warn_unused_result__,
__leaf__, __alloc_size__(2,3))) reallocarray)(void *__ptr , size_t __nmemb , size_t __size )  __attribute__((__malloc__(__builtin_free,1))) ;
extern  __attribute__((__nothrow__)) void *( __attribute__((__warn_unused_result__,
__leaf__, __alloc_size__(2,3))) reallocarray)(void *__ptr , size_t __nmemb , size_t __size )  __attribute__((__malloc__(__builtin_free,1),
__malloc__(reallocarray,1))) ; /* has total 2 decls */ 
#line 3 "test.c"
void *myrealloc(void *__ptr )  __attribute__((__malloc__(__builtin_free,1))) ;
void *myrealloc(void *__ptr )  __attribute__((__malloc__(__builtin_free,1), __malloc__(myrealloc,1))) ; /* has total 3 decls */ 
#line 7
void *myrealloc(void *__ptr )  __attribute__((__malloc__(__builtin_free,1))) ;
void *myrealloc(void *__ptr )  __attribute__((__malloc__(__builtin_free,1), __malloc__(myrealloc,1))) ; /* attrs: extra prototype dump */
#line 7 "test.c"
void *myrealloc(void *__ptr ) /* comes from pVDecl with beginsFunDef; vinline is really false and the varinfo, magic 62015169846816, also has 3 entries in vvardecls */ 
{ 


  {
#line 7
  return ((void *)0);
}
}
``