Здравствуйте. Работаю в SDK от Xilinx, это допиленный Eclipse, компилятор GCC.
У меня 32-битную переменную не получается заполнить двоичными единичками. Код такой:

даёт ноль. Если сдвиг на 31, то единички есть, но 31 штука. Пробовал без преобразования типов - тоже ноль. Короче никак не могу его заставить.
Я понимаю, что можно просто записать 0xFFFFFFFF, но вопрос принципиальный, как заставить?

Вот и запишите "по-простому" 0xFFFFFFFF . А если хотите через ухо (unsigned long long), то ставьте его перед единичкой, которую сдвигаете влево, т.к. после сдвига это делать поздно - старший знак уже пропал.

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

Да, всё сработало, большое спасибо. Понимание-то я проявляю, тут скорее забывание про эту одну единственную единичку. Видите: я остальные операнды расширил, даже правую единичку, а эту забыл ))
Через ухо там несильно сложно, по-настоящему можно написать u64, и поймёт. А unsigned long long это я записал для каноничности, чтобы не было подозрений, что где-то u64 объявлен криво.

Скажите, понимает ли ваш компилятор определения числовых констант с суффиксом:
1i64
или
1LL
А то Microsoft пишет в документе "C++ Integer Constants", что такие суффиксы в Visual Studio 2013 допустимы. Как в этом отношении ведет себя GCC?

А то бы очень классно выглядело выражение типа
(1i64 << 32)
без явного переопределения типа.

Спасибо и за эти подсказки.
1i64 - не понимает такой синтаксис.
1LL - работает правильно.

тоже идея ))

А можно узнать подробней о версии gcc?

Вот результат выражения из первого поста http://ideone.com/tM7rbC
Ну и вот без лишнего приведения типов http://ideone.com/xqRct2

Кстати, да. Ведь вполне ожидаемо, что "(unsigned)-1" даст 0xFFFFFFFF.

Хм... действительно, если разобраться, странно... Даже если у меня 32-битная единичка, я её сдвинул за пределы разрядной сетки, получил ноль. Потом единичку отнимаю от нуля. Получаю 0xFFFFFFFF. Косяк ещё и в том, что обычно компилятор давал ворнинг, что сдвигание привело к выходу за пределы разрядной сетки. А в этом случае не поругался.

есть мысль: может просто сдвиг циклический? Тогда всё сходится. Единичка сдвинутая на 32 разряда попадает на своё прежнее место, отнимаем единичку получаем ноль. Пока проверить не могу, позже.

Если это так, то компилятор глючный донельзя :-)
Этого просто не может быть.

Такое бывает, к сожалению

А у ксайлинкса есть какие-то продукты без такого свойства? )))
Там же написано NO WARRANTY )))

Да, догадка подтвердилась. Код

даёт троечку )))

Фигасе. Это точно gcc? Запускается на ПК? А исходники у него есть?

Ну вот посмотрите в сообщении #10 информацию о версии. Работает на железе. Встраиваемый софтовый проц на ПЛИС. Исходников наверное нет... Т.к. он допилен компанией Xilinx под свои продукты.

А, ну если на железе, тогда другое дело. В конце концов, даже в софтовом проце можно инструкции сдвига поменять или просто перепутать, а в исходниках компилятора напортачить ещё проще :-)

Как раз нет. Все в пределах стандарта:


"Незнание закона не освобождает от ответственности".

Стандарт на неопределённость поведения )))

Тады ой.

А я в последнее время для FFFFFFFF пишу = 0-1, это короче, и никто варнингов почему-то не выдаёт.
Но ~0 ещё короче. Или я что-то не так понял в условиях ?

На некоторых архитектурах, на которых int 16-битный, выражение uint32_t min_per = 0 - 1; (хотя 0 здесь лишний, просто -1 дает тот же результат) присвоит min_per значение 0x0000FFFF. Наверное самым коротким и правильным была бы запись uint32_t min_per = -(uint32_t)1;