GCC Help

• Thread Index

• gcc-10 Bug report
  • From: Selçuk Han AYDIN <shaydin@xxxxxxxxxx>
• Re: how to makeinfo the standalone texinfo source tarballs?
  • From: David Liu <xdavidliu@xxxxxxxxx>
• g++, ld: Warning: size of symbol '_' changed (g++3.4)
  • From: LMH <lmh_users-groups@xxxxxxxxxxx>
• Re: how to makeinfo the standalone texinfo source tarballs?
  • From: Stefan Ring <stefanrin@xxxxxxxxx>
• how to makeinfo the standalone texinfo source tarballs?
  • From: David Liu <xdavidliu@xxxxxxxxx>
• Re: Fwd: Eorror compiling GCC-4.8.0 for Solaris 2.9 and 2.10
  • From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
• Re: Fwd: Eorror compiling GCC-4.8.0 for Solaris 2.9 and 2.10
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: problem building cross-gcc with pre-built cross-gcc
  • From: stsp <stsp2@xxxxxxxxx>
• Re: Fwd: Eorror compiling GCC-4.8.0 for Solaris 2.9 and 2.10
  • From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
• Re: AW: make static method find_reloads_address_1(...) extern accessible
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Fwd: Eorror compiling GCC-4.8.0 for Solaris 2.9 and 2.10
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• Re: Fwd: Eorror compiling GCC-4.8.0 for Solaris 2.9 and 2.10
  • From: Rainer Orth <ro@xxxxxxxxxxxxxxxxxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• problem building cross-gcc with pre-built cross-gcc
  • From: stsp <stsp2@xxxxxxxxx>
• Regarding GCOV
  • From: Aditya h <haditya9949@xxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• Re: gcc on Sparc Solaris 8
  • From: "rolf perau via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: gcc on Sparc Solaris 8
  • From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
• Re: gcc on Sparc Solaris 8
  • From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
• Re: gcc on Sparc Solaris 8
  • From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
• AW: make static method find_reloads_address_1(...) extern accessible
  • From: <stefan@xxxxxxxxx>
• Re: make static method find_reloads_address_1(...) extern accessible
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• Re: gcc on Sparc Solaris 8
  • From: "rolf perau via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: make static method find_reloads_address_1(...) extern accessible
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: gcc on Sparc Solaris 8
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: gcc on Sparc Solaris 8
  • From: "rolf perau via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• make static method find_reloads_address_1(...) extern accessible
  • From: <stefan@xxxxxxxxx>
• Re: Using C++20 __VA_OPT__ in a macro gives an error
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Support for __VA_OPT__ in gcc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: gcc on Sparc Solaris 8
  • From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
• gcc on Sparc Solaris 8
  • From: "rolf perau via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Using C++20 __VA_OPT__ in a macro gives an error
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• Support for __VA_OPT__ in gcc
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• RE: Using C on x86-64, why emit .text for global data?
  • From: Bob Plantz <rgplantz@xxxxxxxxxxx>
• Re: Using C on x86-64, why emit .text for global data?
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: Logical operator inside fold-expression: strange warning
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Using C on x86-64, why emit .text for global data?
  • From: Bob Plantz <rgplantz@xxxxxxxxxxx>
• Re: Help with "unable to generate reloads for" atomic_exchangesi
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Using C++20 __VA_OPT__ in a macro gives an error
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• Re: Odd optimizer behavior with FP arithmetic
  • From: Konstantin Shegunov <kshegunov@xxxxxxxxx>
• Re: Odd optimizer behavior with FP arithmetic
  • From: Alexander Monakov <amonakov@xxxxxxxxx>
• Re: Logical operator inside fold-expression: strange warning
  • From: Niklas Gürtler <profclonk@xxxxxxxxx>
• Odd optimizer behavior with FP arithmetic
  • From: Konstantin Shegunov <kshegunov@xxxxxxxxx>
• Logical operator inside fold-expression: strange warning
  • From: "Student FourK via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: about gcc native on Microsoft Windows
  • From: Liu Hao <lh_mouse@xxxxxxx>
• Re: about gcc native on Microsoft Windows
  • From: Stefan Ring <stefanrin@xxxxxxxxx>
• Re: about gcc native on Microsoft Windows
  • From: Liu Hao <lh_mouse@xxxxxxx>
• Re: about gcc native on Microsoft Windows
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• AW: Why does gcc not provide CMakeList.txt for compilation?
  • From: <stefan@xxxxxxxxx>
• Why does gcc not provide CMakeList.txt for compilation?
  • From: unlvsur unlvsur <unlvsur@xxxxxxxx>
• RE: about gcc native on Microsoft Windows
  • From: Tamar Christina <Tamar.Christina@xxxxxxx>
• Re: about gcc native on Microsoft Windows
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• AW: Help with "unable to generate reloads for" atomic_exchangesi
  • From: <stefan@xxxxxxxxx>
• Re: Help with "unable to generate reloads for" atomic_exchangesi
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Help with "unable to generate reloads for" atomic_exchangesi
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: about gcc native on Microsoft Windows
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Help with "unable to generate reloads for" atomic_exchangesi
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Help with "unable to generate reloads for" atomic_exchangesi
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Strange error message from an incorrect typedef
  • From: Edward Diener <eldlistmailingz@xxxxxxxxxxxxxx>
• RE: GCC 8.3.0, libatomic and text relocations
  • From: "Kacvinsky, Tom" <Tom.Kacvinsky@xxxxxxxxxx>
• Re: GCC 8.3.0, libatomic and text relocations
  • From: Florian Weimer <fw@xxxxxxxxxxxxx>
• Re: ERROR DURING INSTALLATION
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• GCC 8.3.0, libatomic and text relocations
  • From: "Kacvinsky, Tom" <Tom.Kacvinsky@xxxxxxxxxx>
• ERROR DURING INSTALLATION
  • From: Ana <anna.207346@xxxxxxxxx>
• Re: taking OpenCL C as a built-in lang of GCC?
  • From: Jason Merrill <jason@xxxxxxxxxx>
• Re: [DSO missing from command line] gcc-c++ error
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• Re: taking OpenCL C as a built-in lang of GCC?
  • From: Jeff Law <law@xxxxxxxxxx>
• AW: new ira optimization - adding a loop to ira
  • From: <stefan@xxxxxxxxx>
• Re: [DSO missing from command line] gcc-c++ error
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: [DSO missing from command line] gcc-c++ error
  • From: Vassilena Treneva <treneva@xxxxxxxxx>
• Re: [DSO missing from command line] gcc-c++ error
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• [DSO missing from command line] gcc-c++ error
  • From: Vassilena Treneva <treneva@xxxxxxxxx>
• Re: Header search order problem
  • From: Josh Scoggins <josh.scoggins@xxxxxxxxxxxx>
• Header search order problem
  • From: David Aldrich <david.aldrich.ntml@xxxxxxxxx>
• Different output between 9.2 and 8.3: Regression or expected?
  • From: "Hong X" <hongx@xxxxxxx>
• _FORTIFY_SOURCE and libtool
  • From: Liu Hao <lh_mouse@xxxxxxx>
• AW: new ira optimization - adding a loop to ira
  • From: <stefan@xxxxxxxxx>
• AW: new ira optimization - adding a loop to ira
  • From: <stefan@xxxxxxxxx>
• AW: new ira optimization - adding a loop to ira
  • From: <stefan@xxxxxxxxx>
• Re: new ira optimization - adding a loop to ira
  • From: Richard Sandiford <richard.sandiford@xxxxxxx>
• new ira optimization - adding a loop to ira
  • From: <stefan@xxxxxxxxx>
• Re: About machine description for atomic_exchange
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: About machine description for atomic_exchange
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: taking OpenCL C as a built-in lang of GCC?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• taking OpenCL C as a built-in lang of GCC?
  • From: "Jianbin Fang" <jianbinfang@xxxxxxxx>
• Re: Role of unspec or unspec_volatile in a machine description pattern
  • From: "Ian Lance Taylor via gcc-help" <gcc-help@xxxxxxxxxxx>
• Role of unspec or unspec_volatile in a machine description pattern
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Question about __builtin_strlen and constexpr
  • From: "Yan Yichen" <yichen.yan@xxxxxxxxxxx>
• Re: About machine description for atomic_exchange
  • From: Oleg Endo <oleg.endo@xxxxxxxxxxx>
• Re: gcc-ver 7.3 support
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• gcc-ver 7.3 support
  • From: "Krishnakant Mehta via gcc-help" <gcc-help@xxxxxxxxxxx>
• About machine description for atomic_exchange
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Machine description for volatile memory access
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: Machine description for volatile memory access
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Machine description for volatile memory access
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Machine description for volatile memory access
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: Alexander Monakov <amonakov@xxxxxxxxx>
• Re: Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: Ayrat Gaskarov <777grand@xxxxxxxxx>
• Re: Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: Alexander Monakov <amonakov@xxxxxxxxx>
• Re: Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: Ayrat Gaskarov <777grand@xxxxxxxxx>
• Re: Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: David Brown <david.brown@xxxxxxxxxxxx>
• Re: Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Local variables reordering and 'asm volatile("" ::: "memory");'
  • From: Ayrat Gaskarov <777grand@xxxxxxxxx>
• Re: Trouble with --with-sysroot
  • From: Christer Solskogen <christer.solskogen@xxxxxxxxx>
• Re: Trouble with --with-sysroot
  • From: Alex <wailingoctopus@xxxxxxxxx>
• Re: Trouble with --with-sysroot
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: Trouble with --with-sysroot
  • From: Alex <wailingoctopus@xxxxxxxxx>
• gcc openmp target nvptx: LTO_tags out of range
  • From: Jeffrey Kelling <j.kelling@xxxxxxx>
• Re: Trouble with --with-sysroot
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Trouble with --with-sysroot
  • From: Alex <wailingoctopus@xxxxxxxxx>
• Re: libssp_nonshared license problem
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: libssp_nonshared license problem
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• libssp_nonshared license problem
  • From: yao zhuang <secularbird.eagle@xxxxxxxxx>
• while building GCC linking libstdc++.so with the correct libgcc_s.so.1
  • From: Marco Maggi <mrc.mgg@xxxxxxxxx>
• gcc-helpnetwork system
  • From: "Sales.35@xxxxxxxxxxxxxx" <Sales.35@xxxxxxxxxxxxxx>
• Re: Use and misuse of __builtin_expect
  • From: Denis Efremov <efremov@xxxxxxxxx>
• Re: bool to size_t warning
  • From: Jonny Grant <jg@xxxxxxxx>
• Re: bool to size_t warning
  • From: Martin Sebor <msebor@xxxxxxxxx>
• Re: bool to size_t warning
  • From: Jonny Grant <jg@xxxxxxxx>
• Re: bool to size_t warning
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: bool to size_t warning
  • From: Jonny Grant <jg@xxxxxxxx>
• Re: argument "named" of TARGET_FUNCTION_ARG
  • From: Richard Sandiford <richard.sandiford@xxxxxxx>
• Re: bool to size_t warning
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• argument "named" of TARGET_FUNCTION_ARG
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Promo Products For Events
  • From: <amy@xxxxxxxxxxxxxx>
• Use and misuse of __builtin_expect
  • From: Denis Efremov <efremov@xxxxxxxxx>
• Re: How to debug null-pointer function call within __do_global_dtors_aux()
  • From: Richard Sandiford <richard.sandiford@xxxxxxx>
• Re: How to debug null-pointer function call within __do_global_dtors_aux()
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: How to debug null-pointer function call within __do_global_dtors_aux()
  • From: Richard Sandiford <richard.sandiford@xxxxxxx>
• How to debug null-pointer function call within __do_global_dtors_aux()
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: does gcc support _mm256_loadu2_m128i()
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• How to insert a new function in plugin?
  • From: 时彦辉 <shiyanhui@xxxxxxxx>
• does gcc support _mm256_loadu2_m128i()
  • From: qw <applemax82@xxxxxxx>
• Re: cross-compiling gcc-8.3.0 fail; Makefile:528: recipe for target 'elf.lo' failed
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• cross-compiling gcc-8.3.0 fail; Makefile:528: recipe for target 'elf.lo' failed
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: unrecognizable insn
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: what does help?
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• Re: what does help?
  • From: Ali MURAT <alimupas2@xxxxxxxxx>
• what does help?
  • From: Ali MURAT <alimupas2@xxxxxxxxx>
• Re: NULL_RTX etc
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• NULL_RTX etc
  • From: graham stott <graham.stott77@xxxxxxxxx>
• Re: unrecognizable insn
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• unrecognizable insn
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Are pretend arguments included in the outgoing argument region ?
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: Are pretend arguments included in the outgoing argument region ?
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Are pretend arguments included in the outgoing argument region ?
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Are pretend arguments included in the outgoing argument region ?
  • From: Jeff Law <law@xxxxxxxxxx>
• Are pretend arguments included in the outgoing argument region ?
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Does the sign of the value returned by INITIAL_ELIMINATION_OFFSET matters ?
  • From: Jeff Law <law@xxxxxxxxxx>
• Does the sign of the value returned by INITIAL_ELIMINATION_OFFSET matters ?
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: dg-error having two regexes
  • From: Akshat Garg <xkspr7@xxxxxxxxx>
• Re: dg-error having two regexes
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: dg-error having two regexes
  • From: Akshat Garg <xkspr7@xxxxxxxxx>
• Re: dg-error having two regexes
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: dg-error having two regexes
  • From: Akshat Garg <xkspr7@xxxxxxxxx>
• Re: dg-error having two regexes
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: dg-error having two regexes
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• dg-error having two regexes
  • From: Akshat Garg <xkspr7@xxxxxxxxx>
• Re: it is problem?
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• it is problem?
  • From: Ali MURAT <alimupas2@xxxxxxxxx>
• Re: bool to size_t warning
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• Re: bool to size_t warning
  • From: Jonny Grant <jg@xxxxxxxx>
• Re: bool to size_t warning
  • From: Maksim Fomin <maxim@xxxxxxxxx>
• bool to size_t warning
  • From: Jonny Grant <jg@xxxxxxxx>
• Re: how to configure GCC to have caller save registers instead of callee prologue
  • From: Richard Sandiford <richard.sandiford@xxxxxxx>
• Re: stage1 bootstrap 9.1.0 on RHEL produces 64-bit ELF output in gcc/32/crtbeginS.o
  • From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
• stage1 bootstrap 9.1.0 on RHEL produces 64-bit ELF output in gcc/32/crtbeginS.o
  • From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
• Re: how to configure GCC to have caller save registers instead of callee prologue
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: how to configure GCC to have caller save registers instead of callee prologue
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: how to configure GCC to have caller save registers instead of callee prologue
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: gcc -Wconversion
  • From: David Aldrich <david.aldrich.ntml@xxxxxxxxx>
• Re: Troubles building cross-compiler; target 64-bit RISC-V
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: gcc -Wconversion
  • From: Richard Sandiford <richard.sandiford@xxxxxxx>
• gcc -Wconversion
  • From: David Aldrich <david.aldrich.ntml@xxxxxxxxx>
• Re: Troubles building cross-compiler; target 64-bit RISC-V
  • From: <64m@xxxxxxxxxxxx>
• Re: Manuals for GCC v8.2.0.3
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Manuals for GCC v8.2.0.3
  • From: "Kewen.Lin" <linkw@xxxxxxxxxxxxx>
• Manuals for GCC v8.2.0.3
  • From: <dmurley@xxxxxxxx>
• Re: how to configure GCC to have caller save registers instead of callee prologue
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: how to configure GCC to have caller save registers instead of callee prologue
  • From: Florian Weimer <fw@xxxxxxxxxxxxx>
• Re: Troubles building cross-compiler; target 64-bit RISC-V
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: Troubles building cross-compiler; target 64-bit RISC-V
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Troubles building cross-compiler; target 64-bit RISC-V
  • From: <64m@xxxxxxxxxxxx>
• Re: Question about AArch64 mcmodel=large
  • From: "Richard Earnshaw (lists)" <Richard.Earnshaw@xxxxxxx>
• how to configure GCC to have caller save registers instead of callee prologue
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Troubles building cross-compiler; target 64-bit RISC-V
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Troubles building cross-compiler; target 64-bit RISC-V
  • From: <64m@xxxxxxxxxxxx>
• Question about AArch64 mcmodel=large
  • From: "Bu Le" <cityubule@xxxxxx>
• Re: Understanding target specifications for memory barriers
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Can I thrust in GCC doing the right thing when casting to a wider type in C?
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Can I thrust in GCC doing the right thing when casting to a wider type in C?
  • From: Alexander Monakov <amonakov@xxxxxxxxx>
• Can I thrust in GCC doing the right thing when casting to a wider type in C?
  • From: Aaron <aaron_ng@xxxxxxxx>
• Standard expand_prologue() and expand_epilogue() implementations
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Understanding target specifications for memory barriers
  • From: Akshat Garg <xkspr7@xxxxxxxxx>
• C++: __asm on static method
  • From: Georg-Johann Lay <avr@xxxxxxxx>
• Re: Dejagnu: Catch cc1 regexp errors without associated line number
  • From: Richard Sandiford <richard.sandiford@xxxxxxx>
• Dejagnu: Catch cc1 regexp errors without associated line number
  • From: Maxim Blinov <maxim.blinov@xxxxxxxxxxxx>
• Re: flow control statement
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: Should a class-scope typedef effect ODR?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: flow control statement
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: Should a class-scope typedef effect ODR?
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Should a class-scope typedef effect ODR?
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Re: flow control statement
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Fwd: flow control statement
  • From: Ali MURAT <alimupas2@xxxxxxxxx>
• Re: GFortran
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• GFortran
  • From: Александр К-ш <russianbear77@xxxxxxxxx>
• Re: Optimization difference between C and C++
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Optimization difference between C and C++
  • From: BCartier <baptiste.cartier.job@xxxxxxxxx>
• -Wsuggest-attribute=cold issue?
  • From: John Harwell <john.r.harwell@xxxxxxxxx>
• Re: problem on modifying gcc backend for riscv
  • From: Faisal Riyaz <faisalriyaz011@xxxxxxxxx>
• Re: problem on modifying gcc backend for riscv
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: problem on modifying gcc backend for riscv
  • From: Faisal Riyaz <faisalriyaz011@xxxxxxxxx>
• Re: problem on modifying gcc backend for riscv
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: problem on modifying gcc backend for riscv
  • From: Faisal Riyaz <faisalriyaz011@xxxxxxxxx>
• Re: problem on modifying gcc backend for riscv
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: problem on modifying gcc backend for riscv
  • From: Richard Earnshaw <Richard.Earnshaw@xxxxxxx>
• Re: problem on modifying gcc backend for riscv
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Ticket 205680 Request quote for GNU Software Foundation - Fortran Compiler
  • From: Bob Wilkinson <bob.wilkinson@xxxxxxxxxxx>
• Ticket 205680 Request quote for GNU Software Foundation - Fortran Compiler
  • From: "EXI-Atkuri, Naga P" <naga.p.atkuri@xxxxxxxxxx>
• problem on modifying gcc backend for riscv
  • From: Faisal Riyaz <faisalriyaz011@xxxxxxxxx>
• Re: Problem in GCC online manual?
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Problem in GCC online manual?
  • From: Jon Taylor <dosadi82@xxxxxxxxx>
• Re: how to force mem constraint for symbol ?
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: how to force mem constraint for symbol ?
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Bad instructions
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• Re: Bad instructions
  • From: "Mahmood Naderan via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Bad instructions
  • From: "Mahmood Naderan via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Bad instructions
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• Bad instructions
  • From: "Mahmood Naderan via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: how to force mem constraint for symbol ?
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Hi everyone, this is unidef
  • From: Richard Biener <richard.guenther@xxxxxxxxx>
• Re: variable length array (VLA) reference (global, extern access, etc)
  • From: Jeff Law <law@xxxxxxxxxx>
• variable length array (VLA) reference (global, extern access, etc)
  • From: phi gcc <phi.gcc@xxxxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Oleg Endo <oleg.endo@xxxxxxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Paul Smith <psmith@xxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Oleg Endo <oleg.endo@xxxxxxxxxxx>
• Re: one ask for know information about gcc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• RE: one ask for know information about gcc
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Paul Smith <psmith@xxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: enquiry
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• one ask for know information about gcc
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: how to force mem constraint for symbol ?
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: how to force mem constraint for symbol ?
  • From: Jeff Law <law@xxxxxxxxxx>
• how to force mem constraint for symbol ?
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• RE: Nobody help myself in older e-mail
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• enquiry
  • From: Manfredo di Porcia <manfredodiporcia@xxxxxxxxx>
• Re: Nobody help myself in older e-mail
  • From: Paul Smith <paul@xxxxxxxxxxxxxxxxx>
• RE: Nobody help myself in older e-mail
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• RE: Nobody help myself in older e-mail
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• RE: Nobody help myself in older e-mail
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Nobody help myself in older e-mail
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Paul Smith <psmith@xxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Paul Smith <psmith@xxxxxxx>
• Re: std::chrono is much slower than native requests...?
  • From: Alexander Monakov <amonakov@xxxxxxxxx>
• std::chrono is much slower than native requests...?
  • From: Paul Smith <paul@xxxxxxxxxxxxxxxxx>
• Re: x86 long double
  • From: Andrew Haley <aph@xxxxxxxxxx>
• x86 long double
  • From: Cristiano Di Buduo <cristiano@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Kai Ruottu <kai.ruottu@xxxxxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: [x86 inline asm]: width of register arguments
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Why Ubuntu GCC 9.1 is faster than vanilla GCC 9.1 with these patches?
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Andrew Haley <aph@xxxxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: [x86 inline asm]: width of register arguments
  • From: "Zdenek Sojka" <zsojka@xxxxxxxxx>
• Re: Which header for AMD XOP _mm_roti_epi64?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Which header for AMD XOP _mm_roti_epi64?
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Which header for AMD XOP _mm_roti_epi64?
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Re: Which header for AMD XOP _mm_roti_epi64?
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Which header for AMD XOP _mm_roti_epi64?
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Re: Which header for AMD XOP _mm_roti_epi64?
  • From: Marc Glisse <marc.glisse@xxxxxxxx>
• Re: Which header for AMD XOP _mm_roti_epi64?
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Which header for AMD XOP _mm_roti_epi64?
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: [x86 inline asm]: width of register arguments
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: help with compiling for PPC8540
  • From: "Peggy Harvey via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: [x86 inline asm]: width of register arguments
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: gcc warn C++ implicit enum conversion
  • From: Jonny Grant <jg@xxxxxxxx>
• Re: I can't install gcc 9
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: gcc warn C++ implicit enum conversion
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: [x86 inline asm]: width of register arguments
  • From: "Zdenek Sojka" <zsojka@xxxxxxxxx>
• Re: help with compiling for PPC8540
  • From: Kai Ruottu <kai.ruottu@xxxxxxxxxxx>
• Re: help with compiling for PPC8540
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: help with compiling for PPC8540
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Why Ubuntu GCC 9.1 is faster than vanilla GCC 9.1 with these patches?
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• gcc warn C++ implicit enum conversion
  • From: Jonny Grant <jg@xxxxxxxx>
• RE: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: I can't install gcc 9
  • From: Andrew Haley <aph@xxxxxxxxxx>
• I can't install gcc 9
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• RE: gcc 9 can't be compile too missing make files for make command line
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• help with compiling for PPC8540
  • From: "Peggy Harvey via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Install gcj with gcc5 on ubunto
  • From: "charfi asma via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: gcc 9 can't be compile too missing make files for make command line
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• gcc 9 can't be compile too missing make files for make command line
  • From: Dorian ROSSE <dorianbrice@xxxxxxxxxx>
• Re: Install gcj with gcc5 on ubunto
  • From: "Anastasios Lisgaras via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Install gcj with gcc5 on ubunto
  • From: "charfi asma via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Install gcj with gcc5 on ubunto
  • From: "Anastasios Lisgaras via gcc-help" <gcc-help@xxxxxxxxxxx>
• Install gcj with gcc5 on ubunto
  • From: "charfi asma via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Injecting user defined opcode
  • From: Max Schneider <king@xxxxxxxxxxxxxxxxxx>
• Re: Injecting user defined opcode
  • From: "Mahmood Naderan via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Injecting user defined opcode
  • From: "Mahmood Naderan via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Injecting user defined opcode
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Injecting user defined opcode
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• Re: Injecting user defined opcode
  • From: "Mahmood Naderan via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Injecting user defined opcode
  • From: "Mahmood Naderan via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Injecting user defined opcode
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Injecting user defined opcode
  • From: "Mahmood Naderan via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: [x86 inline asm]: width of register arguments
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Gcj - Upgraded VOIP System?
  • From: Kim Awet <kimaawet54@xxxxxxxxx>
• Re: Compilation of large random forest models with g++
  • From: NightStrike <nightstrike@xxxxxxxxx>
• Re: Compilation of large random forest models with g++
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Default debug format
  • From: Florian Doersch <gcc@xxxxxxxxxxxx>
• Re: Compilation of large random forest models with g++
  • From: Mikail Yayla <mikail.yayla@xxxxxxxxxxxxxx>
• Re: CFG generation from C/C++ and JAVA
  • From: NightStrike <nightstrike@xxxxxxxxx>
• Re: CFG generation from C/C++ and JAVA
  • From: "charfi asma via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Compilation of large random forest models with g++
  • From: NightStrike <nightstrike@xxxxxxxxx>
• Compilation of large random forest models with g++
  • From: Mikail Yayla <mikail.yayla@xxxxxxxxxxxxxx>
• Re: CFG generation from C/C++ and JAVA
  • From: Richard Biener <richard.guenther@xxxxxxxxx>
• Re: -mgeneral-regs-only changes preprocessor macros
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Default debug format
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• CFG generation from C/C++ and JAVA
  • From: "charfi asma via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Default debug format
  • From: David Edelsohn <dje.gcc@xxxxxxxxx>
• Re: Default debug format
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Default debug format
  • From: Florian Doersch <gcc@xxxxxxxxxxxx>
• Re: Enabling traps for floating point exceptions
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: -mgeneral-regs-only changes preprocessor macros
  • From: "J.W. Jagersma" <jwjagersma@xxxxxxxxx>
• Re: -mgeneral-regs-only changes preprocessor macros
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• -mgeneral-regs-only changes preprocessor macros
  • From: "J.W. Jagersma" <jwjagersma@xxxxxxxxx>
• Enabling traps for floating point exceptions
  • From: Faisal Riyaz <faisalriyaz011@xxxxxxxxx>
• *.gcda files are not getting generated
  • From: "Basavaraj A S (RBEI/EBA8) via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Help needed building gcc on Arm
  • From: Tim Janes <twjanes@xxxxxxxxx>
• Re: GCC PE support
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: Partial dead code elimination
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: Help needed building gcc on Arm
  • From: "Richard Earnshaw (lists)" <Richard.Earnshaw@xxxxxxx>
• Re: Help needed building gcc on Arm
  • From: Tim Janes <twjanes@xxxxxxxxx>
• [x86 inline asm]: width of register arguments
  • From: "Zdenek Sojka" <zsojka@xxxxxxxxx>
• Re: Help needed building gcc on Arm
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Partial dead code elimination
  • From: Gohil Dwijesh <iddwijesh@xxxxxxxxx>
• Re: Fortran C interoperabiltiy documentation
  • From: "N.M. Maclaren" <nmm1@xxxxxxxxx>
• Re: GCC PE support
  • From: valerij zaporogeci <vlrzprgts@xxxxxxxxx>
• Re: Help needed building gcc on Arm
  • From: Emilio Riva <aviroilime@xxxxxxxxx>
• Help needed building gcc on Arm
  • From: Tim Janes <twjanes@xxxxxxxxx>
• Fortran C interoperabiltiy documentation
  • From: NightStrike <nightstrike@xxxxxxxxx>
• Re: GCC PE support
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: __STDC_NO_THREADS__ and late model gcc/glibc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: __STDC_NO_THREADS__ and late model gcc/glibc
  • From: Chris Hall <chris.hall@xxxxxxx>
• Re: libatomic, 32-bit object code vs. 64-bit object, GCC 8.3.0
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• GCC PE support
  • From: valerij zaporogeci <vlrzprgts@xxxxxxxxx>
• RE: libatomic, 32-bit object code vs. 64-bit object, GCC 8.3.0
  • From: "Kacvinsky, Tom" <Tom.Kacvinsky@xxxxxxxxxx>
• Re: libatomic, 32-bit object code vs. 64-bit object, GCC 8.3.0
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• libatomic, 32-bit object code vs. 64-bit object, GCC 8.3.0
  • From: "Kacvinsky, Tom" <Tom.Kacvinsky@xxxxxxxxxx>
• Re: How to positively detect if rtti is enabled or not
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: How to positively detect if rtti is enabled or not
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: How to positively detect if rtti is enabled or not
  • From: ba58smith <ba58smith@xxxxxxxxx>
• Re: __STDC_NO_THREADS__ and late model gcc/glibc
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• __STDC_NO_THREADS__ and late model gcc/glibc
  • From: Chris Hall <gcc@xxxxxxx>
• Re: How to positively detect if rtti is enabled or not
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: How to positively detect if rtti is enabled or not
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: How to positively detect if rtti is enabled or not
  • From: ba58smith <ba58smith@xxxxxxxxx>
• Re: How to positively detect if rtti is enabled or not
  • From: Marc Glisse <marc.glisse@xxxxxxxx>
• How to positively detect if rtti is enabled or not
  • From: ba58smith <ba58smith@xxxxxxxxx>
• How to change default search paths when compiling gcc?
  • From: Daniele Testa <daniele.testa@xxxxxxxxx>
• Re[8]: GCC won`t emit my instriction
  • From: "Alex Hill via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Re[6]: GCC won`t emit my instriction
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re[6]: GCC won`t emit my instriction
  • From: "Alex Hill via gcc-help" <gcc-help@xxxxxxxxxxx>
• Rebuild debug info after struct modifications in PLUGIN_FINISH_TYPE
  • From: remy <rnicol@xxxxxxx>
• Re: xgcc, ICE, and how to script -O changes
  • From: Brian Groose <bgroose@xxxxxxxxx>
• Re: xgcc, ICE, and how to script -O changes
  • From: Thomas Schwinge <thomas@xxxxxxxxxxxxxxxx>
• Re: xgcc, ICE, and how to script -O changes
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• xgcc, ICE, and how to script -O changes
  • From: Brian Groose <bgroose@xxxxxxxxx>
• OT: C++ on Mars
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Re: Re[4]: GCC won`t emit my instriction
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re[4]: GCC won`t emit my instriction
  • From: "Alex Hill via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: there is no "installation" section of the GCC Manual
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: Re[2]: GCC won`t emit my instriction
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re[2]: GCC won`t emit my instriction
  • From: "Alex Hill via gcc-help" <gcc-help@xxxxxxxxxxx>
• there is no "installation" section of the GCC Manual
  • From: Dennis Clarke <dclarke@xxxxxxxxxxxxx>
• Re: GCC won`t emit my instriction
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: GCC api details - Reg
  • From: suvendu mohapatra <suv2020@xxxxxxxxx>
• Re: Reproducible build of a GCC cross-compiler?
  • From: Sebastian Huber <sebastian.huber@xxxxxxxxxxxxxxxxxx>
• Re: Reproducible build of a GCC cross-compiler?
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Reproducible build of a GCC cross-compiler?
  • From: Sebastian Huber <sebastian.huber@xxxxxxxxxxxxxxxxxx>
• Re[2]: GCC won`t emit my instriction
  • From: "Alex Hill via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: GCC won`t emit my instriction
  • From: Jeff Law <law@xxxxxxxxxx>
• GCC won`t emit my instriction
  • From: "Alex Hill via gcc-help" <gcc-help@xxxxxxxxxxx>
• defining object in inline assembly, referencing it from C code
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• Re: problem after using gsi_remove
  • From: 李宗霖 <fight1995go@xxxxxxxxx>
• Re: Vanilla GCC 9 slower than Ubuntu GCC 9
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: [make profiledbootstrap] gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug/Makefile: No such file or directory
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: Effect of -finput-charset in gcc and phases of translation
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Effect of -finput-charset in gcc and phases of translation
  • From: esoteric escape <manips88@xxxxxxxxx>
• Re: Effect of -finput-charset in gcc and phases of translation
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: GCC api details - Reg
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Effect of -finput-charset in gcc and phases of translation
  • From: esoteric escape <manips88@xxxxxxxxx>
• GCC api details - Reg
  • From: suvendu mohapatra <suv2020@xxxxxxxxx>
• Re: problem after using gsi_remove
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: problem after using gsi_remove
  • From: Marc Glisse <marc.glisse@xxxxxxxx>
• problem after using gsi_remove
  • From: 李宗霖 <fight1995go@xxxxxxxxx>
• Re: Implementation-defined behavior or not?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Implementation-defined behavior or not?
  • From: esoteric escape <manips88@xxxxxxxxx>
• Re: [make profiledbootstrap] gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug/Makefile: No such file or directory
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: [make profiledbootstrap] gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug/Makefile: No such file or directory
  • From: Stefan Ring <stefanrin@xxxxxxxxx>
• Re: Implementation-defined behavior or not?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Implementation-defined behavior or not?
  • From: esoteric escape <manips88@xxxxxxxxx>
• Re: Implementation-defined behavior or not?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Implementation-defined behavior or not?
  • From: esoteric escape <manips88@xxxxxxxxx>
• g++ and IBM AIX: another exception handling bug?
  • From: Florian Dörsch <webmaster@xxxxxxxxxxxxxxxx>
• Re[2]: require assistance with emiting instructions
  • From: "Alex Hill via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Manual and documentation for GCC 8.1
  • From: Andrew Melo <andrew.melo@xxxxxxxxx>
• Manual and documentation for GCC 8.1
  • From: esoteric escape <manips88@xxxxxxxxx>
• Re: GCC Front-ends?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• GCC Front-ends?
  • From: esoteric escape <manips88@xxxxxxxxx>
• Re[2]: require assistance with emiting instructions
  • From: "Alex Hill via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: Error: no iconv implementation
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Error: no iconv implementation
  • From: esoteric escape <manips88@xxxxxxxxx>
• Re: require assistance with emiting instructions
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• Re: Vanilla GCC 9 slower than Ubuntu GCC 9
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: Vanilla GCC 9 slower than Ubuntu GCC 9
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: Converting addc to adcx
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Quotation about plastic injection molds
  • From: CSAI <aa-001@xxxxxxxxxxxxxxxxxxxxxxxx>
• Re: Converting addc to adcx
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Converting addc to adcx
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Re: Converting addc to adcx
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• require assistance with emiting instructions
  • From: "Alex Hill via gcc-help" <gcc-help@xxxxxxxxxxx>
• Converting addc to adcx
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Downgrading to GCC 7.3.0 from 7.4.0 in ubuntu 18.04 environment
  • From: RAJ PRAJAPATI <rajatmelavr@xxxxxxxxx>
• Re: [make profiledbootstrap] gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug/Makefile: No such file or directory
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: [make profiledbootstrap] gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug/Makefile: No such file or directory
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: Location of Ada Standard package
  • From: Florian Weimer <fw@xxxxxxxxxxxxx>
• Re: ARM EABI support for StrongArm SA-110
  • From: "Richard Earnshaw (lists)" <Richard.Earnshaw@xxxxxxx>
• Location of Ada Standard package
  • From: Patrick Kelly <p-kell@xxxxxxxx>
• Re: std::conjunction and SFINAE
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: [make profiledbootstrap] gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug/Makefile: No such file or directory
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• [make profiledbootstrap] gcc-9-build/x86_64-linux-gnu/libstdc++-v3/src/debug/Makefile: No such file or directory
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: std::conjunction and SFINAE
  • From: Johan Alfredsson <sduvan.gcc@xxxxxxxxx>
• Re: std::conjunction and SFINAE
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• std::conjunction and SFINAE
  • From: Johan Alfredsson <sduvan.gcc@xxxxxxxxx>
• ARM EABI support for StrongArm SA-110
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Vanilla GCC 9 slower than Ubuntu GCC 9
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Detect at compile-time if sync primitives are supported?
  • From: Christophe Lyon <christophe.lyon@xxxxxxxxxx>
• Re: Vanilla GCC 9 slower than Ubuntu GCC 9
  • From: Stefan Ring <stefanrin@xxxxxxxxx>
• Re: Finding the test suite for GNU Scientific Library's linear algebra component, BLAS
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: GCC Manual C or C++?
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: warning: listing the stack pointer register 'esp' in a clobber list is deprecated
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: warning: listing the stack pointer register 'esp' in a clobber list is deprecated
  • From: "J.W. Jagersma" <jwjagersma@xxxxxxxxx>
• Re: warning: listing the stack pointer register 'esp' in a clobber list is deprecated
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• warning: listing the stack pointer register 'esp' in a clobber list is deprecated
  • From: "J.W. Jagersma" <jwjagersma@xxxxxxxxx>
• Finding the test suite for GNU Scientific Library's linear algebra component, BLAS
  • From: "Zhoulai Fu@Gmail" <zhoulai.fu@xxxxxxxxx>
• GCC Manual C or C++?
  • From: esoteric escape <manips88@xxxxxxxxx>
• Re: ARM inline asm and temp register without extra move
  • From: Georg-Johann Lay <avr@xxxxxxxx>
• Vanilla GCC 9 slower than Ubuntu GCC 9
  • From: Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>
• Re: ARM inline asm and temp register without extra move
  • From: Max Filippov <jcmvbkbc@xxxxxxxxx>
• ARM inline asm and temp register without extra move
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Drilling, tapping, counter-sinkinggcc-help@xxxxxxxxxxx
  • From: "Machining shop -XIEJIN" <yong@xxxxxxxxxxxxxxx>
• Re: Compiling with -march=c3-2 generates illegal SSE instructions
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Compiling with -march=c3-2 generates illegal SSE instructions
  • From: tedheadster <tedheadster@xxxxxxxxx>
• implicit conversion warnings
  • From: Jonny Grant <jg@xxxxxxxx>
• Gcov in multi-thread programs
  • From: Victor Campos <vhscampos@xxxxxxxxx>
• Re: How to generate frame pointers on Cortex-M?
  • From: "Richard Earnshaw (lists)" <Richard.Earnshaw@xxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: How to generate frame pointers on Cortex-M?
  • From: Vicente Bergas <vicencb@xxxxxxxxx>
• Re: How to insert an external variable/symbol reference in RTL?
  • From: Arslan Khan <arslankhan52@xxxxxxxxx>
• How to insert an external variable/symbol reference in RTL?
  • From: Arslan Khan <arslankhan52@xxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Alexander Monakov <amonakov@xxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Ian Lance Taylor <iant@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Hamad Ahmed <ahmed90@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Ian Lance Taylor <iant@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Hamad Ahmed <ahmed90@xxxxxxxxxx>
• Re: zero-as-null-pointer-constant C++ trunk
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: zero-as-null-pointer-constant C++ trunk
  • From: Jonny Grant <jg@xxxxxxxx>
• Re: zero-as-null-pointer-constant C++ trunk
  • From: David Brown <david@xxxxxxxxxxxxxxx>
• Re: zero-as-null-pointer-constant C++ trunk
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: zero-as-null-pointer-constant C++ trunk
  • From: David Brown <david@xxxxxxxxxxxxxxx>
• Re: zero-as-null-pointer-constant C++ trunk
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• zero-as-null-pointer-constant C++ trunk
  • From: Jonny Grant <jg@xxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Ian Lance Taylor <iant@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: Build fail for 7.3.0 with in-tree binutils
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Build fail for 7.3.0 with in-tree binutils
  • From: flandraco <dirk.seynhaeve@xxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Hamad Ahmed <ahmed90@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: Issue byte codes for ARMv7's movw and movt?
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Re: Issue byte codes for ARMv7's movw and movt?
  • From: Richard Earnshaw <Richard.Earnshaw@xxxxxxxxxxxx>
• Issue byte codes for ARMv7's movw and movt?
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Re: How to generate frame pointers on Cortex-M?
  • From: "Richard Earnshaw (lists)" <Richard.Earnshaw@xxxxxxx>
• Re: How to generate frame pointers on Cortex-M?
  • From: Vicente Bergas <vicencb@xxxxxxxxx>
• Re: How to generate frame pointers on Cortex-M?
  • From: "Richard Earnshaw (lists)" <Richard.Earnshaw@xxxxxxx>
• How to generate frame pointers on Cortex-M?
  • From: Vicente Bergas <vicencb@xxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: different behaviors on gcc warning between one-step compile and separate-step compile
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: different behaviors on gcc warning between one-step compile and separate-step compile
  • From: Wx L <lwxiang1994@xxxxxxxxx>
• Re: different behaviors on gcc warning between one-step compile and separate-step compile
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: different behaviors on gcc warning between one-step compile and separate-step compile
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• different behaviors on gcc warning between one-step compile and separate-step compile
  • From: Wx L <lwxiang1994@xxxxxxxxx>
• Re: Global variables: -fno-common vs -fcommon on x86 32-bit vs 64-bit
  • From: David Brown <david.brown@xxxxxxxxxxxx>
• Re: Global variables: -fno-common vs -fcommon on x86 32-bit vs 64-bit
  • From: Arvind Sankar <nivedita@xxxxxxxxxxxx>
• Re: Global variables: -fno-common vs -fcommon on x86 32-bit vs 64-bit
  • From: Arvind Sankar <nivedita@xxxxxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Re: Global variables: -fno-common vs -fcommon on x86 32-bit vs 64-bit
  • From: Alexander Monakov <amonakov@xxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: Olaf van der Spek <ml@xxxxxxxxxx>
• Re: Global variables: -fno-common vs -fcommon on x86 32-bit vs 64-bit
  • From: David Brown <david.brown@xxxxxxxxxxxx>
• Global variables: -fno-common vs -fcommon on x86 32-bit vs 64-bit
  • From: Arvind Sankar <nivedita@xxxxxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: Olaf van der Spek <ml@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Hamad Ahmed <ahmed90@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Hamad Ahmed <ahmed90@xxxxxxxxxx>
• Re: (c++11) Why can std::bind be used without the std namespace prefix?
  • From: "Liu Hao" <lh_mouse@xxxxxxx>
• (c++11) Why can std::bind be used without the std namespace prefix?
  • From: Michael Haubenwallner <michael.haubenwallner@xxxxxxxxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Andrew Haley <aph@xxxxxxxxxx>
• Override function that returns thread-local storage pointer on armr5
  • From: Jeroen Koekkoek <jeroen@xxxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Hamad Ahmed <ahmed90@xxxxxxxxxx>
• Re: Objc foundation
  • From: Iain Sandoe <iain@xxxxxxxxxxxx>
• Objc foundation
  • From: Peter Wiehe <peter.wiehe2@xxxxxxxxx>
• Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: Mike Gilbert <floppym@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Alexander Monakov <amonakov@xxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Hamad Ahmed <ahmed90@xxxxxxxxxx>
• Re: How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• How to force gcc to blackhole registers so that things maybe garbage collected?
  • From: Hamad Ahmed <ahmed90@xxxxxxxxxx>
• Re: Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Antw: Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241
  • From: "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
• Re: Re: GCC 4.8.5 No default memory alignment number
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Optimize shared libraries with PGO or AutoFDO?
  • From: "Sven C. Dack" <sdack@xxxxxxx>
• Re: rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Re: rdrand generated with march=winchip-c6 in systemd-241
  • From: Florian Weimer <fw@xxxxxxxxxxxxx>
• Re: Re: GCC 4.8.5 No default memory alignment number
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• Re: GCC 4.8.5 No default memory alignment number
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• GCC 4.8.5 No default memory alignment number
  • From: 郭文峰（Gerald Kwok） <18192648006@xxxxxxx>
• Re: GNU C for Windows and blind user!
  • From: Philip Bennefall <philip@xxxxxxxxxxxx>
• GNU C for Windows and blind user!
  • From: Pierre Gaumond <pierregaumond1946@xxxxxxxxx>
• Optimize shared libraries with PGO or AutoFDO?
  • From: Pinku Surana <suranap@xxxxxxxxx>
• Re: Measuring test coverage of GSL with GCOV
  • From: Junchao Zhang <junchao.zhang@xxxxxxxxx>
• Measuring test coverage of GSL with GCOV
  • From: "Z." <zell08v@xxxxxxxxx>
• RE: GCC 8.3.0 build fails on Cray systems with an older "/usr/include/sys/sdt.h" version
  • From: "Oppe, Thomas C ERDC-RDE-ITL-MS Contractor via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: GCC 8.3.0 build fails on Cray systems with an older "/usr/include/sys/sdt.h" version
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: GCC 8.3.0 build fails on Cray systems with an older "/usr/include/sys/sdt.h" version
  • From: Bill Long <longb@xxxxxxxx>
• Re: GCC 8.3.0 build fails on Cray systems with an older "/usr/include/sys/sdt.h" version
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• RE: GCC 8.3.0 build fails on Cray systems with an older "/usr/include/sys/sdt.h" version
  • From: "Oppe, Thomas C ERDC-RDE-ITL-MS Contractor via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: rdrand generated with march=winchip-c6 in systemd-241
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Re: rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Re: rdrand generated with march=winchip-c6 in systemd-241
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• Re: rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Re: rdrand generated with march=winchip-c6 in systemd-241
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• rdrand generated with march=winchip-c6 in systemd-241
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Determining maximum vector length supported by the CPU?
  • From: Martin Reinecke <martin@xxxxxxxxxxxxxxxxxxx>
• Re: Downloading Fortran F95
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Downloading Fortran F95
  • From: Thomas Flynn <t.a.flynn7@xxxxxxxxx>
• gcov file locking in parallel usage
  • From: Junchao Zhang <junchao.zhang@xxxxxxxxx>
• Re: C11, <stdatomic.h> and atomic pointers
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: C11, <stdatomic.h> and atomic pointers
  • From: Martin Sebor <msebor@xxxxxxxxx>
• C11, <stdatomic.h> and atomic pointers
  • From: Chris Hall <chris.hall@xxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jason Mancini <jayrusman@xxxxxxxxxxx>
• Enabling precompiled headers leads to warning
  • From: Paul Smith <paul@xxxxxxxxxxxxxxxxx>
• Re: avr-g++: __gcc_isr not supported
  • From: Georg-Johann Lay <gjl@xxxxxxxxxxx>
• Linker issue with long variable names
  • From: Bob OBrien <Bob.OBrien@xxxxxxxxxxxxx>
• RE: how to build shared library link to a static library
  • From: "Poe, Daryl (Thin Clients)" <daryl.poe@xxxxxx>
• RE: how to build shared library link to a static library
  • From: "Wu, Wendy" <jian.wu3@xxxxxx>
• Re: how to build shared library link to a static library
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• how to build shared library link to a static library
  • From: "Wu, Wendy" <jian.wu3@xxxxxx>
• Re: Suppressing GCC warning locally inside a macro
  • From: "U.Mutlu" <um@xxxxxxxxxxx>
• Re: Suppressing GCC warning locally inside a macro
  • From: "U.Mutlu" <um@xxxxxxxxxxx>
• Re: Suppressing GCC warning locally inside a macro
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Suppressing GCC warning locally inside a macro
  • From: "U.Mutlu" <um@xxxxxxxxxxx>
• Re: Suppressing GCC warning locally inside a macro
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Ambiguous -mtune=atom documentation
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Error: Blank required in STOP statement near (1)
  • From: Jonatan Öström <jonatan.ostrom@xxxxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jason Mancini <jayrusman@xxxxxxxxxxx>
• code: bitsizeof() and bitoffsetof()
  • From: "U.Mutlu" <um@xxxxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jason Mancini <jayrusman@xxxxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jason Mancini <jayrusman@xxxxxxxxxxx>
• Suppressing GCC warning locally inside a macro
  • From: "U.Mutlu" <um@xxxxxxxxxxx>
• -Wformat-signedness silently ignored if no -Wformat
  • From: Jonny Grant <jg@xxxxxxxx>
• Ambiguous -mtune=atom documentation
  • From: tedheadster <tedheadster@xxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jason Mancini <jayrusman@xxxxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jason Mancini <jayrusman@xxxxxxxxxxx>
• RE: _Float16 support
  • From: Tamar Christina <Tamar.Christina@xxxxxxx>
• Re: _Float16 support
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• RE: _Float16 support
  • From: Tamar Christina <Tamar.Christina@xxxxxxx>
• Re: _Float16 support
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• _Float16 support
  • From: Tamar Christina <Tamar.Christina@xxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: bootstrapping snapshot 20190414 with -O3 fails
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• Re: gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jason Mancini <jayrusman@xxxxxxxxxxx>
• gcc9 snapshot 20190414 is 30x slower than gcc 6.3
  • From: Jason Mancini <jayrusman@xxxxxxxxxxx>
• bootstrapping snapshot 20190414 with -O3 fails
  • From: Jason Mancini <jayrusman@xxxxxxxxxxx>
• Re: prevent GCC from re-arranging two emit_insn()
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: Linux ppc64 - compatibility-ldbl.o can't find std::num_put
  • From: Peter Bergner <bergner@xxxxxxxxxxxxx>
• Linux ppc64 - compatibility-ldbl.o can't find std::num_put
  • From: Brian Groose <bgroose@xxxxxxxxx>
• Re: prevent GCC from re-arranging two emit_insn()
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: prevent GCC from re-arranging two emit_insn()
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: prevent GCC from re-arranging two emit_insn()
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: prevent GCC from re-arranging two emit_insn()
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: prevent GCC from re-arranging two emit_insn()
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: prevent GCC from re-arranging two emit_insn()
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: "graham stott via gcc-help" <gcc-help@xxxxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: phi gcc <phi.gcc@xxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: phi gcc <phi.gcc@xxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: phi gcc <phi.gcc@xxxxxxxxx>
• prevent GCC from re-arranging two emit_insn()
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: Martin Sebor <msebor@xxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: Martin Sebor <msebor@xxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: regarding df_regs_ever_live_p
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• Re: built-in function 'exp' declared as non-function
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• built-in function 'exp' declared as non-function
  • From: phi gcc <phi.gcc@xxxxxxxxx>
• Re: regarding df_regs_ever_live_p
  • From: Richard Earnshaw <Richard.Earnshaw@xxxxxxxxxxxx>
• Re: regarding df_regs_ever_live_p
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: regarding df_regs_ever_live_p
  • From: Jeff Law <law@xxxxxxxxxx>
• Re: gcc cross-compiler is using the wrong assembler
  • From: Jim Wilson <jimw@xxxxxxxxxx>
• gcc cross-compiler is using the wrong assembler
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: Issue with webpage
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Reverse order diagnostics
  • From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
• Re: Reverse order diagnostics
  • From: LRN <lrn1986@xxxxxxxxx>
• Re: regarding df_regs_ever_live_p
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• function alignment for AMD Bulldozer/Piledriver
  • From: "Sven C. Dack" <sdack@xxxxxxx>
• how to pass -save-temps to xgcc during build
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• gcc 8.3.0 compiling
  • From: James Dalton <jamesdalton831@xxxxxxxxxxx>
• Re: regarding df_regs_ever_live_p
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: regarding df_regs_ever_live_p
  • From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
• regarding df_regs_ever_live_p
  • From: William Tambe <tambewilliam@xxxxxxxxx>
• Re: CODE_LABEL vs LABEL_REF
  • From: Jeff Law <law@xxxxxxxxxx>