Re: assembler errors when bootstrapping with #pragma optimize "0"
On Thu, Oct 21, 2021 at 8:06 PM Martin Sebor via Gcc wrote: > I put #pragma GCC optimize "0" at the top of gimplify.c to help > me debug something in a bootstrapped compiler. The file failed > to compile with many assembler errors like this: > > /tmp/ccL9zcXD.s: Assembler messages: > /tmp/ccL9zcXD.s:9: Error: CFI instruction used without previous > .cfi_startproc > > I've done this before and had no problems. Is this supposed to > work or was I just lucky when it did before? > I know the binutils people have been doing work with CFI stuff, so perhaps this is a binutils issue? Which version of binutils are you using? A newer version of binutils (or perhaps older) might make a difference. Regards, Tom
Status of PDB support
Hi, I know that PDB support has been worked on in binutils. I thinkt he missing piece is to get GCC to emit CodeView debug information that binutils will turn into a PDBm (not sure if the work is complete in binutils, either). What's the status of this? I ask because our WIndows offering is built with MSVC for C and C++, but a MinGW-w64 built GCC for Ada compilation. Having GCC + binutils generate PDB information would enable us to use Visual Studio for one stop debugging. As it is we have to use gdb for Ada code (DWARF debug symbols) and Visual Studio C/C++ debugging (because PDB), which is a pain. Thanks, Tom
Re: aarch64 built-in SIMD types
On Tue, Feb 25, 2025 at 8:19 AM Tom Kacvinsky wrote: > Hi Kyrylo, > > On Tue, Feb 25, 2025 at 4:01 AM Kyrylo Tkachov > wrote: > > > On 24 Feb 2025, at 20:40, Tom Kacvinsky via Gcc wrote: >> > >> > I am trying to find where the aarch64 SIMD built in types are defined in >> > GCC. >> > For instance, __Int8x8_t. I see some code in gcc/config/aarch64 for >> these, >> > but >> > then it goes deeper into internals of gcc that I don't quite follow. >> > >> > Any help pointing to where I should look would be appreciated. >> > >> >> The logic for defining them is in aarch64-builtins.cc . The information >> about them is tracked in aarch64_simd_type_info structs. >> There’s some preprocessor machinery at work so it may not be obvious how >> it works from a first read. >> There are user-level typedefs in arm_private_neon_types.h that is later >> included standard ACLE headers like arm_neon.h and arm_sve.h >> What particular information are you looking for? >> > > I have been playing around with a front end that doesn't have these types > defined so I was looking > to see how they were defined by GCC so I could add them with something > similar to GCC's -include > option. > I realized it doesn't matter if I get the front end to match up the built-in aarch64 types, it will generate code that will eventually barf when compiled because of "conflicting" typedefs from the generated code and the built-in typedefs from GCC. It was worth a shot, though. Thanks for the help - I was able to follow along the basic gist of the code by expanding the macros using -E instead of -c for the compile commands. Tom
aarch64 built-in SIMD types
Hi all, I am trying to find where the aarch64 SIMD built in types are defined in GCC. For instance, __Int8x8_t. I see some code in gcc/config/aarch64 for these, but then it goes deeper into internals of gcc that I don't quite follow. Any help pointing to where I should look would be appreciated. Thanks, Tom
Re: aarch64 built-in SIMD types
Hi Kyrylo, On Tue, Feb 25, 2025 at 4:01 AM Kyrylo Tkachov wrote: > On 24 Feb 2025, at 20:40, Tom Kacvinsky via Gcc wrote: > > > > I am trying to find where the aarch64 SIMD built in types are defined in > > GCC. > > For instance, __Int8x8_t. I see some code in gcc/config/aarch64 for > these, > > but > > then it goes deeper into internals of gcc that I don't quite follow. > > > > Any help pointing to where I should look would be appreciated. > > > > The logic for defining them is in aarch64-builtins.cc . The information > about them is tracked in aarch64_simd_type_info structs. > There’s some preprocessor machinery at work so it may not be obvious how > it works from a first read. > There are user-level typedefs in arm_private_neon_types.h that is later > included standard ACLE headers like arm_neon.h and arm_sve.h > What particular information are you looking for? > I have been playing around with a front end that doesn't have these types defined so I was looking to see how they were defined by GCC so I could add them with something similar to GCC's -include option. Tom
