Re: Enum processor_features adding on i386 backend
On Tue, Jul 18, 2023 at 7:50 PM Jiang, Haochen via Gcc wrote: > > Hi all, > > As you all know that we are continuously working on new ISA implementation > for i386 backend. > > There is one thing that I am really curious about when I read the code. > > In gcc/config/i386/i386-cpuinfo.h, we have such comment: > > /* ISA Features supported. New features have to be inserted at the end. */ > > Why new features have to be inserted at the end? I did a quick investigation > and found that it was > added at this mailing thread originally at libgcc/config/i386/cpuinfo.c: > > https://gcc.gnu.org/pipermail/gcc-patches/2015-September/428915.html > > In the thread, it seems that it might cause unwanted ABI change. Could anyone > kindly tell me something > more about that? Should this rule still be kept for now after about eight > years since then? YES we should keep it. ___builtin_cpu_supports uses those #s so the ABI is exposed to the object level even if those #s are not exposed to the user directly those are still exposed as an ABI that needs to be expandable that way. Thanks, Andrew > > Thx, > Haochen >
Enum processor_features adding on i386 backend
Hi all, As you all know that we are continuously working on new ISA implementation for i386 backend. There is one thing that I am really curious about when I read the code. In gcc/config/i386/i386-cpuinfo.h, we have such comment: /* ISA Features supported. New features have to be inserted at the end. */ Why new features have to be inserted at the end? I did a quick investigation and found that it was added at this mailing thread originally at libgcc/config/i386/cpuinfo.c: https://gcc.gnu.org/pipermail/gcc-patches/2015-September/428915.html In the thread, it seems that it might cause unwanted ABI change. Could anyone kindly tell me something more about that? Should this rule still be kept for now after about eight years since then? Thx, Haochen
Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies
On Tue, Jul 18, 2023 at 16:52:44 -0400, Jason Merrill wrote: > On 6/25/23 12:36, Ben Boeckel wrote: > > On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote: > >> On 6/22/23 22:45, Ben Boeckel wrote: > >>> On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote: > On 1/25/23 16:06, Ben Boeckel wrote: > > They affect the build, so report them via `-MF` mechanisms. > > Why isn't this covered by the existing code in preprocessed_module? > >>> > >>> It appears as though it is neutered in patch 3 where > >>> `write_make_modules_deps` is used in `make_write` (or will use that name > >> > >> Why do you want to record the transitive modules? I would expect just > >> noting the > >> ones with imports directly in the TU would suffice (i.e check the > >> 'outermost' arg) > > > > FWIW, only GCC has "fat" modules. MSVC and Clang both require the > > transitive closure to be passed. The idea there is to minimize the size > > of individual module files. > > > > If GCC only reads the "fat" modules, then only those should be recorded. > > If it reads other modules, they should be recorded as well. For clarification, given: * a.cppm ``` export module a; ``` * b.cppm ``` export module b; import a; ``` * use.cppm ``` import b; ``` in a "fat" module setup, `use.cppm` only needs to be told about `b.cmi` because it contains everything that an importer needs to know about the `a` module (reachable types, re-exported bits, whatever). With the "thin" modules, `a.cmi` must be specified when compiling `use.cppm` to satisfy anything that may be required transitively (e.g., a return type of some `b` symbol is from `a`). MSVC and Clang (17+) use this model. I don't know MSVC's rationale, but Clang's is to make CMIs relocatable by not embedding paths to dependent modules in CMIs. This should help caching and network transfer sizes in distributed builds. LLVM/Clang discussion: https://discourse.llvm.org/t/c-20-modules-should-the-bmis-contain-paths-to-their-dependent-bmis/70422 https://github.com/llvm/llvm-project/issues/62707 Maybe I'm missing how this *actually* works in GCC as I've really only interacted with it through the command line, but I've not needed to mention `a.cmi` when compiling `use.cppm`. Is `a.cmi` referenced and read through some embedded information in `b.cmi` or does `b.cmi` include enough information to not need to read it at all? If the former, distributed builds are going to have a problem knowing what files to send just from the command line (I'll call this "implicit thin"). If the latter, that is the "fat" CMI that I'm thinking of. > But wouldn't the transitive modules be dependencies of the direct > imports, so (re)building the direct imports would first require building > the transitive modules anyway? Expressing the transitive closure of > dependencies for each importer seems redundant when it can be easily > derived from the direct dependencies of each module. I'm not concerned whether it is transitive or not, really. If a file is read, it should be reported here regardless of the reason. Note that caching mechanisms may skip actually *doing* the reading, but the dependencies should still be reported from the cached results as-if the real work had been performed. --Ben
Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies
On 7/18/23 16:52, Jason Merrill wrote: On 6/25/23 12:36, Ben Boeckel wrote: On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote: On 6/22/23 22:45, Ben Boeckel wrote: On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote: On 1/25/23 16:06, Ben Boeckel wrote: They affect the build, so report them via `-MF` mechanisms. Why isn't this covered by the existing code in preprocessed_module? It appears as though it is neutered in patch 3 where `write_make_modules_deps` is used in `make_write` (or will use that name Why do you want to record the transitive modules? I would expect just noting the ones with imports directly in the TU would suffice (i.e check the 'outermost' arg) FWIW, only GCC has "fat" modules. MSVC and Clang both require the transitive closure to be passed. The idea there is to minimize the size of individual module files. If GCC only reads the "fat" modules, then only those should be recorded. If it reads other modules, they should be recorded as well. Please explain what you mean by fat modules. There seems to be confusion. But wouldn't the transitive modules be dependencies of the direct imports, so (re)building the direct imports would first require building the transitive modules anyway? Expressing the transitive closure of dependencies for each importer seems redundant when it can be easily derived from the direct dependencies of each module. Jason -- Nathan Sidwell
Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies
On 6/25/23 12:36, Ben Boeckel wrote: On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote: On 6/22/23 22:45, Ben Boeckel wrote: On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote: On 1/25/23 16:06, Ben Boeckel wrote: They affect the build, so report them via `-MF` mechanisms. Why isn't this covered by the existing code in preprocessed_module? It appears as though it is neutered in patch 3 where `write_make_modules_deps` is used in `make_write` (or will use that name Why do you want to record the transitive modules? I would expect just noting the ones with imports directly in the TU would suffice (i.e check the 'outermost' arg) FWIW, only GCC has "fat" modules. MSVC and Clang both require the transitive closure to be passed. The idea there is to minimize the size of individual module files. If GCC only reads the "fat" modules, then only those should be recorded. If it reads other modules, they should be recorded as well. But wouldn't the transitive modules be dependencies of the direct imports, so (re)building the direct imports would first require building the transitive modules anyway? Expressing the transitive closure of dependencies for each importer seems redundant when it can be easily derived from the direct dependencies of each module. Jason
Re: LRA for avr: help with FP and elimination
On 7/17/23 03:17, senthilkumar.selva...@microchip.com wrote:
On Fri, 2023-07-14 at 09:29 -0400, Vladimir Makarov wrote:
If you send me the preprocessed test, I could start to work on it to fix
the problems. I think it is hard to fix them right for a person having
a little experience with LRA.
Ok, this is a reduced test case that reproduces the failure.
$ cat case.c
typedef int HItype __attribute__ ((mode (HI)));
HItype
__mulvhi3 (HItype a, HItype b)
{
HItype w;
if (__builtin_mul_overflow (a, b, &w))
__builtin_trap ();
return w;
}
On latest master, this trivial patch turns on LRA for avr
--- gcc/config/avr/avr.cc
+++ gcc/config/avr/avr.cc
@@ -15244,9 +15244,6 @@ avr_float_lib_compare_returns_bool (machine_mode mode,
enum rtx_code)
#undef TARGET_CONVERT_TO_TYPE
#define TARGET_CONVERT_TO_TYPE avr_convert_to_type
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_ADDR_SPACE_SUBSET_P
#define TARGET_ADDR_SPACE_SUBSET_P avr_addr_space_subset_p
Then configuring and building for avr without attempting to build libgcc
$ configure --target=avr --prefix= --enable-languages=c && make all-host
&& make install-host
And finally to reproduce the failure
$ /bin/avr-gcc -mmcu=avr25 case.c -Os
Thank you. I've reproduced the bug and started to work on it
yesterday. The problem is a bit tricky than I initially thought but I
believe I'll fix it on this week.
Re: Ju-Zhe Zhong and Robin Dapp as RISC-V reviewers
On Tue, Jul 18, 2023 at 09:25:44AM +0800, juzhe.zh...@rivai.ai wrote: > Thanks Jeff. > I will wait after Robin updated his MAINTAINERS (since I don't known what > information I need put in). Add riscv port Juzhe Zhong line to the Reviewers section of MAINTAINERS file (alphabetically before RTL optimizers) and remove your line from Write After Approval section. Jakub
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 Microsoft this is no longer true best regards, Julian
