Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01015.html
It feels to me like it's getting a little late for this but it
would still be helpful to get some feedback. Jeff, you were
very interested in this work when we discussed it offline. Do
you have any comments?
On 10/24/19 8:42 AM,
Other than the comments from Joseph any feedback on the patch
itself and my questions?
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01015.html
On 10/14/2019 02:41 PM, Martin Sebor wrote:
Attached is a more fleshed out version of the built-in implemented
to run in a pass of its own. I
On Tue, 15 Oct 2019, Richard Sandiford wrote:
> > No. I'd expect the code generating the IR from GCC diagnostics should
> > arrange for the message to be translated first (while in the case of
> > __builtin_warning in user code, it would not be translated), and the code
> > subsequently using
Joseph Myers writes:
> On Mon, 14 Oct 2019, Martin Sebor wrote:
>
>> On 10/14/19 4:03 PM, Joseph Myers wrote:
>> > How does this interact with translation?
>> >
>> > My expectation would be that in user code, the message is taken literally
>> > as-is; it is not looked up in the GCC message
On Mon, 14 Oct 2019, Martin Sebor wrote:
> On 10/14/19 4:03 PM, Joseph Myers wrote:
> > How does this interact with translation?
> >
> > My expectation would be that in user code, the message is taken literally
> > as-is; it is not looked up in the GCC message catalog even if it is
> > identical
On 10/14/19 4:03 PM, Joseph Myers wrote:
How does this interact with translation?
My expectation would be that in user code, the message is taken literally
as-is; it is not looked up in the GCC message catalog even if it is
identical to some GCC diagnostic. However, when used internally for
How does this interact with translation?
My expectation would be that in user code, the message is taken literally
as-is; it is not looked up in the GCC message catalog even if it is
identical to some GCC diagnostic. However, when used internally for GCC
diagnostics, they should be
Attached is a more fleshed out version of the built-in implemented
to run in a pass of its own. I did this in anticipation of looking
at the CFG to help eliminate false positives due to ASAN
instrumentation (e.g., PR 91707).
The built-in now handles a decent number of C and GCC formatting
