This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
One potential problem I can see is that the expansion of the new macro is not a void expression as (if I am not mistaken) mandated by the standard (§ 7.2.1.1 N1570) meaning that (admittedly questionable) code like the following won't compile. int n = (assert(1), 42); Would the new macro still be able to give the desired hint to the compiler if the logic were moved into an inline function and have the macro expand to a simple call to that function? Or, since this is only relevant for GCC anyway, maybe a statement expression could be used? https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html But I'm not sure what potential problems this might cause with regards to C++ object lifetime if the _Condition is of a user-defined type. On 9/17/18 10:38 PM, François Dumont wrote: > We talk about it a while back. > > I've run testsuite several times since I have this patch on my local > copy. Note that when I implemented it the wrong way tests started to > fail so it is clearly having an effect on the generated code. > > * include/bits/c++config [__OPTIMIZE__](__glibcxx_assert): Define as > optimization hint > > using __builtin_unreachable. > > Ok to commit ? > > François >
Attachment:
signature.asc
Description: OpenPGP digital signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |