From: already5chosen@yahoo.com
On Tue, 13 Jan 2026 23:31:26 -0000 (UTC)
Kaz Kylheku <046-301-5902@kylheku.com> wrote:
> On 2026-01-10, Michael S wrote:
> > On Fri, 9 Jan 2026 20:14:04 -0000 (UTC)
> > Kaz Kylheku <046-301-5902@kylheku.com> wrote:
> >
> >> On 2026-01-09, Michael S wrote:
> >> > On Fri, 09 Jan 2026 01:42:53 -0800
> >> > Tim Rentsch wrote:
> >> >
> >> >>
> >> >> The important thing to realize is that the fundamental issue
> >> >> here is not a technical question but a social question. In
> >> >> effect what you are asking is "why doesn't gcc (or clang, or
> >> >> whatever) do what I want or expect?". The answer is different
> >> >> people want or expect different things. For some people the
> >> >> behavior described is egregiously wrong and must be corrected
> >> >> immediately. For other people the compiler is acting just as
> >> >> they think it should, nothing to see here, just fix the code
> >> >> and move on to the next bug. Different people have different
> >> >> priorities.
> >> >
> >> > I have hard time imagining sort of people that would have
> >> > objections in case compiler generates the same code as today, but
> >> > issues diagnostic.
> >>
> >> If false positives occur for the diagnostic frequently, there
> >> will be legitimate complaint.
> >>
> >> If there is only a simple switch for it, it will get turned off
> >> and then it no longer serves its purpose of catching errors.
> >>
> >> There are all kinds of optimizations compilers commonly do that
> >> could also be erroneous situations. For instance, eliminating dead
> >> code.
> >
> >
> >
> > I am not talking about some general abstraction, but about specific
> > case.
> > You example is irrelevant.
> > -Warray-bounds exists for a long time.
> > -Warray-bounds=1 is a part of -Wall set.
>
> In your particular example, it is crystal clear that the "return 0"
> statement is elided away due to being considered unreachable, and the
> only reason for that can be undefined behavior, and the only undefined
> behavior is accessing the array out of bounds.
>
> The compiler has decided to use the undefined behavior of the OOB
> array access as an unreachable() assertion, and at the same time
> neglected to issue the -Warray-bounds diagnostic which is expected to
> be issued for OOB access situations that the compiler can identify.
>
> No one can claim that the OOB situation in the code has escaped
> identification, because a code-eliminating optimization was predicated
> on it.
>
> It looks as if the logic for identifying OOB accesses for diagnosis is
> out of sync with the logic for identifying OOB accesses as assertions
> of undefined behavior.
>
> In some situations, a surprising optimization occurs not because of
> undefined behavior, but because the compiler is assuming well-defined
> behavior (absence of UB).
>
> That's not the case here; it is relying on the presence of UB.
>
> Or rather, it is relyiing on the absence of UB in an assinine way:
> it is assuming that the program does not reach the out-of-bounds
> access, because the sought-after value is found in the array.
>
> But that reasoning requires awareness of the existence of the
> out-of-bounds access.
>
> That's the crux of the issue there.
>
> There is an unreachable() assertion in modern C. And it works by
> invoking undefined behavior; it means "let's have undefined behavior
> in this spot of the code". And then, since the compiler assumes
> behavior is well-defined, assumes that that statement is not reached,
> nor anything after it, and can eliminate it.
>
> The problem is that an OOB array access should not be treated
> as the same thing, as if it were unreachable(). Or, rather, no,
> sure it's okay to treat an OOB arrary access as unreachable() --- IF
> you generate the diagonstic about OOB array access that you
> were asked to generate!!!
>
Would you be so kind to submit a bug report to gcc bugzilla?
In theory, I can do it myself, but I have a tendency to be lazy.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
