Hello, For the upcoming Cauldron, I've registered a BoF on treatment of undefined behavior in GCC. To "promote" the BoF, collect some input prior to the event, and indirectly indicate my interests, I am offering the following light-hearted questionnaire.
I would ask to mail responses directly to my address, not the list. If you prefer Google Forms, please fill https://goo.gl/forms/1sLhMtLLhorvzDm42 Development policies touched upon in items 2-6 is what I'd invite to discuss on the BoF. Thank you. Alexander You are wearing: [*] Distribution maintainer's hat [*] GCC developer's hat [*] GCC user's hat # Undefined behavior and compiler diagnostics 1. Some undefined behavior is relevant only at translation time, not execution time (for example: an unmatched ' or " character is encountered on a logical source line during tokenization). GCC typically issues a diagnostic when encountering such UB. Should GCC rather make use of the undefinedness in order to make the compiler simpler and faster? [*] Yes [*] No Details: _ 2. In some instances GCC is able to produce a warning for code that is certain to invoke undefined behavior at run time. Should GCC strive to diagnose that as much as practical, even at the cost of the compiler getting more complex? [*] Yes [*] No Details: _ 3. Sometimes GCC is also able to issue a warning for code that is likely (but not certain) to invoke undefined behavior. As such warnings may have false positives, should GCC nevertheless try to issue them too, where practical? [*] Yes [*] No Details: _ 4. When GCC assumes absence of undefined behavior in optimization, it leads to "surprising" transformations. This is generally not reportable to the user; however, -Waggressive-loop-optimization was added for one such case. If you are familiar with that flag, would you say overall it was worth it, and more warnings in that spirit would be nice to have? [*] Yes [*] No Details: _ # Undefined behavior and compiler optimizations 5. When GCC optimizations encounter code that is certain to invoke undefined behavior, they do not react consistently: at the moment we have a wide range of behaviors, like not transforming the code at all, or replacing it with a trap instruction. Should GCC apply one tactic consistently, and if so, which? [*] Yes [*] No Details: _ 6. Some GCC optimization/analysis functionality assumes absence of UB, and cannot detect that code invokes undefined behavior. Should GCC prefer to assume presence of UB in analysis, which would allow to diagnose it or transform to runtime trap? [*] Yes [*] No Details: _
