Re: Does gcc have different inlining heuristics on different platforms?

Hi, sorry for bumping this again I forgot to mention that Windows inlining, from what I remember, was ok before gcc 14 landed. It seemed that only once gcc 14 came about that the insane inlining started happening. This might point to the inlining heuristics having changed, but unfortunately gcc 13

Re: Compiler support for forbidding certain methods from being called

Hi Jonathan, Thanks for the suggestion, it seems promising. I switched out the error attribute for the warning attribute at first, since they should be equivalent except warning just warns instead of erroring. This results in the link step failing if LTO is enabled for some reason though. I then c

Re: Compiler support for forbidding certain methods from being called

Jonathan Wakely wrote: > > On Mon, 14 Apr 2025 at 10:11, Julian Waters via Gcc wrote: > > > > Hi all, > > > > A codebase I'm working with has decided that poisoning certain > > standard library functions is necessary, as it explicitly does not use > &

Compiler support for forbidding certain methods from being called

Hi all, A codebase I'm working with has decided that poisoning certain standard library functions is necessary, as it explicitly does not use those functions unless absolutely necessary for its own reasons (This was not my decision to make). As such, we've been looking into ways to implement that.

Re: Does gcc have different inlining heuristics on different platforms?

p to speed if I could, but I don't even know where to start or look :( best regards, Julian On Mon, Mar 31, 2025 at 8:09 PM Richard Biener wrote: > > On Mon, Mar 31, 2025 at 1:20 PM Julian Waters via Gcc wrote: > > > > Hi all, > > > > I've been trying to ch

Does gcc have different inlining heuristics on different platforms?

Hi all, I've been trying to chase down an issue that's been driving me insane for a while now. It has to do with the flatten attribute being combined with LTO. I've heard that flatten and LTO are a match made in hell (Someone else's words, not mine), but from what I observe, several methods marked

Help with a RTL manipulation

Hi all, I currently have the following RTL patch to TLS handling code on hand, but am having major trouble understanding it: +#if TARGET_WIN32_TLS + rtx scratch = gen_rtx_SCRATCH (Pmode); + + rtx basereg = gen_reg_rtx (Pmode); + rtx thread = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, const0_rtx), UN

Re: How to implement Native TLS for a specific platform?

ere __tls_get_addr is a function provided by the OS which will >> return the address of variable x in r0 (return reg). You should >> already have the PLT reloc, and you need to implement the TLS_GD_GOT >> reloc to GOT table. In GOT table you need additionally two relocs: >> GOT[n]

Re: How to implement Native TLS for a specific platform?

turn the address of variable x in r0 (return reg). You should > already have the PLT reloc, and you need to implement the TLS_GD_GOT > reloc to GOT table. In GOT table you need additionally two relocs: > GOT[n] R_ARC_TLS_DTPMOD x > GOT[n+1] R_ARC_TLS_DTPOFF x > > I

Re: How to implement Native TLS for a specific platform?

ches. Of course, there are different ways >> to implement TLS, in ARC is the simplest solution. Also, u need to >> hack the assembler, linker and the OS for a full implementation. >> >> Cheers, >> Claudiu >> >> On Tue, Jul 9, 2024 at 7:14 PM Julian Waters v

Re: How to implement Native TLS for a specific platform?

ok in arc.cc and search for TLS, also use git > blame to see the original patches. Of course, there are different ways > to implement TLS, in ARC is the simplest solution. Also, u need to > hack the assembler, linker and the OS for a full implementation. > > Cheers, > Claudiu > &g

How to implement Native TLS for a specific platform?

Hi all, I'm currently trying to implement Native TLS on a platform that gcc uses emutls for at the moment, but I can't seem to figure out where and how to implement it. I have a rough idea of the assembly required for TLS on this platform, but I don't know where to plug it in to the compiler to ma

Re: About gsoc

Hello again, Dave. Have you managed to learn how a basic language Interpreter works before commenting on the significantly-more-complex gcc's efficiency? Or were you not able to because your IQ is below the freezing point of water and you can't even understand what a basic tree walker is? Then aga

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

What about removing the _gcov_fork object file from the list of object files in Makefile.in (Named LIBGCOV_INTERFACE last I remember) if the target doesn't support fork? Seems cleaner in my opinion. best regards, Julian

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

I think the most reasonable thing to do is to remove _gcov_fork from LIBGCOV_INTERFACE in libgcc's Makefile.in when the target is Windows. best regards, Julian

[PATCH] C++: Introduce the extended attribute for asm declarations

Hi all, This is the beginning of a patch to introduce the extended attribute for asm declarations proposed in https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636563.html. I will need some reviewer help in implementing this patch, as I am not very familiar with gcc's internals. The attribu

[RFC] Structured Exception Handling support for Windows

gcc's assembler has had support for Windows style Structured Exception Handling for a while now, it would be useful if gcc itself had support for catching hardware faults on Windows through this mechanism as well (For example, the Java HotSpot VM will simply not work on Windows without support for

[PING][PATCH v2] Add clang's invalid-noreturn warning

Hi all, Sorry for sending the ping here, but gcc-patches seems to be completely overwhelmed and my patch keeps getting buried Cheers, https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627913.html best regards, Julian

Add clang's invalid-noreturn warning flag

Please review a patch to add clang's invalid-noreturn flag to toggle noreturn warnings. This patch keeps the old behaviour of always warning on every noreturn violation, but unlike clang also adds an extra layer of fine tuning by turning invalid-noreturn into a warning with levels, where level 1 w

Re: Warning specifically for a returning noreturn

I see. I think it may be appropriate to adopt what clang has done and have one -Winvalid-noreturn for both cases, thoughts? On Fri, Jul 21, 2023 at 5:43 PM Jonathan Wakely wrote: > On Fri, 21 Jul 2023 at 04:28, Julian Waters via Gcc > wrote: > > > > Hi all, > > &

Re: Warning specifically for a returning noreturn

rtunately not the one who wrote the code that way; I'm merely a build > systems developer trying to get it to work with gcc :/ > > best regards, > Julian > > On Wed, 5 Jul 2023, 19:26 Jonathan Wakely, wrote: > >> On Wed, 5 Jul 2023 at 12:01, Julian Waters via Gcc >

ms_printf format attribute should be ISO compliant for ucrt linked gcc

Hi all, Is there a way to make the format attribute when passed ms_printf recognise ISO C99 and above format specifiers? Currently on Windows gcc always assumes that printf doesn't recognise specifiers such as %z and %T for strftime, but for gcc that links against the newer C Runtime from Microsof

Re: Warning specifically for a returning noreturn

th gcc :/ best regards, Julian On Wed, 5 Jul 2023, 19:26 Jonathan Wakely, wrote: > On Wed, 5 Jul 2023 at 12:01, Julian Waters via Gcc > wrote: > > > > I see, thanks Andrew. > > > > Anyone else have opinions on this besides Liu or Andrew? The responses > have &

Re: Warning specifically for a returning noreturn

ense for a noreturn function to have a return type > other than void. > ``` > > Thanks, > Andrew Pinski > > > > > > best regards. > > Julian > > > > On Wed, Jul 5, 2023 at 9:07 AM Andrew Pinski wrote: > >> > >> On Tue, Jul 4, 2023 at

Re: Warning specifically for a returning noreturn

too? best regards. Julian On Wed, Jul 5, 2023 at 9:07 AM Andrew Pinski wrote: > On Tue, Jul 4, 2023 at 5:54 PM Julian Waters via Gcc > wrote: > > > > Hi all, > > > > Currently to disable the warning that a noreturn method does return, it's > > required

Warning specifically for a returning noreturn

Hi all, Currently to disable the warning that a noreturn method does return, it's required to disable warnings entirely. This can be very inconvenient when -Werror is enabled with a noreturn method that isn't specifically calling something like std::abort() at the end, when one wants all other -Wa

Re: [PATCH] Basic asm blocks should always be volatile

Hi Michael, I'm on gcc 13.1 compiling for Windows x64, with the MinGW UCRT64 runtime library best regards, Julian On Thu, Jun 29, 2023 at 9:27 PM Michael Matz wrote: > Hello, > > On Thu, 29 Jun 2023, Julian Waters via Gcc wrote: > > > int main() { > > asm

Re: [PATCH] Basic asm blocks should always be volatile

vailable to stress test the possible bug, -O3, -ffunction-sections -fdata-sections -Wl,--gc-sections -flto=auto. Compiled as C++17 and intel assembly syntax best regards, Julian On Thu, Jun 29, 2023 at 2:46 AM Andrew Pinski wrote: > On Wed, Jun 28, 2023 at 8:04 AM Michael Matz wrote: > &

Re: [PATCH] Basic asm blocks should always be volatile

t; { > > std::printf("Exception\n"); > > } > > > > asm ("5:"); > > > > In any case I doubt marking it as volatile in the parser hurts either, > since this is the behaviour it's supposed to have > > > > best regard

Re: [PATCH] Basic asm blocks should always be volatile

gt; On Tue, Jun 27, 2023 at 9:15 AM Julian Waters > wrote: > > > > Hi Andrew, > > > > That can't be right, on my system a test of asm vs asm volatile with -O3 > and -flto=auto yields very different results, with only the latter being > correct. The patch fixe

Re: [PATCH] Basic asm blocks should always be volatile

only the latter being > correct. The patch fixed it and caused gcc to emit correct assembly > > best regards, > Julian > > On Wed, Jun 28, 2023 at 12:08 AM Andrew Pinski wrote: > >> On Tue, Jun 27, 2023 at 9:03 AM Julian Waters via Gcc >> wrote: >> > >>

Re: [PATCH] Basic asm blocks should always be volatile

inski wrote: > On Tue, Jun 27, 2023 at 9:03 AM Julian Waters via Gcc > wrote: > > > > gcc's documentatation mentions that all basic asm blocks are always > volatile, > > yet the parser fails to account for this by only ever setting > > volatile_p to true > &g

Re: [PATCH] Basic asm blocks should always be volatile

My apologies, I sent this to the wrong list. I have already resent it to the correct one regards, Julian

[PATCH] Basic asm blocks should always be volatile

gcc's documentatation mentions that all basic asm blocks are always volatile, yet the parser fails to account for this by only ever setting volatile_p to true if the volatile qualifier is found. This patch fixes this by adding a special case check for extended_p before finish_asm_statement is calle

Applying extended assembly parsing to basic asm

Hi all, Would it be acceptable for a changeset that applies the parsing of string literals in extended assembly blocks to the assembly templates inside basic asm to be mailed here? As I see it, there is no reason to keep this behaviour from basic asm statements and it can prove to be very useful,

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

It's alright Gabriel, pay this intellectually challenged individual no mind. It's clear that, unlike Stefan, who at the very least knows how to disassemble native code and understands what the instruction sequences mean (even though the way he goes about it is flat out wrong), this retard doesn't k

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

gcc -O0 -c -mabm -mbmi retard.c -o retard.o ^ | | | int code(unsigned long long number) { return (int) _tzcnt_u64(number); } objdump --disassemble-all retard.o : 0: 55 push %rbp 1: 48 89 e5

Re: Another epic optimiser failure

e the rest of your post after using that criticism against me initially, how ironic. "Ever heard the saying "if you can't run with the big dogs, stay under the porch"?" You think you're one of the big dogs? Pffft, that's cute. I have no interest in getting

Re: Another epic optimiser failure

Man, these clang fanboys sure are getting out of hand I feel like all this garbage can be easily resolved by y'all showing this idiot the exact proper options required and attaching the resulting compiled assembly exactly as he wants it, or if gcc doesn't compile the exact assembly he wants, expla

Where is the libtool compiler lib search path generated from?

Currently I have a libtool that looks something like this: # The library search path used internally by the compiler when linking # a shared library. compiler_lib_search_path="-LD:/Eclipse/Workspace/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/x86_64-w64-mingw32/libstdc++-v3/src -LD:/Eclipse/Work

Re: gcc with the new WIN32 threads fails to compile libstdc++

.libs/libstdc++.dll.a On Mon, Apr 10, 2023 at 3:21 PM Andrew Pinski wrote: > On Mon, Apr 10, 2023 at 12:16 AM Julian Waters via Gcc > wrote: > > > > Hi all, > > > > When trying to compile gcc with the revamped WIN32 threading model which > > supports C++11 thr

gcc with the new WIN32 threads fails to compile libstdc++

Hi all, When trying to compile gcc with the revamped WIN32 threading model which supports C++11 threads, libstdc++ always fails to link with the following error: C:\msys64\ucrt64\x86_64-w64-mingw32\bin\ld.exe: ../src/c++11/.libs/libc++11convenience.a(thread.o): in function `__gthread_join': D:/Ec

Linker removal of trampolines on Microsoft Windows targets

Hi all, Microsoft's Visual C++ compiler has the ability to remove trampolines generated by the linker (which ultimately calls __imp_SymbolName from the DLL import address table) when linking with code that is intended to be loaded from a DLL if link time optimization on their compiler was specifie