я именно это и доказывал, кажется у нас недопонимание вышло)

А, извиняюсь :)

строго говоря, dcl.array#9 ничего не определяет, так как не содержит нормативный текст, но очень удобный в данном споре, да

Ну, он и не нужен. В этом же параграфе стандарта содержатся все необходимые нормативные пункты

Проблема в том, что в текущей трактовке стандарта нет никакого обхода правил, определенных стандартом потому что стандарт не определяет никаких правил (или никто не смог убедительно доказать обратное)

Формально, выкинуть неиспользованные строки массива так же легально, как и выкинуть неиспользованную стековую переменную

ну да, не определяет, а разъясняет)

Вообще-то, не все так просто. Стековая переменная и часть массива разные вещи. Массив это объект. Такой же как, например, структура - развивая эту логику компилятор может выкидывать неиспользуемые поля структур, но тогда будет меняться результат sizeof для структуры, а это как минимум странно.

https://godbolt.org/z/r894Ex
вот например, он вообще всё выкинул, но вот sizeof всё-равно правильный.
если что-то невозможно распознать при помощи валидной программы, то компилятор в полном праве это поменять

Я не могу утверждать наверняка, но могу предположить, что компилятор не может выкидывать неиспользованные поля структуры только потому что не способен статически доказать их неиспользуемость

Но что, если эта структура имеет internal linkage?

или ещё на этапе LTO можно так же соптимизировать

Да, именно. Так же как с массивом. Единственное, что о нем компилятор знает наверняка это директива - выдели память от сих до сих.

Да, и он статически может доказать, что эта память не используется, поскольку на неё не берется даже указатель

В том то и дело, что не совсем.
Он ещё знает, что это массив объектов определённого типа.
Просто линейной памяти "от сих до сих" вообще может и не существовать, особенно в constexpr контексте

Вся - да, может. Но не часть. Потому что, как минимум существует переменная которой сопоставлен кусок памяти под массивом. Единственное что точно можно сделать, это доказать, что она вся не используется - остальное нарушение требования целостности памяти массива.

Дело в том, что согласно expr.add#4.2, имея только int* вы не можете без UB покинуть первую строку массива и перейти ко второй. И, пользуясь этим знанием, компилятор может доказать статически, что никакая арифметика над этим указателем не приводит к тому, что мы можем достигнуть элементп arr[1][0]

Соответственно, массивы arr[1], arr[2] и дальше могут справедливо считаться неиспользуемыми, ведь сам arr тоже локальный и никуда не передаётся, компилятор видит весь его лайфтайм, он может выкинуть части массива так же, как части структуры в примере выше

Но не будет. Уже под совершенно другой причине – на это слишком многие закладываются

Это где об этом написано?

там написано
When several “array of” specifications are adjacent, a multidimensional array type is created;
но нигде не написано, что такое multidimensional array, только в примере, что это массив массивов

В общем, я вижу ровно два случая (с нашим двухмерным массивом) либо декей до указателя, либо срез сокращением размерности. В первом случае компилятор не может делать никаких предположений о том что происходит - во втором, может смело выкинуть часть массива, но в коде ни что не пострадает, потому что в первом случае стандарт говорит a) существует кусок памяти, соответствующий всему массиву и б) существует указатель на первый элемент массива. Архитектура гарантирует,  что указатель может пройти по всей физически доступной памяти (и тут канонический отстрел ноги из C, но это другая история), во втором - стандарт говорит, что мы получим массив с размером равным втрой размерности и это его границы, выходить за них уже UB.

Многомерный массив занимает линейную память. Получая указатель на эту линейную память обращение к любому элементу не содержит UB в пределах N×M, включая элемент следующий за последним

этого тоже не написано