General protection fault при вызове emerge

memtest86 после шестичасового прогона никаких ошибок

это ни о чём не говорит, мемтест - говно

это ни о чём не говорит, мемтест - говно

С древним memtest86+ не путаешь? Есть еще проприентарный (freeware) в виде EFI приложения.

очевидно не путаю, ведь у тебя софт падает

Оно, кстати, не всегда падает. Просто трейс выкидывает в консоль. И до пересборки свежим GCC такого не было.

Может быть gcc неподдерживаемые инструкции генерит - aes, avx. Какой проц, «-march» какой?

Оно, кстати, не всегда падает

а ты думал всё будет просто

И до пересборки свежим GCC такого не было

совпадение

тогда бы была другая ошибка. кроме того у него хрюзен

Обращение к невыровненным данным в avx.

Какой проц, «-march» какой?

Ryzen 7 2700, -march=znver1.

совпадение

Несколько месяцев подряд такое совпадение было?

да

Повод сделать полную переборку! emerge -e world

И снова нечаянно скастовали world :)

… приведёт к падению на любом имеющемся проце. что ты хотел этим сказать?

Сбросил настройки в UEFI, ничего не изменилось.

значит теперь пробуй бинарный дистрибутив

что ты хотел этим сказать?

Что gpf можно вызвать неправильной иструкцией.

Хотя тут, скорее, проблема в смене (версии) тулчейна.

это уже не «неподдеживаемая инструкция», а баг компилятора

а баг компилятора

Или проца, или обоих, или еще микрокода, зашитого в биос или загружаемого.

gcc-10.1 в тестовой «~amd64».

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

максимум локальная поломка в генте

Сделай полное обновление тулчейна, строго в такой же последовательности

# emerge -1 sys-devel/binutils
# emerge -1 sys-libs/glibc
# emerge -1 dev-libs/gmp dev-libs/mpc dev-libs/isl dev-libs/mpfr 
# emerge -1 sys-devel/gcc

Потом можешь еще сделать констрольный выстрел emerge @system

а в арче он уже месяц

В арче пакеты собраны с -march=znver1?

юзеры сами компиляют код, у многих из них zen

юзеры сами компиляют код, у многих из них zen

Прям все пакеты компиляют: и системные, и несистемные? Или только то, что только один раз в жизни запускают?

а зачем все, если у ТС валятся уже gcc/педон/binutis /glibc

gcc/педон/binutis /glibc

И что из этого арчебальды компиляют с -march=znver1?

всё, ведь это одни из самых распространённых пакетов. кроме того свежий gcc есть не только в арче

Показывай свои самодельные пакеты для сборки этих пакетов с -march=znver1.

какие ещё самодельные пакеты, если они есть в репах, а CFLAGS настраиваются в /etc/makepkg.conf?

И арчибальды компиляют то, что есть в виде готовых бинарей?

иногда нужно наложить патчи, например сейчас в binutils поломана сборка wine

иногда нужно

Ты уж определись: «все, всё и всегда» или «иногда, когда нужно один раз в жизни»

ты предполагаешь, что исключительно gcc/python/binutils/glibc сломаны, когда весь остальной софт работает? маловероятно

Ах да. Покажи /etc/makepkg.conf . Посмотрим все вместе какого размера у тебя march

значит теперь пробуй бинарный дистрибутив

Загрузил убунту с флешки, позапускал разные питоновские скрипты. Все ок.

а ты полную нагрузку на проц дай

Так уже. Вчера скачал интеловский линпак, погонял минут десять - все ок. Видимо, с оптимизацией под Zen в новом GCC что-то накосячили.

Пересобрал с -march=native, теперь все ок.

Сравниваю ключи для -march=native и вычисленного -march следющим скриптом

#!/bin/bash

gcc_help_target() {
	gcc -march=${1} -Q --help=target
}

parse_arch() {
	while read -r l; do
		[[ "$l" =~ ^-march= ]] && echo ${l#-march=} && return 0
	done < <(gcc_help_target native)
	return 1
}

diff_opts() {
	while true; do
		read -r l1 <&3 || break
		read -r l2 <&4 || break
		[[ "$l1" != "$l2" ]] && printf '%s\n%s\n\n' "$l1" "$l2"
	done 3< <(gcc_help_target $1) 4< <(gcc_help_target $2)
}

arch=$(parse_arch)
printf '*** -march=%s ***\n' $arch
diff_opts $arch native