Hi, David,
Thank you for the info.
Yes, this does sound like a general issue in this area.
Is there any mechanism in GCC currently that records such original source code
information for IRs
after the compiler transformation?
If not, shall we add such information in the IR for this purpose? Is doing this
very expensive?
> On Jun 30, 2025, at 12:23, David Malcolm <dmalc...@redhat.com> wrote:
>
> On Mon, 2025-06-30 at 16:47 +0000, Qing Zhao wrote:
>
> [...snip...]
>
>> The output with -fdiagnostics-show-context=1 is:
>>
>> /home/opc/Work/GCC/latest-gcc-
>> write/gcc/testsuite/gcc.dg/pr109071_7.c: In function ‘foo’:
>> /home/opc/Work/GCC/latest-gcc-
>> write/gcc/testsuite/gcc.dg/pr109071_7.c:12:6: warning: array
>> subscript -1 is below array bounds of ‘int[10]’ [-Warray-bounds=]
>> 12 | a[i] = -1; /* { dg-warning "is below array bounds of" }
>> */
>> | ~^~~
>> ‘foo’: events 1-2
>> 11 | if (i == -1)
>> | ^
>> | |
>> | (1) when the condition is evaluated to true
>
> Looks great, but one caution: presumably "true" in this context refers
> to the state of the IR when the warning is emitted, rather than what
> the user wrote. I've run into this in the analyzer;
> see PR analyzer/100116 (which I don't have a good solution for, alas).
>
> Is there a way to get at the original sense of the condition, in terms
> of what the user wrote? I'm guessing that this has been canonicalized
> away long before the middle-end warnings see this.
As long as such information is lost during transformation, there is no way to
get
the original source code, I guess.
Not sure whether the LOCATION_T can include such information?
>
> Or perhaps the message for (1) could say exactly what condition it
> considers to be true e.g.
> (1) when the condition "i == -1" is evaluated to true
> or somesuch, which might give the user a better clue if the sense of
> the conditional has been reversed during canonicalization/optimization.
This looks like a reasonable workaround based on the current IR.
>
> Caveat: I didn't reread the latest version of your patch, but am just
> assuming it's looking at the cfg edge flags when the warning is
> emitted; sorry if I'm making a false assumption here.
Yes, that’s right. You made good assumptions here -:).
thanks.
Qing
>
>>
> Dave
>
