Re: GCC 11.5 Released
Unsubscribe me please, Thanks Sent from my iPhone > On 19 Jul 2024, at 07:37, Richard Biener via gcc-announce > wrote: > > The GNU Compiler Collection version 11.5 has been released. > > GCC 11.5 is a bug-fix release from the GCC 11 branch > containing important fixes for regressions and serious bugs in > GCC 11.4 with more than 157 bugs fixed since the previous release. > > This is also the last release from the GCC 11 branch, GCC continues > to be maintained on the GCC 12, GCC 13 and GCC 14 branches and the > development trunk. > > This release is available from the FTP servers listed here: > > https://gcc.gnu.org/pub/gcc/releases/gcc-11.5.0/ > https://gcc.gnu.org/mirrors.html > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually!
GCC 11.5 Released
The GNU Compiler Collection version 11.5 has been released. GCC 11.5 is a bug-fix release from the GCC 11 branch containing important fixes for regressions and serious bugs in GCC 11.4 with more than 157 bugs fixed since the previous release. This is also the last release from the GCC 11 branch, GCC continues to be maintained on the GCC 12, GCC 13 and GCC 14 branches and the development trunk. This release is available from the FTP servers listed here: https://gcc.gnu.org/pub/gcc/releases/gcc-11.5.0/ https://gcc.gnu.org/mirrors.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
Re: GCC 11.5 Released
please unsubscribe me, thanks Op vr 19 jul 2024 om 08:40 schreef Richard Biener via gcc-announce < gcc-annou...@gcc.gnu.org>: > The GNU Compiler Collection version 11.5 has been released. > > GCC 11.5 is a bug-fix release from the GCC 11 branch > containing important fixes for regressions and serious bugs in > GCC 11.4 with more than 157 bugs fixed since the previous release. > > This is also the last release from the GCC 11 branch, GCC continues > to be maintained on the GCC 12, GCC 13 and GCC 14 branches and the > development trunk. > > This release is available from the FTP servers listed here: > > https://gcc.gnu.org/pub/gcc/releases/gcc-11.5.0/ > https://gcc.gnu.org/mirrors.html > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually! >
gcc-13-20240719 is now available
Snapshot gcc-13-20240719 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20240719/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision 953bf37690d22de956d75c6aef7a9690ad55b9a7 You'll find: gcc-13-20240719.tar.xz Complete GCC SHA256=fab70e6ee4f481d10f0e85cb7256d968f3c5f927ec95dc29f491ca906b1498b7 SHA1=fd4be0c11e4404bd554251f44e997a0c5ae2967e Diffs from 13-20240712 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: DW_TAG_compile_unit's references to .debug_line and .loc directive extension
On Thu, Jul 4, 2024 at 12:42 PM Fangrui Song wrote:
>
> I have noticed that Meta Platforms folks have a proposal to extend the
> .loc directive
> https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608
> .
> I filed https://sourceware.org/bugzilla/show_bug.cgi?id=31955 ("gas:
> Extend .loc directive to emit a label") and am sending this message in
> case there are interest/opinions.
>
> For your convenience, the gas documentation is at
> https://sourceware.org/binutils/docs/as/Loc.html
>
> > The .loc directive will add a row to the .debug_line line number matrix
> > corresponding to the immediately following assembly instruction.
>
> Here is my summary of their proposal:
>
> Clang will add a new debug mode to emit a DW_AT_LLVM_stmt_sequence
> attribute to each DW_TAG_subprogram DIE, referencing the start of a
> line number program sequence associated with the subprogram.
> (https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434)
>
> ```
> main:
> .loc 0 1 13 debug_line_label .Lmain_line_entries
> ...
>
> .section .debug_info,"",@progbits
> ...
> .byte 1 # Abbrev [1] 0xc:0x78
> DW_TAG_compile_unit
> .long .Lline_table_start0 # DW_AT_stmt_list
> ...
>
> .byte 14 # Abbrev [14]
> DW_TAG_subprogram
> ...
> .long .Lmain_line_entries - .Lline_table_start0#
> DW_AT_LLVM_stmt_sequence
>
> .section.debug_line,"",@progbits # generated
> .Lline_table_start0:
> # Conceptually, the .Lmain_line_entries label is emitted at start of a
> line number program sequence associated with `main`
> ```
>
> Advantages.
>
> *Faster symbolization*
>
> Traditional address symbolization involves locating the
> DW_TAG_compile_unit DIE and parsing the line number program from the
> DW_AT_stmt_list offset.
> This process requires skipping unrelated DW_TAG_subprogram DIEs. The
> DW_AT_LLVM_stmt_sequence attribute directly points to the relevant
> line number program sequence, eliminating unnecessary steps.
>
> *Improved ICF disambiguating*
>
> Identical Code Folding (ICF) can make two line number program
> sequences (associated with folded subprograms) indistinguishable.
> While DW_AT_LLVM_stmt_sequence doesn't resolve this, it identifies the
> associated function. If the caller is known, this additional
> information could help disambiguate the correct sequence.
>
> ---
>
> ELF/COFF -fno-function-sections and Mach-O .subsections_via_symbols
> allow consecutive functions to share the same line number program
> sequence.
> To utilize DW_AT_LLVM_stmt_sequence better, the sequences should be
> split to resemble ELF/COFF -ffunction-sections.
>
> Mach-O doesn't have -ffunction-sections -fno-function-sections
> differences and normally needs very few relocations for .debug_line
> and the new mode will introduce more like ELF/COFF
> -ffunction-sections.
Heads-up: they have created a patch to add the .loc_label assembler
directive https://github.com/llvm/llvm-project/pull/99710 .
.cfi_label is existing, so .loc_label looks reasonable.
