From: antispam@fricas.org   
      
   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.   
      
   AFAIK gcc warning machinery depends on information gathered during   
   optimization.  In this case reasonable guess is that optimizer   
   deleted offending access before warning machinery could see it.   
   I do not know how hard is to fix this.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)