gcc-12.2

Kiváncsi vagyok, milyen változást látok. Az utóbbi ilyen a 11.x volt, akkor gdb-t és valgrind-et kellett frissíteni a bináris fájlformátum változása miatt. (És gprof-ot.)

Hozzászólások

Szerintem semmi izgalmasat nem fogsz rajta látni. Új verzió, lehet támogat egy-két megújult nyelvi szabványból feature-öket (pl. C++20, Fortran 2018, stb.), amiket eleve a kutya nem használ (lusták megtanulni, meg nem akarnak gcc-ből túl új verziós függőséget, mert akkor kevés helyen fordul le). Illetve ha valami új prociarchitektúrára akarsz keményen optimalizálni, pl. Zen4, Intel 12-13. gen, stb.. Ha ezek nálad nem játszanak, akkor sok hasznod nem lesz az új verzióból. Én már használom Archon a 12.2-t egy ideje, nincs vele semmi baj, de semmi extrát sem látok benne, nem gyorsabb, nem jobb, ugyanúgy működik, mint a 10-11-es verzió. Az is igaz, hogy nem vagyok programozó, csak nagyon kicsi, primitív kódokat forgatok vele, nem gdb-zek, meg mások projektjeit forgatom inkább, ha forráskódból kell feltenni (ezek tipikusan AUR-ból jönnek, vagy klónozott git-tárolóból). Tartaléknak fent van a 14.0.6-os LLVM és Clang, nagy fejlődést abban sem érzékelek. Igaz ritkán is használom, csak arra tartom, hogy ha valami hirtelen nagyon kéne, és gcc alatt nem fordulna, akkor legyen még rá valami eszköz, amivel célt lehet érni. Pedig van egyébként LLVM terén is újdonság, de az spéci esetekben jön ki, pl. GPU-kra akarsz shaderkódot fordítani, ilyesmi.

Plusz azt is figyelembe kell venni, ahogy telik az idő, meg fejlődik a gcc, úgy eleve nem is tudnak már nagyon látványosat dobni. Már így is rommá van optimalizálva, a nyelvek se változnak már hozzá gyökeresen, túl nagy világmegváltást ezen a szinten már nem lehet bemutatni.

Ennek ellenére frissíts rá, ha tudsz, már csak annak a kedvéért is, hogy ne ragadj le régi verziókon, és aktuális eszközökkel dolgozz, amik nincsenek elavulva, de túl nagy katarzisra ne számítsál. Nem fogja 50%-kal jobban dúsítani a pilláidat.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ja, hogy milyen újdonságokra várok? Már annyira megöregedtem, hogy az esetleges új featúrák teljesen hidegen hagynak, helyette főleg az alábbi kettő érdekel: mi lett inkompatibilis (pl. gdb, gprof, valgrind), illetve vannak-e új compiler-warningok. Az utóbbiak a legjobb haverjaim, rengeteg (potenciális vagy valós) problémát fogtak már nekem.
 

Ja, akkor én értettem félre. A valgrindot nem ismerem, de ha most 11-essel mennek a dolgok, szerintem 12.2-essel sem fog túl sok minden eltörni. Ez inkább akkor áll fent, ha több főverziót ugorsz át.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Lefordult, kezdetnek fogott egy ilyet (még nem néztem, de talán egy strftime kellene ide):

oksafile.c:597:35: error: '%02d' directive writing between 2 and 11 bytes into a region of size between 1 and 17 [-Werror=format-overflow=]
  597 |         sprintf (tmstmp, "%04d%02d%02d%02d%02d%02d%08ld",
      |                                   ^~~~
oksafile.c:597:9: note: 'sprintf' output between 23 and 87 bytes into a destination of size 23
  597 |         sprintf (tmstmp, "%04d%02d%02d%02d%02d%02d%08ld",
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  598 |                  tm.tm_year+1900, tm.tm_mon+1, tm.tm_mday,
      |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  599 |                  tm.tm_hour,      tm.tm_min,   tm.tm_sec,
      |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  600 |                  (long)tv.tv_usec);
      |                  ~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Meg volt 'pointer usage after free/realloc' is. Igaz, hogy csak debugkiíráshoz használtam a régi értéket, de azt ő ott nem tudhatta (nem printf volt, hanem saját fv), tehát jogos volt a figyelmeztetés. Ilyesmi lett:

uintptr_t old= (uintptr_t)ptr;
free(ptr); vagy ptr2= realloc(ptr, newsize);
dosomething((void *)old);

Na ez most egy PHP-plugin, bizonyára igaza van, de egyelőre nem értem.

GlobusPni.c: In function ‘zif_glb_set’:
GlobusPni.c:173:32: error:
    the comparison will always evaluate as ‘false’
    for the address of ‘val’ will never be NULL
    [-Werror=address]
  173 |             Z_STRVAL_P (optval)==NULL ||
      |                                ^~

Kezdetnek pár egyszerű define:


#define Z_STRVAL(zval) ZSTR_VAL(Z_STR(zval))
#define Z_STRVAL_P(zval_p) Z_STRVAL(*(zval_p))
#define ZSTR_VAL(zstr) (zstr)->val

Eredménye:

     ((*(optval)).value.str)->val==((void *)0)

Szerk: meglett a definíció, így már értem, hogy ez nem lesz NULL, ha maga az optval nem null:

struct _zend_string {
 zend_refcounted_h gc;
 zend_ulong h;
 size_t len;
 char val[1];
};

Esetleg egy Z_STR_P(optval)==NULL lenne megpróbálható.


#define Z_STR(zval) (zval).value.str
#define Z_STR_P(zval_p) Z_STR(*(zval_p))

Most gcc-13.1 van előttem, fogott egy ilyet: lokális változó címét globális struktúrába tesszük:

proba_csenmain.c:366:16: error: storing the address of local variable 'auth' in 'var.auth' [-Werror=dangling-pointer=]
  366 |     var.auth   = &auth;
      |     ~~~~~~~~~~~^~~~~~~

Érdekes, hogy nem minden kontextusban panaszkodik, mindenestre megnyugszik, ha a függvény végére teszem ezt:

var.auth= NULL;

A -fanalyzer opcióval pedig fogott hiányzó va_end-et.