• GCC säger nej till betydande kod som skapats av AI

    Utvecklare får använda AI för att diskutera idéer, förstå källkod och göra efterforskningar. Men kod som helt eller delvis bygger på material från språkmodeller som ChatGPT, Gemini eller GitHub Copilot ska normalt inte tas emot som bidrag till GNU Compiler Collection.

    GCC Steering Committee, den grupp som leder utvecklingen av GNU Compiler Collection, har antagit en ny policy för användningen av artificiell intelligens och stora språkmodeller.

    GNU Compiler Collection, vanligtvis förkortat GCC, är en samling kompilatorer för bland annat programmeringsspråken C, C++, Fortran och Ada. Programvaran är en central del av många Linuxsystem och används för att omvandla programmerares källkod till körbara program.

    Den nya policyn innebär att GCC tills vidare kommer att avvisa bidrag som innehåller upphovsrättsligt betydande material som har skapats av en språkmodell.

    Det räcker inte att redigera AI-koden

    Reglerna omfattar inte bara kod som kopierats direkt från exempelvis ChatGPT eller GitHub Copilot. Även kod som senare har skrivits om, rättats eller förbättrats av en människa kan omfattas.

    Det avgörande är om den färdiga koden fortfarande bygger på material som ursprungligen skapades av en språkmodell.

    En utvecklare kan alltså inte låta en AI skapa en större funktion, städa upp koden manuellt och därefter behandla resultatet som ett helt självständigt arbete.

    När ett kodbidrag väl har sitt ursprung i AI-genererat material fortsätter det, enligt policyn, att räknas som härlett från detta material.

    AI får fortfarande användas som hjälpmedel

    Policyn innebär inte ett fullständigt förbud mot AI-verktyg.

    Utvecklare får fortfarande använda språkmodeller för att:

    • diskutera programmeringsidéer,
    • förstå befintlig källkod,
    • lära sig mer om ett obekant teknikområde,
    • undersöka möjliga lösningar,
    • genomföra allmän efterforskning.

    Begränsningen gäller när upphovsrättsligt betydande material från språkmodellen faktiskt hamnar i den kod som skickas in till GCC-projektet.

    En utvecklare kan exempelvis fråga en språkmodell hur en viss kompilatorteknik fungerar. Därefter kan utvecklaren själv konstruera och skriva en egen lösning. Det skiljer sig från att låta språkmodellen skapa själva implementationen och sedan använda den som grund för bidraget.

    Vad betyder upphovsrättsligt betydande?

    All kod är inte automatiskt tillräckligt originell eller omfattande för att skyddas av upphovsrätten.

    En mycket enkel ändring, som att rätta ett stavfel, byta ett variabelnamn eller justera en uppenbar felskrivning, kan vara juridiskt obetydlig. Mer omfattande funktioner, algoritmer och implementationer kan däremot betraktas som upphovsrättsligt betydande.

    Policyn innehåller därför vissa begränsade undantag.

    GCC:s ansvariga utvecklare kan acceptera triviala eller juridiskt obetydliga ändringar som har skapats med hjälp av en språkmodell. Ändringen måste fortfarande uppfylla projektets vanliga kvalitetskrav, och användningen av AI ska redovisas tydligt.

    Särskilda regler för testprogram

    AI-genererade testfall kan också behandlas annorlunda än kod som blir en permanent del av GCC.

    Ett testfall består ofta av ett mycket litet program som används för att återskapa ett fel eller kontrollera att kompilatorn beter sig på rätt sätt. Sådan kod är normalt inte en del av kompilatorns egen implementation.

    Därför kan även upphovsrättsligt betydande AI-genererade testfall i vissa situationer accepteras.

    Upphovsrätten är den stora frågan

    Bakgrunden till försiktigheten är osäkerheten kring hur språkmodeller har tränats och vilka rättigheter som gäller för materialet de producerar.

    En språkmodell kan ha tränats på stora mängder offentligt tillgänglig källkod. Det är inte alltid möjligt att avgöra om ett kodförslag är en helt ny konstruktion eller om det ligger nära kod som redan har skrivits av någon annan.

    För ett stort projekt som GCC kan detta skapa både juridiska och praktiska problem. Projektet måste kunna veta att den kod som tas emot får distribueras under GCC:s licens och att bidragsgivaren har rätt att lämna över den.

    En försiktighetsprincip för fri programvara

    Den nya policyn visar att AI kan användas som ett verktyg under utvecklingsarbetet, men att ansvaret fortfarande ligger hos människan.

    För GCC räcker det inte att en utvecklare förstår, granskar eller förbättrar den kod som en språkmodell har skapat. Om ett betydande kodbidrag bygger på AI-genererat material kan det fortfarande avvisas.

    Budskapet till utvecklare är därför tydligt: använd gärna AI för att lära, resonera och undersöka – men skriv den kod som ska skickas in till GCC själv.

    > FAKTA: GCC OCH AI-GENERERAD KOD

    GCC är en samling kompilatorer för bland annat C, C++, Fortran och Ada. GCC används i många Linuxdistributioner och andra fria operativsystem.

    GCC-projektets nya policy innebär att upphovsrättsligt betydande kod som har skapats av en språkmodell normalt inte accepteras som bidrag.

    Policyn gäller även kod som först har skapats av exempelvis ChatGPT, Gemini eller GitHub Copilot och därefter har skrivits om eller förbättrats av en människa.

    AI får fortfarande användas för att diskutera idéer, förstå befintlig kod, göra efterforskningar och lära sig mer om ett teknikområde.

    Triviala ändringar och vissa testfall kan i särskilda fall accepteras. Användningen av AI måste då redovisas tydligt.

  • GCC 16.1 är här – och C++ tar ett stort kliv in i 2020-talet

    GCC 16.1 är här och markerar början på en ny fas för GNU Compiler Collection. Med C++20 som nytt standardläge, experimentellt stöd för kommande C++26-funktioner och förbättringar för både diagnostik, optimering och modern hårdvara är detta en release som kan få stor betydelse för utvecklare. Samtidigt kan äldre kodbaser behöva ses över när kompilatorn tar ett tydligt steg bort från C++17-eran.

    Den fria kompilatorsamlingen GCC har fått en ny storversion. Med GCC 16.1 startar den nya GCC 16-serien, och även om en kompilatorrelease kanske inte låter som något som får pulsen att rusa hos alla, är detta en version som många utvecklare kommer att märka av.

    Den största nyheten är att GCC nu byter standardläge för C++: från GNU C++17 till GNU C++20.

    Det betyder att den som kompilerar C++-kod utan att själv ange språkversion nu automatiskt får C++20 som utgångspunkt. För moderna projekt är det goda nyheter. För äldre kodbaser kan det däremot innebära att vissa saker behöver justeras.

    C++20 blir det nya normala

    C++20 var ett stort steg för programmeringsspråket C++. Det introducerade bland annat nya sätt att skriva generisk kod, förbättrade standardbibliotek och funktioner som gör språket mer uttrycksfullt. Att GCC nu gör GNU C++20 till standard är därför en tydlig signal: C++20 är inte längre något framtidsläge, utan något utvecklare bör räkna med i vardagen.

    För de flesta projekt innebär det inte nödvändigtvis katastrof. Men kod som byggts med antagandet att kompilatorn använder C++17 kan börja bete sig annorlunda eller ge nya felmeddelanden. Lösningen är ofta enkel: ange uttryckligen vilken standard projektet ska byggas med, till exempel med flaggan -std=gnu++17, eller uppdatera koden så att den fungerar bra med C++20.

    GCC-utvecklarna meddelar också att stödet för C++20:s standardbibliotek nu räknas som stabilt. Däremot är C++20-moduler fortfarande experimentella och kräver särskild aktivering med -fmodules.

    En försmak av C++26

    GCC 16.1 blickar också framåt. Versionen innehåller experimentellt stöd för flera funktioner som är på väg in i C++26, alltså en kommande version av C++-standarden.

    Bland nyheterna finns stöd för reflection, där program kan undersöka delar av sin egen struktur, contracts, som kan användas för att uttrycka krav och garantier i kod, constexpr exceptions, vilket stärker möjligheterna att göra beräkningar vid kompilering, samt nya bibliotekstyper som std::simd, std::inplace_vector, std::copyable_function och std::function_ref.

    Det här är inte funktioner man bör kasta in i produktionskritisk kod hur som helst. De är fortfarande experimentella. Men för språkintresserade utvecklare och verktygsmakare är GCC 16.1 ett viktigt steg mot nästa generation C++.

    Algol 68 gör oväntad entré

    En av de mer oväntade nyheterna är att GCC nu får en experimentell frontend för Algol 68, kallad ga68.

    Algol 68 är ett klassiskt programmeringsspråk från datorhistoriens mer akademiska hörn. Det hade stort inflytande på senare språk, även om det aldrig blev lika vardagligt använt som C, Pascal eller Fortran. Att GCC nu får stöd för Algol 68 är därför både tekniskt intressant och lite nostalgiskt.

    Frontend:en bygger på språket så som det beskrivs i den reviderade rapporten, inklusive godkända rättelser, och innehåller dessutom vissa GNU-utökningar samt en POSIX-prelude.

    Bättre felmeddelanden och modernare analys

    Kompilatorer handlar inte bara om att omvandla kod till körbara program. De är också ett av utvecklarens viktigaste verktyg för att förstå vad som gått fel.

    I GCC 16.1 har diagnostiken förbättrats. GCC kan nu generera fel- och varningsmeddelanden i ett experimentellt HTML-format, vilket kan göra rapporter mer lättlästa i webbläsare eller utvecklingsverktyg.

    Samtidigt förbättras SARIF-stödet med ny information om kontrollflöde. SARIF är ett format som används för maskinläsbara analysrapporter, till exempel i säkerhetsverktyg och CI-system.

    Det äldre JSON-formatet för diagnostik har tagits bort. Användare som behöver maskinläsbara felrapporter hänvisas i stället till SARIF.

    Mer stöd för moderna språkfunktioner

    På C-sidan utökas stödet för C23 och typen _BitInt till fler processorarkitekturer, bland annat RISC-V, Arm, S/390 och LoongArch. Det gör det enklare att skriva kod som arbetar med heltal av mer exakt definierade bitstorlekar.

    C-frontend:en får också stöd för så kallad counted-by-attribution för pekarfält, vilket kan hjälpa kompilatorn och analysverktyg att förstå hur stora vissa datastrukturer är.

    Fortran-användare får dessutom förbättringar i coarray-stödet. På system med en enda nod finns nu stöd för delat minne med flera trådar, vilket kan förbättra parallella Fortran-program.

    Snabbare kod genom bättre optimeringar

    Som vanligt i en ny GCC-version finns även en rad optimeringsförbättringar. GCC 16.1 har bland annat bättre vektorisering, alltså förmågan att omvandla kod så att processorn kan utföra flera operationer parallellt.

    Kompilatorn kan nu också vektorisera vissa loopar där antalet varv inte är känt i förväg, och hanteringen av reduktioner och tidiga loopavbrott har förbättrats.

    Även Link-Time Optimization, LTO, har fått förbättringar. LTO gör det möjligt för kompilatorn att optimera över flera källfiler när programmet länkas ihop. I GCC 16.1 hanteras top-level assembly bättre med hjälp av flaggan -flto-toplevel-asm-heuristics.

    Dessutom har spekulativ devirtualisering byggts ut, vilket kan hjälpa kompilatorn att optimera indirekta funktionsanrop när den kan göra kvalificerade gissningar om vilken funktion som faktiskt kommer att köras.

    Nya processorer och mer hårdvarustöd

    GCC 16.1 uppdaterar också stödet för ny hårdvara.

    På x86-sidan tillkommer stöd för AMD Zen 6 med -march=znver6, Intel Wildcat Lake med -march=wildcatlake och Intel Nova Lake med -march=novalake.

    För AMD GPU-offloading finns nu experimentellt stöd för MI300, och även LoongArch och IBM Z får ytterligare förbättringar.

    För vanliga användare märks detta kanske inte direkt. Men för den som bygger program för nya servrar, superdatorer eller specialiserad hårdvara kan kompilatorstöd vara avgörande för att få ut maximal prestanda.

    En version som kan kräva städning

    Som med många stora kompilatoruppdateringar finns en hake: kod som fungerade i tidigare GCC-versioner kan behöva ändras.

    Det beror både på den nya C++20-standarden som standardläge och på att kompilatorn blivit bättre på att upptäcka problem. I praktiken kan detta leda till fler varningar eller kompileringsfel i projekt som tidigare byggde utan problem.

    För utvecklare är rådet enkelt: testa tidigt, ange språkstandard tydligt i byggsystemet och läs igenom varningarna. Många av dem kan peka på verkliga problem som tidigare bara råkade passera obemärkt.

    Sammanfattning

    GCC 16.1 är mer än bara ännu en versionssiffra. Det är en tydlig markering om vart C++-världen är på väg. Med C++20 som nytt standardläge, experimentellt stöd för C++26, förbättrad diagnostik, bättre optimeringar och stöd för ny hårdvara är detta en viktig release för både systemutvecklare och språkentusiaster.

    För den som arbetar med äldre C++-kod gäller det att vara uppmärksam. För den som vill använda modernare språkfunktioner är GCC 16.1 däremot ett välkommet steg framåt.

    ”`html

    Faktaruta: GCC 16.1

    > Release: GCC 16.1 är den första stabila versionen i GCC 16-serien.

    > Största nyheten: C++ använder nu GNU C++20 som standard i stället för GNU C++17.

    > För utvecklare: Äldre projekt kan behöva ange språkstandard med exempelvis -std=gnu++17.

    > Framtidsstöd: Experimentellt stöd finns för flera C++26-funktioner.

    > Övrigt: GCC 16.1 innehåller även bättre diagnostik, optimeringar och stöd för ny hårdvara.

    ”`

Etikett: GNU Compiler Collection

  • GCC säger nej till betydande kod som skapats av AI

    Utvecklare får använda AI för att diskutera idéer, förstå källkod och göra efterforskningar. Men kod som helt eller delvis bygger på material från språkmodeller som ChatGPT, Gemini eller GitHub Copilot ska normalt inte tas emot som bidrag till GNU Compiler Collection. GCC Steering Committee, den grupp som leder utvecklingen av GNU Compiler Collection, har antagit…

  • GCC 16.1 är här – och C++ tar ett stort kliv in i 2020-talet

    GCC 16.1 är här och markerar början på en ny fas för GNU Compiler Collection. Med C++20 som nytt standardläge, experimentellt stöd för kommande C++26-funktioner och förbättringar för både diagnostik, optimering och modern hårdvara är detta en release som kan få stor betydelse för utvecklare. Samtidigt kan äldre kodbaser behöva ses över när kompilatorn tar…