> On Thu, Feb 8, 2024 at 5:07 AM Cupertino Miranda > <cupertino.miranda@xxxxxxxxxx> wrote: >> >> >> Hi everyone, >> >> This is a patch to make CORE builtin macros work with builtin >> implementation within GCC. >> >> Looking forward to your comments. >> > > Can you please repost it as a proper patch email, not as an attachment? > > But generally speaking, is there any way to change/fix GCC to allow a > much more straightforward way to capture type, similar to how Clang > does it? I'm not a big fan of extern declarations and using per-file > __COUNTER__. Externs are globally visible and we can potentially run > into name conflicts because __COUNTER__ is not globally unique. > > And just in general, it seems like this shouldn't require such > acrobatics. > > Jose, do you have any thoughts on this? Yes the macro is ugly and more elaborated than the clang version, but I am afraid it is necessary in order to overcome the fact GCC constant-folds enumerated values at parse-time. Note however that the expression-statement itself to which the macro expands is not elaborated, much like the null pointer dereference in the clang version doesn't get elaborated. These are just conveyed to the builtins an the builtins use the TREE (IR in case of clang I guess) to extract the type from it. As far as I understand it the extern declaration in the macro is not declaring an object with extern visibility, so it should not result in any symbol being defined nor have any impact outside of the compilation unit. The __COUNTER__ is there just so you can use the macro more than once in the same compilation unit, but that's all. Cuper will correct me if I am wrong. > >> Regards, >> Cupertino >>
