Re: Which GCC version start to support RISC-V RVV1.0
On 6/4/24 8:51 PM, Erick Kuo-Chen Huang(黃國鎭) via Gcc-help wrote: Hi, We would like to know which GCC version start to support RISC-V RVV1.0 ? We appreciate for your help. gcc-14. Jeff
Re: How to avoid some built-in expansions in gcc?
On 04/06/2024 19:43, Michael Matz via Gcc wrote: Hello, On Tue, 4 Jun 2024, Richard Biener wrote: A pragmatic solution might be a new target hook, indicating a specified builtin is not to be folded into an open-coded form. Well, that's what the mechanism behind -fno-builtin-foobar is supposed to be IMHO. Hopefully the newly added additional mechanism using optabs and ifns (instead of builtins) heeds it. -fno-builtin makes GCC not know semantics of the functions called Hmm, true. Not expanding inline is orthogonal strictly speaking ... which is worse for optimization than just not inline expanding it. ... but on AVR expanding inline is probably worse than that lost knowledge. So yeah, ideally we would devise a (simple/reasonable) way to at least disable inline expansion, without making it non-builtin. The ideal here would be to have some way to tell gcc that a given function has the semantics of a different function. For example, a programmer might have several implementations of "memcpy" that are optimised for different purposes based on the size or alignment of the arguments. Maybe some of these are written with inline assembly or work in a completely different way (I've used DMA on a microcontroller for the purpose). If you could tell the compiler that the semantic behaviour and results were the same as standard memcpy(), that could lead to optimisations. Then you could declare your "isinf" function with __attribute__((semantics_of(__builtin_isinf))). And the feature could be used in any situation where you can write a function in a simple, easy-to-analyse version and a more efficient but opaque version.
Re: How to avoid some built-in expansions in gcc?
Hello, On Tue, 4 Jun 2024, Jakub Jelinek wrote: > On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote: > > (Well, and without reverse-recognition of isfinite-like idioms in the > > sources. That's orthogonal as well.) > > Why? If isfinite is better done by a libcall, why isn't isfinite-like > idiom also better done as a libcall? It is. I was just trying to avoid derailing the discussion for finding an immediately good solution by searching for the perfect solution. Idiom finding simply is completely independend from the posed problem that Georg-Johann has, which remains unsolved AFAICS, as using fno-builtin-foobar has its own (perhaps mere theoretical for AVR) problems. Ciao, Michael.
Re: How to avoid some built-in expansions in gcc?
Hey, On Wed, 5 Jun 2024, David Brown wrote: > The ideal here would be to have some way to tell gcc that a given > function has the semantics of a different function. For example, a > programmer might have several implementations of "memcpy" that are > optimised for different purposes based on the size or alignment of the > arguments. Maybe some of these are written with inline assembly or work > in a completely different way (I've used DMA on a microcontroller for > the purpose). If you could tell the compiler that the semantic > behaviour and results were the same as standard memcpy(), that could > lead to optimisations. > > Then you could declare your "isinf" function with > __attribute__((semantics_of(__builtin_isinf))). > > And the feature could be used in any situation where you can write a > function in a simple, easy-to-analyse version and a more efficient but > opaque version. Hmm, that actually sounds like a useful feature. There are some details to care for, like what to do with arguments: e.g. do they need to have the same types as the referred builtin, only compatible ones, or even just convertible ones, and suchlike, but yeah, that sounds nice. Ciao, Michael.
Re: How to avoid some built-in expansions in gcc?
> Am 05.06.2024 um 16:08 schrieb Michael Matz : > > Hey, > >> On Wed, 5 Jun 2024, David Brown wrote: >> >> The ideal here would be to have some way to tell gcc that a given >> function has the semantics of a different function. For example, a >> programmer might have several implementations of "memcpy" that are >> optimised for different purposes based on the size or alignment of the >> arguments. Maybe some of these are written with inline assembly or work >> in a completely different way (I've used DMA on a microcontroller for >> the purpose). If you could tell the compiler that the semantic >> behaviour and results were the same as standard memcpy(), that could >> lead to optimisations. >> >> Then you could declare your "isinf" function with >> __attribute__((semantics_of(__builtin_isinf))). >> >> And the feature could be used in any situation where you can write a >> function in a simple, easy-to-analyse version and a more efficient but >> opaque version. > > Hmm, that actually sounds like a useful feature. There are some details > to care for, like what to do with arguments: e.g. do they need to have the > same types as the referred builtin, only compatible ones, or even just > convertible ones, and suchlike, but yeah, that sounds nice. There’s the difficulty to avoid having GCC replace it with a semantically equivalent call (that would be no longer optimized). That is, your intent is to enable a subset of optimizations only enabled by denoting the semantic equivalence. That subset at least needs documenting. Richard > > Ciao, > Michael.
gcc-11-20240605 is now available
Snapshot gcc-11-20240605 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240605/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision c6091480032a1ec45ee5b063aafb8a1ed3f67e40 You'll find: gcc-11-20240605.tar.xz Complete GCC SHA256=885497ba8d29aa5001e953cd09646724d778d97ebe14d62da916c27bebcc2ce7 SHA1=fe88003d206ede7c96643de848a7321e51f33622 Diffs from 11-20240529 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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: What is the purpose of these two fixincludes?
FX Coudert via Gcc writes: > Hi, > > I am trying to reduce the number of unneeded fixincludes that are used > on darwin (because fixincluded headers make it impossible to change > SDK once the compiler is built, which is common practice in the macOS > world, and quite useful). It's the same problem on Linux. You get all kinds of strange problems with previously installed gccs once you upgrade the system. I'm not sure in fact any modern target gcc or clang as the standard compiler needs fixincludes at all. I usually just install with install-no-fixedincludes, but really this should probably be a configure option and default to on. -Andi
