https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
frankhb1989 at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |frankhb1989 at gmail dot com --- Comment #13 from frankhb1989 at gmail dot com --- It should be noted that current implementation is conflict with assertions in some cases, as in https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VA2QCXJGXVLH43327TRR5UM2BP52DWIC/. The purpose of such an attribute is not emphasized in the documentation, which leads to the confusion. I'm actually not against the semantics it implies, but I find the warning actually reduce its availability for other reasons. Note `assert` is required to be supported by the standard, so it will work across different implementations, including those do not support `__attribute__` at all. To get the code portable, the attributes will always be wrapped in macros whose names are not reserved identifiers. It should be natural that by conditionally defining such macros as nothing, each configuration of every implementation would be happy eventually, because modifying assertions everywhere in current code (instead modifying the macros) is obviously infeasible in general. A question is, when to disable the attribute? For debug build configurations (with `NDEBUG` undefined), it has almost no side effect by conditional definition based on some conditions (like `NDEBUG`), except one: the conditions may have to be duplicated in #ifdef/#if in different places of the code. It is still not a big trouble for `assert` normally, but it can be a disaster for custom assertion macros when the conditions are complicated enough. And though rarely, it can be a nightmare after the condition macros are defined (after necessary #undef) more than once, by different authors of the code. For release configurations (such as builds with properly defined `NDEBUG`), the problem is more serious. Since the attribute is designed as a hint of optimization, it should not be defined as nothing besides debugging. But to modify all occurrence of assertions is still even more absurd, whether they will generate code or not. So there is a dilemma: which one to keep, the assertions or the attribute? Removing the assertions is infeasible; unconditionally disabling the attribute is illogical (and totally nonsense for old versions of GCC which I need to adapt to). And clearly, I don't want to maintain multiple copies of the code just for different build configurations; I definitely need both of them in such cases. Thus either choice is essentially bad. The final workaround (*not the fix*) is to disable the warning itself, which is configuration-neutral and it should does work at least as old versions of GCC. However, old compiler drivers do not recognize such options. To maintain the divergence in build scripts is dirty. So it should better be... pragmas? The last problem: #pragma or _Pragma to disable such diagnostics does not work. Is it a bug, or unsupported at all?