Re: How to compress the size of a field in a structure?

2024-01-15 Thread Richard Biener via Gcc
On Sat, Jan 13, 2024 at 8:46 AM Hanke Zhang via Gcc wrote: > > Hi, I'm attempting to compress the size of a field in a structure for > memory-friendly purposes. I created an IPA pass to achieve this, but I > ran into some issues as follows: > > // original > struct Foo { > long a1; > int a2; >

Why is -ffold-mem-offsets a target option?

2024-01-15 Thread Georg-Johann Lay
Just noticed that -ffold-mem-offsets is a target option, i.e. it is shown with --help=target > grep -A3 mem-off common.opt ffold-mem-offsets Target Bool Var(flag_fold_mem_offsets) Init(1) Fold instructions calculating memory offsets to the memory access instruction if possible. Is that "Target

Re: Why is -ffold-mem-offsets a target option?

2024-01-15 Thread Richard Biener via Gcc
On Mon, Jan 15, 2024 at 11:22 AM Georg-Johann Lay wrote: > > Just noticed that -ffold-mem-offsets is a target option, i.e. it is > shown with --help=target > > > grep -A3 mem-off common.opt > ffold-mem-offsets > Target Bool Var(flag_fold_mem_offsets) Init(1) > Fold instructions calculating memory

Re: New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Szabolcs Nagy via Gcc
The 01/13/2024 13:49, Florian Weimer wrote: > This commit > > commit 8abddb187b33480d8827f44ec655f45734a1749d > Author: Andrew Burgess > Date: Sat Aug 5 14:31:06 2023 +0200 > > libgcc: support heap-based trampolines > > Add support for heap-based trampolines on x86_64-linux, aarch

Re: Why is -ffold-mem-offsets a target option?

2024-01-15 Thread Georg-Johann Lay
Am 15.01.24 um 13:20 schrieb Richard Biener: On Mon, Jan 15, 2024 at 11:22 AM Georg-Johann Lay wrote: Just noticed that -ffold-mem-offsets is a target option, i.e. it is shown with --help=target > grep -A3 mem-off common.opt ffold-mem-offsets Target Bool Var(flag_fold_mem_offsets) Init(1

Re: New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Adhemerval Zanella Netto via Gcc
On 15/01/24 09:46, Szabolcs Nagy wrote: > The 01/13/2024 13:49, Florian Weimer wrote: >> This commit >> >> commit 8abddb187b33480d8827f44ec655f45734a1749d >> Author: Andrew Burgess >> Date: Sat Aug 5 14:31:06 2023 +0200 >> >> libgcc: support heap-based trampolines >> >> Add suppo

Office Hours for the GNU Toolchain on 2024-01-25 at 11am EST5EDT.

2024-01-15 Thread Carlos O'Donell via Gcc
Office Hours for the GNU Toolchain on 2024-01-25 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

Re: New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Carlos O'Donell via Gcc
On 1/15/24 08:55, Adhemerval Zanella Netto wrote: > > > On 15/01/24 09:46, Szabolcs Nagy wrote: >> The 01/13/2024 13:49, Florian Weimer wrote: >>> This commit >>> >>> commit 8abddb187b33480d8827f44ec655f45734a1749d >>> Author: Andrew Burgess >>> Date: Sat Aug 5 14:31:06 2023 +0200 >>> >>>

Re: New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Florian Weimer via Gcc
* Carlos O'Donell: > I agree. TLS should be seen more like .bss/.data rather than something > that is allocated with malloc(). There wasn't consensus regarding this in 2014. See below. > If we leak memory via TLS that is a glibc bug that we can deal with, This is something that libgcc_s.so.1 d

Re: New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Iain Sandoe
> On 15 Jan 2024, at 15:35, Florian Weimer wrote: > > * Carlos O'Donell: > >> I agree. TLS should be seen more like .bss/.data rather than something >> that is allocated with malloc(). > > There wasn't consensus regarding this in 2014. See below. > >> If we leak memory via TLS that is a gl

Re: New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Joseph Myers via Gcc
On Mon, 15 Jan 2024, Florian Weimer via Gcc wrote: > The change conflated multiple issues: sanitizer support, > async-signal-safe TLS access, and eager allocation of all TLS-related > memory, so that subsequent accesses cannot fail. My impression was the > main point of contention was eager alloc

Re: New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Florian Weimer via Gcc
* Iain Sandoe: >> On 15 Jan 2024, at 15:35, Florian Weimer wrote: >> >> * Carlos O'Donell: >> >>> I agree. TLS should be seen more like .bss/.data rather than something >>> that is allocated with malloc(). >> >> There wasn't consensus regarding this in 2014. See below. >> >>> If we leak memo

GCC GSoC 2024: Call for project ideas and mentors

2024-01-15 Thread Martin Jambor
Hello, another year has passed, Google has announced there will be again Google Summer of Code (GsoC) in 2024 and the deadline for organizations to apply is already approaching (February 6th). I'd like to volunteer to be the main org-admin for GCC again but let me know if you think I shouldn't or

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Mathieu Desnoyers via Gcc
On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote: This commit commit 8abddb187b33480d8827f44ec655f45734a1749d Author: Andrew Burgess Date: Sat Aug 5 14:31:06 2023 +0200 libgcc: support heap-based trampolines Add support for heap-based trampolines on x86_64-linux, aarch

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Florian Weimer via Gcc
* Mathieu Desnoyers: > On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote: >> This commit >> commit 8abddb187b33480d8827f44ec655f45734a1749d >> Author: Andrew Burgess >> Date: Sat Aug 5 14:31:06 2023 +0200 >> libgcc: support heap-based trampolines >> Add support for heap-bas

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Mathieu Desnoyers via Gcc
On 2024-01-15 14:42, Florian Weimer wrote: * Mathieu Desnoyers: [...] General use of lttng should be fine, I think, only the malloc wrapper has this problem. The purpose of the nesting counter TLS variable in the malloc wrapper is to catch situations like this where a global-dynamic TLS acc