GCC 16 जारी हुआ

 (gcc.gnu.org)
1 पॉइंट द्वारा GN⁺ 2026-05-01 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • GNU Compiler Collection की नई रिलीज़ एक महत्वपूर्ण मोड़ है, क्योंकि C++ का default standard अब gnu++20 कर दिया गया है और C++20 implementation को अब experimental नहीं माना जाता
  • C++26 reflection·contracts·constexpr फीचर, C++23 फीचर, और experimental C++23·C++26 library support जोड़े गए हैं, जबकि template errors और type trait constraint failure diagnostics अब hierarchical messages के साथ अधिक विस्तार से मिलती हैं
  • OpenMP और OpenACC में GPU memory allocation, target memset, और device memcpy API का विस्तार किया गया है, और Ada·Fortran·Modula-2·Algol 68 front end में भी नई language features और experimental compiler जोड़े गए हैं
  • x86-64 अब AMD Zen6, Intel Wildcat Lake, और Intel Nova Lake को support करता है, और AMD GPU·LoongArch·IBM z Systems·Solaris·Windows के लिए भी target-specific features और ABI changes जोड़े गए हैं
  • JSON diagnostic format हटाया गया है, SARIF·HTML diagnostics को मजबूत किया गया है, static analyzer में सुधार हुआ है, और libgdiagnostics में 37 entrypoint जोड़कर tool integration और diagnostic infrastructure को काफी बढ़ाया गया है

compatibility बदलाव और common improvements

  • Solaris पर int8_t आदि अब C99 standard compliance के लिए signed char हो गए हैं, और यह एक incompatible change है
  • Solaris पर -pthread option अब _REENTRANT को predefine नहीं करता
  • -fdiagnostics-format= का json format हटा दिया गया है, और machine-readable diagnostics के लिए SARIF का उपयोग करना होगा
  • Link-Time Optimization अब -flto-toplevel-asm-heuristics के साथ top-level asm statements को बेहतर तरीके से handle करता है
  • speculative devirtualization अब सामान्य indirect function calls को handle करता है और एक से अधिक target speculation को support करता है
  • vectorizer अब reduction की loop-internal parallelism को अधिक लचीले ढंग से पहचानता है, और unknown iteration count वाली loops तथा uncounted loop vectorization को support करता है
    • इसके अलावा masking का उपयोग करने वाले vector length agnostic loops के लिए alignment peeling, mutual peeling for alignment, और early break loops में vector induction calculation हटाने का support भी शामिल है
  • GCC Command Options और option index को पहले छूट गए कई options शामिल करने के लिए संशोधित किया गया है
  • GCC-specific attributes documentation को आधुनिक बनाया गया है ताकि GCC द्वारा supported सभी C/C++ dialects में स्वीकार्य standard attribute syntax पर अधिक ज़ोर दिया जा सके
    • attribute सामग्री को दोहराव कम करने के लिए पुनर्गठित किया गया है, और नया attribute index जोड़ा गया है
    • parameter और option spec file documentation को GCC developers और custom GCC configuration की ज़रूरत वाले users के लिए GCC internals manual में स्थानांतरित किया गया है

भाषा-वार प्रमुख बदलाव

  • OpenMP और OpenACC

    • OpenMP memory allocation support को मजबूत किया गया है, जिससे pinned trait allocator और ompx_gnu_pinned_mem_alloc उपलब्ध होने पर CUDA API का उपयोग करते हैं, और Nvidia GPU पर संबंधित memory access performance बेहतर होती है
    • GNU extension ompx_gnu_managed_mem_alloc allocator और ompx_gnu_managed_mem_space host पर device-accessible memory allocate करते हैं
      • unified-shared memory समर्थित न होने पर भी device access संभव है, और जिन systems में सभी host memory device-accessible है, वहाँ भी इसका page-migration behavior दूसरी memory से अलग हो सकता है
    • OpenMP 5.0 ने C/C++ में सीमित declare mapper support जोड़ा है, और uses_allocators clause में OpenMP 5.2 के syntax changes के साथ OpenMP 6.0 का semicolon support भी शामिल है
    • OpenMP 5.1 ने C/C++ में map clause और target update construct के iterator modifier के लिए प्रारंभिक support जोड़ा है
    • OpenMP 5.2 C/C++ में begin declare variant directive को support करता है
    • OpenMP 6.0 ने omp_target_memset और omp_target_memset_async API routine जोड़े हैं, और no_openmp_constructs assumptions clause भी उपयोग किया जा सकता है
    • OpenMP 5.0, 5.1 और 5.2 में deprecated किए गए directive और clause डिफ़ॉल्ट रूप से deprecation warning देते हैं, जिन्हें -Wno-deprecated-openmp से बंद किया जा सकता है
      • deprecated named constant या API routine के उपयोग पर भी warning आती है, जिसे -Wno-deprecated-declarations से बंद किया जा सकता है
    • OpenACC ने C/C++/Fortran के लिए acc_memcpy_device और acc_memcpy_device_async API routine जोड़े हैं
    • OpenACC 3.0 का wait directive if clause स्वीकार करता है, और OpenACC 3.3 के Fortran API routine acc_attach और acc_detach, OpenACC 2.6 के C/C++ counterpart को पूरक बनाते हैं
    • OpenACC 3.4 में Fortran data clause के named constant PARAMETER का उपयोग specification और GCC दोनों में स्वीकार्य है, लेकिन GCC में इसका compile-time और runtime behavior पर कोई प्रभाव नहीं पड़ता

  • Ada, Fortran, Modula-2, Algol 68

    • Ada GNAT extension में Constructor और Destructor जोड़े गए हैं, जो standard Ada से काफ़ी अलग construction/finalization mechanism प्रदान करते हैं
    • Ada में Implicit with, Structural Generic instantiation और Extended_Access aspect जोड़े गए हैं
      • Extended_Access को unconstrained array subtype की ओर इशारा करने वाली general access type declaration पर निर्दिष्ट किया जा सकता है, यह pointer representation बदलता है और Ada द्वारा allocate न की गई memory को foreign language के साथ जोड़ना आसान बनाता है
    • Ada में -gnatd_V या verbose mode के -gnatd_W के जरिए compiler debugging के लिए VAST का उपयोग किया जा सकता है, और Ada 2022 Reduction Expressions semantic analysis, Ada.Containers.Bounded_Indefinite_Holders, accessibility rule implementation और Android support में सुधार हुआ है
    • Fortran coarray और Fortran 2018 TEAM feature को संभालता है, जो single node machine पर native shared memory multithreading का उपयोग करते हैं
    • Fortran 2003 Parameterized Derived Types support में सुधार हुआ है, और LEN parameter handling काम करती है, लेकिन PR82649 के अनुसार भविष्य में representation change की आवश्यकता होगी
    • Fortran 2018 IMPORT statement extension, REDUCE intrinsic और नए GENERIC statement को support करता है
    • Fortran 2023 sinpi जैसे trigonometric function additions, split intrinsic subroutine, और optional lower bound argument लेने वाले c_f_pointer को support करता है
    • -fexternal-blas64 option MATMUL में 64-bit integer argument के साथ external BLAS routine को कॉल करता है, और यह केवल 64-bit system तथा -ffrontend-optimize लागू होने पर ही मान्य है
    • Modula-2 import list, module name और nested scope symbol processing के दौरान spelling hint देता है, और नई wide set implementation तथा M2WIDESET library module पेश करता है
      • wide set बदलाव ABI को बदलता है और पुराने GCC versions के object file के साथ link-time error पैदा कर सकता है
    • Modula-2 default library में BinDict binary dictionary module जोड़ा गया है, कई modules में Write और WriteLn procedure उपलब्ध कराए गए हैं, और -fm2-pathname-root= option से external library module access बेहतर हुआ है
    • GCC में experimental Algol 68 compiler ga68 शामिल है, जिसका लक्ष्य Revised Report और IFIP WG2.1 Algol 68 Support subcommittee द्वारा अनुमोदित errata को implement करना है
      • कुछ GNU extension और POSIX prelude भी implement किए गए हैं; भाषा संबंधी जानकारी के लिए Algol 68 website और front end जानकारी के लिए wiki देखें

C++ और libstdc++

  • C++ compilation का डिफ़ॉल्ट language version -std=gnu++17 से बदलकर -std=gnu++20 हो गया है
    • जो code पुराने C++ standard पर निर्भर है, उसे build flag में -std= जोड़ना होगा या code को porting करना होगा; विवरण के लिए porting notes देखें
    • C++20 modules सपोर्ट अभी भी experimental है और इसे -fmodules से enable करना होगा
  • C++26 features में reflection, annotations for reflection, base class subobject splicing, function parameter reflection, contracts, constexpr exceptions, constexpr virtual inheritance सहित कई चीज़ें implement की गई हैं
    • P2996R13 Reflection को -std=c++26 -freflection से enable किया जाता है
    • P2686R4 का कुछ हिस्सा partial support में है; structured binding constexpr हो सकता है, लेकिन constexpr automatic variable reference अभी अनुमति नहीं है
  • C++23 features में P2036R3, P2590R2, P2246R1 implement किए गए हैं
  • C++ error messages अब template-related समस्याओं आदि में hierarchical structure रखते हैं, और message nesting को indentation और bullet point से दिखाया जाता है
  • experimental C++20 modules support अब --compile-std-module option जोड़कर source file compile करने से पहले <bits/stdc++.h> header unit और std, std.compat module को build करता है
    • अगर <bits/stdc++.h> header unit build किया गया है, तो importable standard library header के #include को पारदर्शी रूप से <bits/stdc++.h> import में बदल दिया जाता है
    • रिपोर्ट किए गए कई bug ठीक किए गए हैं
  • standard library type trait की constraint failure diagnostics अब is_constructible_v, is_invocable_v आदि के false होने का कारण अधिक विस्तार से बताती हैं
  • libstdc++ में 128-bit integer को support करने वाले target पर std::is_integral<__int128> और समान trait अब हमेशा true होंगे
    • पहले GNU dialect में यह true था, लेकिन strict dialect में ऐसा नहीं था
  • P0952R2: A new specification for std::generate_canonical को C++11 के बाद प्रभावित सभी mode में implement किया गया है, जिससे observed output प्रभावित होता है
    • पुराना behavior _GLIBCXX_USE_OLD_GENERATE_CANONICAL define करके वापस लाया जा सकता है
  • std::variant ABI को C++20 और उससे ऊपर के mode के साथ consistent बनाने के लिए अपडेट किया गया है, और इससे कुछ C++17 mode class layout प्रभावित होते हैं
    • पुराना behavior _GLIBCXX_USE_VARIANT_CXX17_OLD_ABI define करके वापस लाया जा सकता है, और इसका प्रभाव केवल C++17 mode पर लागू होता है
  • std::regex execution को system stack की जगह heap-based stack इस्तेमाल करने के लिए फिर से लिखा गया है, ताकि बड़े string matching के दौरान stack overflow से बचा जा सके
  • C++20 implementation अब experimental नहीं है, और Windows पर std::chrono::current_zone() काम करता है
  • चूंकि GCC 16 से पहले का C++20 support experimental था, इसलिए C++20 component इस्तेमाल करने वाले program को पुराने release के साथ compatible नहीं माना जाना चाहिए
    • ABI change के दायरे में <atomic> waiting/notifying function, <semaphore> semaphore type, <syncstream> synchronization, std::format args और std::formatter representation, <compare> का std::partial_ordering, और कुछ <ranges> adaptor representation शामिल हैं
  • experimental C++23 library support में std::mdspan, ranges::starts_with, ranges::ends_with, ranges::shift_left, ranges::shift_right, std::allocator_traits::allocate_at_least शामिल हैं
  • experimental C++26 library support में std::simd, std::inplace_vector, std::optional<T&>, std::copyable_function, std::function_ref, std::indirect, std::polymorphic, shared pointer के लिए std::owner_equal, <debugging> header आदि शामिल हैं

टार्गेट और ऑपरेटिंग सिस्टम सपोर्ट

  • IA-32/x86-64

    • AMD Zen6-आधारित CPU को -march=znver6 के साथ सपोर्ट किया जाता है, और Zen5 में सक्षम ISA extension के ऊपर AVX512_BMM, AVX_NE_CONVERT, AVX_IFMA, AVX_VNNI_INT8, AVX512_FP16 को सक्षम करता है
    • अगर AVX512 सपोर्ट चालू है और znver4, znver5, znver6 tuning है, तो auto-vectorization code size घटाने और performance सुधारने के लिए masked vector epilog इस्तेमाल करने की कोशिश करता है
    • Intel Wildcat Lake को -march=wildcatlake, और Intel Nova Lake को -march=novalake के साथ सपोर्ट किया जाता है
      • -march=novalake Panther Lake-आधारित ISA extension में APX_F, AVX10.1, AVX10.2, PREFETCHI को अतिरिक्त रूप से सक्षम करता है
    • GCC 16 से कई -march= switch में AMX-TRANSPOSE, USER_MSR, CLDEMOTE, KL, WIDEKL, PREFETCHI को सक्षम करना हटा दिया गया है
    • -mavx10.1-256, -mavx10.1-512, -mevex512 हटा दिए गए हैं, और -mavx10.1 behavior change warning भी साथ में हट गई है
    • AMX-TRANSPOSE सपोर्ट GCC 16 में हटा दिया गया है, और GCC अब -mamx-transpose को स्वीकार नहीं करता
    • नया --enable-x86-64-mfentry configure option x86-64 profiling के लिए mcount की जगह __fentry__ का उपयोग करने वाले -mfentry को सक्षम करता है, और glibc target पर यह डिफ़ॉल्ट रूप से सक्षम है
    • --enable-tls=DIALECT डिफ़ॉल्ट TLS dialect को नियंत्रित करने का सपोर्ट देता है, डिफ़ॉल्ट मान gnu है, और स्वीकार्य मान gnu तथा TLS descriptor के लिए gnu2 हैं

  • AMD GPU, LoongArch, IBM z Systems

    • AMD GPU offloading में OpenMP target region और OpenACC compute region launch overhead काफ़ी कम हो गया है
    • AMD Instinct MI300 gfx942 device के लिए experimental सपोर्ट जोड़ा गया है, और generic gfx9-4-generic के साथ अधिकांशतः compatible gfx950 भी शामिल है
    • AMD GPU का डिफ़ॉल्ट multilib build set अब gfx908, gfx90a, gfx9-generic, gfx9-4-generic, gfx10-3-generic, gfx11-generic है
      • generic arch मौजूद होने पर specific device के लिए multilib अब डिफ़ॉल्ट रूप से नहीं बनाए जाते
      • generic architecture के लिए ROCm 6.4.0 या उससे ऊपर चाहिए
      • नए डिफ़ॉल्ट multilib set के लिए LLVM 20 या उससे ऊपर का assembler और linker चाहिए
      • GCC के AMD installation notes और configuration notes देखें
    • LoongArch _BitInt (N) और unsigned _BitInt (N) जैसे bit-precise integer type को सपोर्ट करता है
    • LoongArch target_clones attribute के साथ FunctionMulti-Versioning को सपोर्ट करता है, जो CPU feature के अनुसार function version बनाता है और runtime पर अपने-आप optimal version चुनता है
    • LoongArch32 architecture के लिए सपोर्ट जोड़ा गया है, जिसमें डिफ़ॉल्ट ABI ilp32d और ilp32f, ilp32s ABI शामिल हैं
      • यह standard 32-bit version LA32 और reduced 32-bit version LA32R दोनों को संभालता है, जिससे embedded application के लिए 32-bit target code generation संभव होता है
      • यह सुविधा Binutils और glibc सपोर्ट पर निर्भर है
    • S/390, System z, IBM z Systems अब bit-precise integer type और _Float16 floating-point type को सपोर्ट करते हैं
      • _Float16 operations software या float instruction के ज़रिए किए जाते हैं
    • S/390 परिवार में Linux kernel के canary address loading runtime patching को सपोर्ट करने के लिए global stack protector -mstack-protector-guard=global के रूप में जोड़ा गया है, और -mstack-protector-guard-record भी जोड़ा गया है
    • S/390 परिवार में -m31 सपोर्ट deprecated कर दिया गया है और इसे भविष्य के release में हटाया जाएगा

  • ऑपरेटिंग सिस्टम

    • Solaris -gsctf option के साथ Solaris CTF, यानी Compact C Type Format, generation को आसानी से सपोर्ट करता है
    • Windows native TLS, यानी Thread-Local Storage, को सपोर्ट करता है
      • इसे सक्षम करने के लिए configure के समय --enable-tls बताना होगा और GNU binutils 2.44 या उससे ऊपर चाहिए

डायग्नॉस्टिक्स, प्लगइन, स्टैटिक एनालिसिस

  • GCC -fdiagnostics-add-output=experimental-html के साथ HTML फ़ॉर्मैट डायग्नॉस्टिक आउटपुट को सपोर्ट करता है
  • SARIF आउटपुट dump directory का पालन करता है, और build-dir/foo.o आउटपुट उदाहरण में GCC 16, SARIF को build-dir/foo.c.sarif में लिखता है
    • GCC 15 ने उसी उदाहरण में foo.c.sarif में लिखा था
  • SARIF आउटपुट logical location nesting को कैप्चर करता है, और कई मामलों में fix object में description property शामिल करता है
  • SARIF threadFlowLocation की kinds property को non-standard control flow अभिव्यक्ति के लिए नए throw, catch, unwind, setjmp, longjmp मान मिलते हैं
  • GCC diagnostics directed graph को लिंक कर सकते हैं, और global directed graph भी report कर सकते हैं
    • text sink में graph को अनदेखा किया जाता है, लेकिन SARIF sink में कैप्चर किया जाता है, और experimental-html इसे dot का उपयोग करके SVG-आधारित रूप में render करता है
    • SARIF या HTML diagnostic sink में cfgs=yes सेट करने पर सभी optimization pass के सभी function के लिए GCC intermediate representation capture सक्षम हो जाता है
  • GCC diagnostics, XML और JSON file के अंदर logical location को refer कर सकते हैं
    • sarif-replay tool इसका उपयोग SARIF input issue report करते समय JSON pointer देने के लिए करता है
  • यदि environment में GCC_DIAGNOSTICS_LOG सेट है, तो diagnostic subsystem stderr या named file में text log आउटपुट करता है
    • इसका उपयोग इस तरह के internal decision trace करने के लिए होता है कि diagnostic कब और क्यों reject हुआ
  • यदि environment में EXPERIMENTAL_SARIF_SOCKET सेट है, तो GCC startup पर उस socket से connect करने की कोशिश करता है, और उत्पन्न होने वाले हर diagnostic के लिए JSON-RPC notification भेजता है
  • Plugin author के लिए publish/subscribe framework जोड़ा गया है, जो loosely-coupled sender और receiver के बीच strongly-typed message पहुंचाता है
    • इस release में जिन topic को plugin subscribe कर सकता है, वे सिर्फ किसी specific function के optimization pass start/stop event और static analyzer से जुड़े event हैं
  • GCC diagnostic sink में finalizer hook वाला extension object हो सकता है, और plugin इसका उपयोग SARIF output file में अतिरिक्त जानकारी कैप्चर करने के लिए कर सकता है
  • GCC 16 में diagnostic machinery को बड़े स्तर पर व्यवस्थित किया गया है, और जो plugin सिर्फ diagnostic-core.h का उपयोग करते हैं, उन पर इसका असर नहीं होना चाहिए
    • जो plugin maintainer diagnostics का अधिक जटिल उपयोग करते हैं, उन्हें porting guide देखनी चाहिए
  • Static analyzer, C++ Named Return Value Optimization और exception के शुरुआती सपोर्ट को संभालता है, इसलिए इसे सरल C++ उदाहरणों में उपयोग किया जा सकता है
    • scaling issue की वजह से इस release में इसे production C++ code पर इस्तेमाल करना मुश्किल हो सकता है
  • -fanalyzer, -fexceptions सक्षम होने पर यह मानता है कि nothrow attribute के बिना external function call exception throw कर सकता है
    • नया -fanalyzer-assume-nothrow विकल्प इस मान्यता को अक्षम करता है
    • इसका उद्देश्य उन project में warning बढ़ने से बचना है जो C++ interoperability के लिए C code में -fexceptions का उपयोग करते हैं, लेकिन जिनके द्वारा इस्तेमाल किया जा रहा C API के exception throw करने की संभावना कम है
  • -fanalyzer की user code representation data structure को समझना और debugging आसान बनाने के लिए फिर से लिखा गया है, और diagnostic location में थोड़ा सुधार हुआ है
    • इसके बदले analyzer की memory usage बढ़ती है
  • -fanalyzer की memory contents simulation data structure को फिर से implement किया गया है, जिससे यह तेज़ और maintenance के लिहाज़ से आसान हो गया है
  • analyzer ने GCC की value_range machinery का उपयोग शुरू कर दिया है, जिससे कुछ false positive हटते हैं

libgdiagnostics और ठीक की गई समस्याएँ

  • libgdiagnostics को कुल 37 entrypoint नए मिले हैं
  • logical location पर काम करने के लिए 5 entrypoint जोड़े गए हैं
  • command-line option और SARIF playback support के लिए 2 entrypoint जोड़े गए हैं
  • directed graph पर काम करने के लिए 12 entrypoint जोड़े गए हैं, जो graph बनाना, global graph पास करना, diagnostic graph कनेक्ट करना, node और edge जोड़ना/क्वेरी करना, और node label व location सेट करना support करते हैं
  • diagnostic text को buffer में तैयार करने के लिए 17 entrypoint जोड़े गए हैं
    • इनमें message buffer बनाना/हटाना, string/text/byte/printf append करना, event id append करना, URL/quote/color range को handle करना, dump करना, और buffer-आधारित diagnostic finish के साथ location label/event जोड़ना शामिल है
  • diagnostic_manager_set_debug_physical_locations() भी जोड़ा गया है
  • GCC bug tracking system में 16.1 release के लिए fixed के रूप में बताए गए problem report की सूची PR list में देखी जा सकती है
    • यह सूची पूरी न भी हो सकती है, और कुछ ठीक किए गए PR इसमें शामिल न हुए हों

संबंधित पढ़ाई

2 टिप्पणियां

 
dieafterwork 2026-05-01

आख़िरकार..
 
GN⁺ 2026-05-01
Hacker News टिप्पणियाँ

  • मैं P2590R2 Explicit lifetime management को ऐसी implementation feature के रूप में बताना चाहूँगा जिसे लोगों को अपनाना चाहिए, लेकिन शायद व्यवहार में ज़्यादा इस्तेमाल नहीं किया जाएगा
    यह std::start_lifetime_as के लिए है, और pointer को structured type में type-pun करने का यह UB नहीं होने वाला तरीका है
    external I/O buffer को handle करने वाला लगभग हर zero-copy code मोटे तौर पर reinterpret_cast(buffer.get()) जैसा दिखता है, और यह undefined behavior है, लेकिन अब अगर reinterpret_cast को start_lifetime_as से बदल दें तो यह अब बुरा काम नहीं रहेगा
    https://en.cppreference.com/cpp/memory/start_lifetime_as

    • इसे पहले से ही वैध तरीके से करने का एक तरीका था, और सबको वही इस्तेमाल करना चाहिए था। pointer को no-op memmove से laundering करने वाला तरीका
      यहाँ reinterpret_cast का इस्तेमाल bug है
      start_lifetime_as memory laundering वाले मंत्र को साफ़-सुथरा standard नाम देने के अलावा एक और काम करता है। अर्थ के स्तर पर यह memory को छूता नहीं, जबकि no-op memmove मूलतः memory को छूता है। व्यवहार में compiler memmove को no-op समझकर optimize कर सकता है, इसलिए बड़ा फ़र्क नहीं पड़ता
    • अगर alignment constraints को नज़रअंदाज़ करें, तो यह read के implementation पर निर्भर करता है। अगर compiler के नज़रिए से वह पूरी तरह opaque है, तो kernel या network card जैसी कोई चीज़ वास्तव में उस buffer के अंदर Foo construct कर रही होती है, इसलिए cast पूरी तरह उचित हो जाता है
      start_lifetime_as तब उपयोगी है जब buffer lifetime compiler के लिए पारदर्शी हो और aliasing assumptions को बिगाड़ सकता हो
    • cppreference की व्याख्या थोड़ी संदिग्ध लगती है
      ऐसा लगता है कि T एक बिल्कुल नया complete object है और उसके अंदर subobject हैं, जिनमें से एक का type U है। U को bit_cast की तरह initialize किया जाता है, शायद मतलब यह था कि उस address पर पहले से मौजूद bits से cast किया जाता है। लेकिन obj बिना definition के अचानक आ जाता है, इसलिए शायद इसका मतलब सही address पर मौजूद किसी चीज़ से है
      लेकिन E क्या है यह अस्पष्ट है। पेज पर लिखा है “E is the lvalue of type U denoting obj”, जबकि obj शायद char जैसे type का होगा, और अगर वह पहले से U type का होता तो bit_cast की ज़रूरत ही नहीं होती
    • char buffer के साथ type punning की अनुमति है
    • वह code सिर्फ़ बुरा नहीं है, alignment issue की वजह से सही भी नहीं है

  • अभी खोजने से पहले तक मुझे पता नहीं था कि GCC release schedule इतना नियमित है: https://gcc.gnu.org/develop.html

    • बड़े projects बहुत पहले से regular releases की ओर जा चुके हैं
      90 के दशक तक यह सोचा जाता था कि waterfall शैली में एक बड़ी release बनाई जा सकती है जिसमें मनचाहे सारे features हों, लेकिन project बड़ा होने पर हमेशा कोई न कोई ऐसा व्यक्ति होता है जो अभी तैयार न हुए feature पर काम कर रहा होता है। regular release करने पर फिर भी customers को release दी जा सकती है
      यह तरीका readiness को लेकर अनिश्चित developers को unstable features बंद करने के लिए toggle बनाने पर मजबूर करता है, और व्यवहारिक रूप से वही सबसे बेहतर के क़रीब है
    • हाल की GCC major releases काफ़ी नियमित रही हैं, Fedora की spring release जैसी, और किसी बड़े rhythm में फिट होती दिखती हैं। संकेत है Red Hat
    • Cygnus के लोगों ने project को फिर से व्यवस्थित करने के बाद से ऐसा है। अब यह RedHat→IBM तक पहुँचा है
    • मेरी याद के मुताबिक यह तब से है जब GCC पर GPL3 लागू हुआ
      पहले यह ज़्यादा धीमा था, और मैंने GCC 2.95 के C++ bugs को workaround करने में बहुत ज़्यादा समय बिताया था
      यह कि मुझे वह problematic version आज भी याद है, अपने आप में बहुत कुछ कहता है

  • मैं इसे पहले से कुछ समय से इस्तेमाल कर रहा हूँ। Debian sid में trunk package है
    इसमें c++26 reflection है, इसलिए मैं reflection से कुछ जादुई काम कर रहा हूँ, और ser-des जैसे कुछ मामलों में यह काफ़ी बेहतर है
    काश ecosystem में बस एक LSP server भी होता

    • Debian 12 और 13 पर GCC 16 binaries चलाते समय libstd समस्या पैदा कर रहा है

  • -fdiagnostics-format= का तथाकथित json format इस release में हटा दिया गया है, और कहा गया है कि अगर GCC से machine-readable diagnostics चाहिए तो SARIF इस्तेमाल करें
    लेकिन यह भी कहा गया है कि -fdiagnostics-add-output=experimental-html से diagnostics को HTML output किया जा सकता है
    JSON output हटाकर HTML output जोड़ने के फ़ैसले के पीछे की वजह जानने की उत्सुकता है

    • SARIF एक औपचारिक schema वाला JSON लगता है। पहले जो JSON output था, वह शायद अपनी निजी non-standard schema वाला था

  • शुरुआती सवाल है, लेकिन मैं जानना चाहता हूँ कि GCC अंदरूनी तौर पर कहीं LLVM का इस्तेमाल करता है, या उसका अपना code generation और optimization pipeline है। LLVM की तुलना में यह किस स्तर पर है, यह भी जानना चाहता हूँ

    • GCC LLVM का इस्तेमाल नहीं करता
      यह LLVM से अधिक targets को support करता है, और ज़्यादातर मामलों में समान या बेहतर executables बनाता है
    • Wikipedia-शैली में जवाब दें तो, जैसा पहले कहा गया, GCC LLVM से बहुत पुराना है
      Wikipedia के अनुसार GCC 22 मार्च 1987 का है, जबकि LLVM की शुरुआती release 2003 की है
      एक और बड़ा फ़र्क license का है। GCC GPL है, LLVM Apache License है, इसलिए दोनों projects code साझा नहीं करते
    • नहीं करता
    • दूसरे जवाबों का “नहीं!” सही है, लेकिन पहले GCC के लिए LLVM backend इस्तेमाल करने वाला एक GCC plugin था
      Apple ने GCC से LLVM पर जाने के दौर में, लगभग 2012 के आसपास, llvm-gcc का इस्तेमाल किया था, जो GCC front end और LLVM back end का संयोजन था
      https://dragonegg.llvm.org
    • GCC LLVM से बहुत पुराना है, और दोनों code साझा नहीं करते

  • क्या -Ofast अभी भी -fno-fast-math को ignore करता है?

  • पिछले लगभग 3 महीनों से मैं unstable source इस्तेमाल कर रहा हूँ
    कुछ programs हाल की GCC से compile नहीं होते, लेकिन पुरानी GCC से ठीक चलते हैं, इसलिए फिलहाल कुल मिलाकर gcc 15.x मेरे लिए बेहतर बैठता है
    फिर भी अगर देखें कि मैं 3000 से ज़्यादा programs compile करता हूँ, तो अधिकांश ठीक चल जाते हैं, और सिर्फ़ कुछ को patch की ज़रूरत पड़ती है। ऐसे patch अक्सर LFS/BLFS में मिल जाते हैं, और individual issues को sed से ठीक करने पर आमतौर पर काम हो जाता है
    उम्मीद है कि वे समस्याएँ ठीक हो गई होंगी। हम सबको stability और “बस काम करने वाली” चीज़ों की ज़रूरत है

    • क्या उन समस्याओं के लिए bug reports दर्ज की गईं?