Летнее фестивальное меню
c 4 июня по 31 августа Посмотреть меню Послушать плейлист Вы получили это письмо, потому что подписались на рассылку от LB Group. Чтобы отписаться, перейдите по ссылке.
Re: Partial vector
On Tue, Jun 4, 2024 at 8:52 AM Stefan Schulze Frielinghaus via Gcc wrote: > > Hi all, > > Is there some sort of guarantee that the unused part of a partial vector has > all bits set to zero? > > The question came up while implementing an insn for mode V2SF on s390 > where only half of the hard register would be utilized. The final > machine instruction, however, would make use of the full register > (V4SF). Therefore, if the other half is not guaranteed to be zero, then > a floating-point exception might occur in this particular case. Of > course, if such a guarantee exists, then one would have to maintain that > for all insn implementations. > > This all sounds a bit fragile and probably better solved by having some > sort of masking support by the hardware but I'm still keen to know. There is no guarantee by the middle-end (like having PROMOTE_MODE for vectors). You may want to look how x86 implements MMX-with-SSE (aka 8 byte vectors within 16 byte SSE regs). In particular there's no generic middle-end support for "lowering" V2SFmode to V4SFmode during RTL expansion, your machine description expanders have to do that. Richard. > Cheers, > Stefan
Order for springs
Hello, I would like to present our offer, which includes a wide range of springs made from patented wire with diameters from 0.2 to 16.0 mm, as well as stainless spring wires. We manufacture not only traditional compression and extension springs, but also torsion springs, shaped springs, disc springs, flat springs, rings, washers, and many more. The products are available in various materials, such as spring strips and others, according to individual agreements with the Client. Do you need the highest quality spring solutions? Best regards Harry Russell
Re: Partial vector
On Tue, Jun 04, 2024 at 09:50:04AM +0200, Richard Biener wrote: > On Tue, Jun 4, 2024 at 8:52 AM Stefan Schulze Frielinghaus via Gcc > wrote: > > > > Hi all, > > > > Is there some sort of guarantee that the unused part of a partial vector has > > all bits set to zero? > > > > The question came up while implementing an insn for mode V2SF on s390 > > where only half of the hard register would be utilized. The final > > machine instruction, however, would make use of the full register > > (V4SF). Therefore, if the other half is not guaranteed to be zero, then > > a floating-point exception might occur in this particular case. Of > > course, if such a guarantee exists, then one would have to maintain that > > for all insn implementations. > > > > This all sounds a bit fragile and probably better solved by having some > > sort of masking support by the hardware but I'm still keen to know. > > There is no guarantee by the middle-end (like having PROMOTE_MODE > for vectors). You may want to look how x86 implements MMX-with-SSE > (aka 8 byte vectors within 16 byte SSE regs). > > In particular there's no generic middle-end support for "lowering" V2SFmode > to V4SFmode during RTL expansion, your machine description expanders > have to do that. Thanks for clarification. I will also have a look at the MMX-with-SSE feature. Cheers, Stefan > > Richard. > > > Cheers, > > Stefan
Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address failed: thomasinacu...@att.net: SMTP error from remote server for RCPT TO command, host: al-ip4-mx-vip2.prodigy.net (144.160.235.144) reason: 550 5.2.1 ... Addressee unknown, relay=[74.208.4.1 97] --- The header of the original message is following. --- Received: from winhex19beus2.winusa.mail ([10.72.152.141]) by mrieueus.server.lan (mrieueus003 [172.19.150.82]) with ESMTPS (Nemesis) id 0MFumu-1sHETw3ulC-008q5T for ; Tue, 04 Jun 2024 16:30:30 +0200 Received: from vps6 (10.72.152.251) by winhex19beus2.winusa.mail (10.72.152.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1544.11; Tue, 4 Jun 2024 10:30:30 -0400 Date: Tue, 4 Jun 2024 05:30:28 -0900 To: From: "Urgent: Important Message!!" Subject: Chase Message-ID: X-Priority: 3 X-Mailer: PHPMailer 6.6.5 (https://github.com/PHPMailer/PHPMailer) MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 Return-Path: gcc@gcc.gnu.org X-ClientProxiedBy: winhex19beus6.winusa.mail (10.72.152.143) To winhex19beus2.winusa.mail (10.72.152.141) X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:0mHD6uGc+U0=;cHKXPor7j4WxSokg8xQ154TKvxv 1KUmkU1Yyn3uTkI4eGfcEG9mxv286WsTIXmjx0ntGN4mt7/wBMjOruH4lueTr8WHco/jgulr6 SuZfukDKQTHFA7FxeKtOnxxaj69hgz0IwhRX5TJ3ojvxvqEbBt7M64OMljSCLRAdpGXXnzAep opxYKP4ACC/mxF9rz2g//qYD7fJIYFSBZjxqg3IUnX8WlBGePr9nxzRKHqtL0MZNd5ZkBXeBH z5CeNavFPLbt3IUNcEpUNyi0tMug97Iy9T3P9K722I/JIdJgDx2Wwpr04XfkJc4GeP+J5+4qc F1CjlC2klbs+6v/5Au/CyqudSra+0nQzb+BIXLmYFIgeThdffQkX5MnqYhAn2nl1eP3A51v9M mPJd308eSMje4Vu9wDs2//3Ugp7797n6bbb1rU0gp+LWrUVgEcIk6uh53P/kLsoejgHyLt2vE gx+rZk3PtPYkMhWMdvkt3KoKq2prlPSTGLKBBbn+4WS1ngAhcLGJpXrlWmQif5WWkXQwIQ1EX iXp01wICzPTQffWAuCBP+2+h/8twJyJGDRie7ROVT1PGuct+RM66ISXE4/N7CVsvYaJmiWtzO vZP9l27ferT1jFM8i2FL5m4mLq7SCwhYAMBac08enKCqVqiWbb6wY2lBs6TTIqchy4vd8MZGS USllxHmW76idnxLFmiYjKQTNCmdoD4tE2f63iqhR2En++KN0N71wOHStqaqPj6jJNkLgyf+PU J1sn6EqQjSNZVEAX80ERaHd0SNPC9dcwLijgURxrnW0KLRGaKFlx2M= Reporting-MTA: dns;perfora.net Arrival-Date: Tue, 04 Jun 2024 16:30:30 +0200 Final-Recipient: rfc822;thomasinacurry@att.net Action: failed Status: 5.0.0 Final-Log-ID: 0MFumu-1sHETw3ulC-008q5T
Re: How to avoid some built-in expansions in gcc?
Hello, On Sat, 1 Jun 2024, Richard Biener via Gcc wrote: > >>> You have a pointer how to define a target optab? I looked into optabs > >>> code but found no appropriate hook. For isinf is seems is is > >>> enough to provide a failing expander, but other functions like isnan > >>> don't have an optab entry, so there is a hook mechanism to extend optabs? > >> Just add corresponding optabs for the missing cases (some additions are > >> pending, like isnornal). There’s no hook to prevent folding to FP > >> compares nor is that guarded by other means (like availability of native > >> FP ops). Changing the guards would be another reasonable option. > >> Richard > > > > There are many other such folds, e.g. for isdigit(). The AVR libraries > > have all this in hand-optimized assembly, and all these built-in expansions > > are bypassing that. Open-coded C will never beat that assemlbly code, at > > least not with the current GCC capabilities. > > The idea is that isdigit() || isalpha() or similar optimize without > special casing the builtins. > > > How would I go about disabling / bypassing non-const folds from ctype.h and > > the many others? > > I think this mostly shows we lack late recognition of open-coded isdigit > and friends, at least for the targets where inlining them is not > profitable. > > 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. > A good solution would base this on (size) costs, the perfect solution > would re-discover the builtins late and undo inlining that didn’t turn > out to enable further simplification. > > How is inlined isdigit bad on AVR? Is a call really that cheap > considering possible register spilling around it? On AVR with needing to use 8bit registers to do everything? I'm pretty sure the call is cheaper, yeah :) Ciao, Michael.
Re: How to avoid some built-in expansions in gcc?
> Am 04.06.2024 um 16:56 schrieb Michael Matz : > > Hello, > > On Sat, 1 Jun 2024, Richard Biener via Gcc wrote: > > You have a pointer how to define a target optab? I looked into optabs > code but found no appropriate hook. For isinf is seems is is > enough to provide a failing expander, but other functions like isnan > don't have an optab entry, so there is a hook mechanism to extend optabs? Just add corresponding optabs for the missing cases (some additions are pending, like isnornal). There’s no hook to prevent folding to FP compares nor is that guarded by other means (like availability of native FP ops). Changing the guards would be another reasonable option. Richard >>> >>> There are many other such folds, e.g. for isdigit(). The AVR libraries >>> have all this in hand-optimized assembly, and all these built-in expansions >>> are bypassing that. Open-coded C will never beat that assemlbly code, at >>> least not with the current GCC capabilities. >> >> The idea is that isdigit() || isalpha() or similar optimize without >> special casing the builtins. >> >>> How would I go about disabling / bypassing non-const folds from ctype.h and >>> the many others? >> >> I think this mostly shows we lack late recognition of open-coded isdigit >> and friends, at least for the targets where inlining them is not >> profitable. >> >> 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 which is worse for optimization than just not inline expanding it. Richard >> A good solution would base this on (size) costs, the perfect solution >> would re-discover the builtins late and undo inlining that didn’t turn >> out to enable further simplification. >> >> How is inlined isdigit bad on AVR? Is a call really that cheap >> considering possible register spilling around it? > > On AVR with needing to use 8bit registers to do everything? I'm pretty > sure the call is cheaper, yeah :) > > > Ciao, > Michael.
Re: How to avoid some built-in expansions in gcc?
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? Jakub
What is the purpose of these two fixincludes?
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). There are currently two generic (not darwin-specific) fixincludes that are triggered: - math_exception. Right not it is very broad, and only skipped on glibc and Solaris. I think the comment "This should be bypassed on __cplusplus, but that does not work on solaris 8 and 9” indicates that this fix is really outdated, probably not necessary. Most if not all headers nowadays are C++-compatible, no? I would like to suggest replacing this with a proper bypass on __cplusplus, with the attached patch. - stdio_stdarg_h and stdio_va_list. These, I simply don’t understand what is the intent. It appears to me that they are not necessary on darwin, and I could potentially add it to “skip”. But… is it really necessary anywhere? It is from before 1998. I would welcome guidance on how to handle these, or advice on what the second is supposed to achieve. Thanks, FX math_exception.diff Description: Binary data
Which GCC version start to support RISC-V RVV1.0
Hi, We would like to know which GCC version start to support RISC-V RVV1.0 ? We appreciate for your help. Best Regards, Erick CONFIDENTIALITY NOTICE: This e-mail (and its attachments) may contain confidential and legally privileged information or information protected from disclosure. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein is strictly prohibited. In this case, please immediately notify the sender by return e-mail, delete the message (and any accompanying documents) and destroy all printed hard copies. Thank you for your cooperation. Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.
