Jose E. Marchesi writes: >> 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? Apologies for that. Was unaware of the requirement. >> >> 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 tried, but due to GCC front-end specifics it is not possible without overly change how GCC front-end works. It is not only the constant folding of the enums as Jose suggests, but also the cast of 0 gets optimized away by the parser itself. Leaving the builtins expansion without a clue of the precise type used in a field expression, as an example. >> 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. The symbols with the __COUNTER__ are consumed by the builtins expansion and will never reach the output. >> >> 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 >>>
