Насчет любой переменной вы погорячились - значения static переменных сохраняются даже после выхода из функции и будут иметь его при повторном входе в эту функцию.

Не совсем понятно из какого топика вырвана эта цитата, но вы исказили ее смысл, попустив слово "запись". По смыслу у Сергея Борща "выкинуть" не саму переменную, а выкинуть обращение к ней.

Отсюда. Модераторы мудро решили ее закрыть.

Я не пропустил слово "запись"

И обращение к ней (запись в нее) он не может выкинуть, так как должен знать, что результат может понадобиться при следующем обращении к ней. Если она static.

static относится к storage-class specifier, т.е. влияет лишь на размещение и область видимости объекта, но не влияет на оптимизацию обращения к данному объекту. Для предотвращения оптимизации обращения к объекту применяется квалификатор volatile, который наряду с const и restrict относится к квалификаторам типа (type qualifiers). См. стандарт C99 (ISO/IEC 9899:1999).

Ключевой момент - "Если результат такой записи не используется". Т.е. если вы не читате из такой переменной, а только пишете, то такая запись - бесполезная трата тактов процессора. Я не уверен, является ли присвоение адреса переменной указателю сигналом о том, что результат записи где-то потребуется и не смог найти упоминания об этом в стандарте.
В вашем случае я могу предположить еще один сценарий, который также сделает вашу программу неработоспособной - компилятор имеет право сделать запись в вашу переменную непосредственно перед выходом из функции. А вы пытаетесь использовать содержимое этой переменной в прерывании до выхода из функции.

В целом я согласен с Сергей Борщ. Особенно зная его квалификацию. На практике, тем не менее, по крайней мере IAR AVR не выбрасывает массивы в которые идёт запись, но нет чтения. Я использовал такие массивы для отладки.Например, когда мне хотелось просмотреть результаты обработки аналоговых значений в окне watch. Интересно также что массив не выкидывается также и в случае если обращение осуществляется путём работы с указателем.

Думаю, что причина следующая. Массив размещается в принудительном порядке за счёт static, как писал rezident. А обращение к нему не выбрасывается так как на этапе линковки может быть прилинкован модуль ассемблерный или из другого языка, короче тот, где оптимизация затруднена.


PS: Тем не менее не вижу смысла в "хитрых" приёмах, если всё это можно сделать в рамках стандарта. Зачем передавать ссылку на массив размещённый на стэке? Это же ни в какие ворота! Вы этот массив даже в отладчике не увидите сразу после завершения его использования. А ваш указатель формально будет указывать на несуществующие данные. Это для примера.
Надо применять такие приёмы, которые обеспечивают железобетонный результат. А не "от компиляции к компиляции".
Чисто моё мнение конечно.

это смотря как накрутить ему уровень оптимизации. в режиме отладки обычно оптимизацию вообще отключают, тогда все переменные считаются как volatile.

Ну раз пошла такая пьянка (с привлечением стандартов) то читаем:

Таким образом, выкинуть компилятор ее не может при всем желании, так как Its lifetime is the entire execution of the program


А что по-вашему означает "использование" переменной? Как раз присвоение ее значения другой или передача как параметра в функцию. И выкидывать запись в нее компилятор тоже не может, так как это значение может понадобиться функции при последующих входах, она ведь полагается на то, что оно сохранится поскольку Its lifetime is the entire execution of the program.


Оптимизация здесь совершенно ни при чем. Поведение static переменных регламентируются стандартом.


Оптимизацию отключают только... альтернативно одаренные люди. Мне кажется что сама возможность ее отключения оставлена для того, чтобы пользователь мог отключив ее убедиться что виноват не оптимизатор, а его программа.

ЗЫ. Тут недавно проскакивал пост в котором один такой юзер удивлялся почему AVR-ка не выполняет запись в EEPROM хотя у него все написано правильно:
EECR |= _BV(EEMPE);
EECR |= _BV(EEPE);
правда у него зачем-то оптимизация была отключена в результате для этого кода генерировался десяток команд, а EEMPE действительно лишь на протяжении четырех клоков...



Понравилос
По таким постам легко отличать верующих от атеистов. Для верующих сила авторитета сильнее стандарта Си.

Проверте сами, может ли компилятор выкинуть static перемную.



Скомпилируйте код. Я бы на месте оптимизатора ее выкинул. Или по крайней мере запись в нее.

Анатолий.

Даже в этой абсолютно бессмысленной программе он ее не выкидывает:

И даже выполняет в нее запись. Оптимизация -Os

Как хорошо, что вы не на месте компилятора!

ну и еще один пример тогда, конечно с -Os:



Анатолий.

"Не болтайте ерундой!" Не может и не должен компилятор выкидывать эту переменную. Она же static, хоть и объявлена внутри функции. Под нее обязательно выделяется ОЗУ и она очищается при стартапе, но область видимости этой переменной - только внутри данной функции. Присвоение значения тоже не выкидывается, т.к. по сути это инициализация ее.
А вот в следующем случае компилятор наверняка оставит только последнее действие.

И вот в таком случае цикл с проверкой на условие скорее всего заменится на бесконечный цикл. Особенно, если foo1 и foo2 будут в разных единицах (файлах) компиляции.

добавьте ключик "-ffunction-sections -fdata-sections -Wl,--gc-sections" и от вашей статической переменной абсолютно ничего не останется.

Ну так вот стандрат С говорит, что компилятор в процессе оптимизации обязан обеспечить observable behaviour такое же, как у абстрактной машины языка. Да, время жизни static-переменной по стандарту совпадает с временем жизни программы. Но и время жизни static-функции совпадает с ним же. А компилятор успешно выбрасывает, если она в пределах этого же файла не вызывается сама и её адрес никуда не передаётся. А всё почему - на всё то же o.b. не виляет - выбрасываем.

Так что наличие обсуждаемой static-переменной в функции foo() с observable behaviour никак не связано, поэтому компилятор имеет право её выбросить. Всё зависит от уровня оптимизации, на который способен компилятор и от указаний ему по этому поводу.

avr-gcc -Os -ffunction-sections -fdata-sections -Wl,--gc-sections -mmcu=atmega8 static.c
avr-objdump -d a.out >static.dump


Или так
avr-gcc -Os -fwhole-program -S -mmcu=atmega8 static.c


А то, что не выкинул при компиляции одной только функции foo() - ну так есть ещё над чем работать. Поскольку переменная не volatile, внутри функци не считывается и её адрес никуда не передаётся — она может быть выброшена. Не в этой версии компилятора, так в следующей.

С массивами, в которые из основного кода ведётся только запись, а из прерывания — только чтение, тоже не всё так просто. Если массив не volatile, то компилятор имеет право переставить запись в него и взведение volatile-флага, информирующего прерывание о том, что запись произведена. В результате прерывание может начать читать буфер до того, как в него реально произведена запись.

Да и хрен на нее, хоть и static. На то и оптимизатор. Пользы от переменной никакой, накой ее держать?

Не его (компилятора) собачье дело! Пускай warning выдаст, а я уж сам решу нужна мне там переменная или не нужна. Насчет выбрасывания неиспользуемых функций - согласен, а вот насчет выбрасывания переменных типа static ...ммм... можно привести реальные примеры такого поведения с указанием конкретных компиляторов и параметров оптимизации?

На любом ненулевом уровне оптимизации gcc выкидывает foo

По закону имеет право выкидывать... В смысле, по стандарту.
Какой компилятор реализует такую оптимизацию? Возможно, и никакой, так как это может требовать специальных усилий разработчиков компилятора без существенного выигрыша. Искать нужно среди компиляторов, занимающихся глобальной оптимизацией программы в целом. Они могут легко вычислить, что переменная не используется, и выкинуть её в ходе обычной оптимизации потоков данных. Поэтому крутые компиляторы для однокристаллок с их небольшими программами и широкими возможностями для глобальной оптимизации наиболее вероятные кандидаты. Вот только С с его адресной арифметикой существенно тормозит подобные оптимизации.



Скорее всего выкидывает линкер, как объект, на который нет ни одной ссылки из программы.

Хм. IAR тоже выбрасывает.
А вот так уже нет. Но warning формирует в обоих случаях.


Нет, именно компилятор. Эта строка с объявлением переменной уже в asm-файле просто закоментарена компилятором.

Не зряж в IAR введен Extended keyword __root с помощю его никто никогда никого не выкинет.

Вера здесь не при чём. Просто я, в отличее от Сергея, работаю только в компиляторе IAR. В связи с этим не берусь обобщать. Кроме того, Сергей не раз достаточно аргументировано отвечал приводя выдержки из стандарта.

Все остальные аргументы здесь уже привели. Они совпадают с моим подходом.

Так, к примеру, я отлаживаю сразу на максимальной оптимизации. 2 причины. 1 - чтобы по 2 раза не отлаживать. 2 - сама отладка - это не пошаговое хождение, а точечная остановка в нужном месте.

Вопрос: Какое значение получает обработчик прерывания через указарель 'p_a', если код скомпилирован с -Os? Кто считает что 2?




Правильный ответ: при первом вызове foo () 1, при последующих 3.

Анатолий.

Чтобы прерывания правильно обрабатывали глобальные переменные, меняющиеся вне прерывания, эти переменные должны быть волатильными. Есть такое правило.
Формально, p_a является волатильной и даже указывает (должна) на волатильную переменную, но в реале указывает на неволатильную. При присваивании p_a = &a должен был появиться варнинг. А в остальном, компилятор работая с "а" всё делает верно. Если бы между cli/sti был вызов функции, то перед вызовом в "а" была бы записана двойка.

Это я и пытаюсь показать на примере 777777



Никаких варингов нет.



Да, с небольшим уточнением, если эта дополнительная функция проинлайнилась в foo () и указатель p_a в ней не используеться, то записи двойки в 'a' не будет.

Анатолий.

Разумеется, потому что с точки зрения компилятора у тебя идут две подряд строки
a = 2;
a = 3;
Результат выполнения этой программы - занесения 3 в переменную a. Но это последнее присваивание компилятор не имеет права выбрасывать потому что a - static! И этот результат может понадобиться при последующих вызовах этой функции.

В моем случае последовательность была такая:

Здесь компилятор не имеет права выбрасывать ничего, даже если бы pTWI было не volatile потому что:
а) адрес cmd присваивается глобальной переменной, сделовательно cmd используется и он должен быть инициализирован;
б) pTWI - глобальная переменная, следовательно она может использоваться в других функциях, а значит по выходу из функции в ней должен быть адрес cmd;
в) более того, следом вызывается некая глобальная функция, поэтому компилятор обязан предположить, что pTWI может использоваться в этой функции, следовательно адрес cmd должен быть присвое ей до вызова SendSLA
После того как я сделал массив static ограничений стало еще больше.

Обалденное определение, мне нравится. А что значит "правильно обрабатывали"? А как можно обрабатывать неправильно?
Вообще-то у него есть строго определенное значение: оно заставляет компилятор предполагать, что значение этой переменной может меняться само по себе, помимо хода выполнения программы:

Таким образом, volatile должны быть объявлены только те переменные, которые с точки зрения компилятора не меняются исходя из транслироемого кода.



Вообще говоря да, компилятор обязан предположить, что 'a' может потребоваться в той функции, но в данном случае она static и поэтому из той функции недоступна.

Вот мы все на языке лирики, а меж тем - чистая теория графов удалил вершину - и нет проблемы переменной

Вы не правы. Привязались к статику уак банный лист:-)
Он не для этого задуман. И все ваши домыслы можно поставить с ног на голову путём изменения опций компилятора и линкера.
Остыньте и сделайте два-три глубоких вдоха. В этом споре вы уже проиграли. Сэ ля ви

PS
aesok, с возвращением!

А для чего же он создан? Приведите раздел стандарта который это объясняет. В крайнем случае, приведите пример программы с набором опций компилятора и линкера. Вы ничего этого не сделали, но почему-то объявляете, что я проиграл.

Статик создан именно для того, чтобы его значение, установленное в функции, сохранялось при выходе из нее и было таким же при повторном входе в эту функцию. Компилятор имеет большую свободу действий, но такое поведение переменной он обязан обеспечивать. Если у вас есть другие мнения на этот счет - объясните, желательно с убедительной аргументацией.

Это такая же голимая интерпретация как и я писал об volatille
Я хотя бы для себя ввёл то правило, являющееся следствием оптимизации компиляторов. То есть "моё" правило, напрямую не касалось определения volatille, а просто юзало его.

Статик просто размещает переменную в каком-то там сегменте (bss или др.). И всё. Остальное на совести компилятора.

Что именно "всё остальное"? Стандарт четко определяет время жизни (lifetime) переменной. Что по-вашему означает этот термин?

Когда компилятор выкидывает какие-либо присвоения, то он это делает в том случае, когда видит, что они не потребуются до конца жизни переменной. Если же ее время жизни - до конца программы, то как он может их выкинуть? Он обязан полагаться на то, что где-то в программе она потребуется. Или вы считаете, что он может проанализировать программу и выяснить, что функция больше вызываться не будет и отменить присваивание? Это даже программист не может сделать, для этого он и выполняет отладку.

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

Я уже потерял суть спора. Чё не нравится? В смысле, что компилятор (и какой?) сделал не так, как хотелось?


В сегменте bss эта переменная будет жить вечно. Довольны?
Вопрос только в том, выкинет ли компилятор какое-нибудь присваивание в эту переменную.

Это уж как вы ему (компилятору) укажете. Выбрасывать-не выбрасывать, предупреждать-не отвлекать на всякую ботву и тд.
По крайней мере GCC так работает.
ключ -fdata-sections позволяет выкидывать неиспользуемые секции данных.

Для себя я уже давно всё сделал, а Вам народ неоднократно писал про это:

С такими опциями со статической переменной может быть вообще всё что угодно
(всё будет сильно зависеть от контекста Вашей программы).

Ну что ж, попробуем тупо воткнуть их в проект

Получаем на выходе:

Если между присваиваниями воткнуть обращение к какой-нибудь функции (даже к ней самой), то он и первое присваивание не выкинет:


Ну, если например в ней не будет обращений к foo, то он ее выкинет, это отследить не сложно. Но если обращение есть, то никакой самодеятельности не будет. (Если только там нет ключей, заставляющих его нарушать стандарт, но я сомневаюсь и наличии таковых)

Оригинально. Вообще ключевое слово 'static' определяет область видимости переменной, а в контексте функции к этому добавляется требование ее размещения в области данных, а не стека. Вот и все. Больше компилятор ничего не ограничивает, и если он достаточно умный, то найдя только присваивания данной переменной без передачи (или возврата) ее адреса в другие функции имеет полное право оптимизировать использование этой переменной, вплоть до полного исключения ее из результата компиляции.

...переменной <==> функции...

Ключевое слово - lifetime. У static переменной оно бесконечное. Поэтому наличие только присваивания не может служить основанием для того чтобы заявлять о ее неиспользовании. Она может понадобиться при следующем вызове функции.

И вообще, если компилятор выкидывает какую-то переменную или часть кода, то это означает что и без оптимизаций эта переменная/код не будет использована. Поэтому не стоит так бояться "самодеятельности" компилятора, если таковая обнаружится, не спешите выключать оптимизацию, лучше повнимательнее посмотрите исходник.



С самого начала речь шла о static переменных в контексте функций.

Современные методы анализа потока данных и кода позволяют выяснить, что в конструкциях типа приведенной ниже, ни при первом, ни при последующем вызовах необходимости в выделении места под переменную нет.


В случае с исходником из поста 35, компилятор все делает правильно, т.к. имеется использование адреса переменной вне функции.

Отсутствие её чтения - может. Этот факт анализируют (почти) все современные компиляторы. Могут выдавать ремарку или варнинг. Особенно на "статик" (не глобальную/межмодульную). Шипко умные могут даже выкинуть её, если она не волатильная.


Следите за ходом мысли.
Если foo() сделать статиком, то она рискует быть удалённой, если внутри модуля она на вызывается и адрес её не используется. Даже на 99% она будет удалена современными компиляторами.
То же самое относится и к статик переменным. Если внутри функции (аналог модуля для статик функции) переменная не читается, то не важно есть ли в неё запись, она может быть удалена. Если её адрес используется/записывается в другую переменную, то идёт рекурсия по анализу использования этой второй переменной. Если она не читается, а только прописывается, то сперва удаляется эта вторая переменная, а потом удаляется первая переменная, которая "статик". Всё по-чесноку.

Как уже говорили, при использовании ключей combine и fwhole-program, все функции становятся static.
И в этом случае у компилятора руки развязываются полностью.
А со всеми ключикамии для линкера возможно получить кумулятивный эффект, под кодовым названием "без говNа":)
И тут единственное, что может сохранить обращения к переменной это volatile и ничто более.
Повтарюсь, не стоит сюда притягивать за уши static.