[TLS]Re: Curve-popularity data?
On Wednesday, 5 June 2024 22:00:44 CEST, D. J. Bernstein wrote: Andrei Popov writes: I support this change, willing to implement it in the Windows TLS stack. We have thousands of customers concerned about increased latencies due to the enablement of TLS 1.3. The services they connect to require NIST curves and HRR is required to get TLS clients to send appropriate key shares. To clarify, when you say "require NIST curves", do you mean "require conformance with NIST SP 800-56A"? really depends on the deployment, some just want to use SP 800-56A curves, some need actual, real, to the letter, legal compliance with FIPS 140-2 or FIPS 140-3. In other words, will another curve be allowed once it's added to NIST SP 800-56A? Maybe faster: would the short-term problem be addressed if we can convince NIST to announce that it will consider X25519 and X448 for a revision of SP 800-56A, and doesn't intend to enforce conformance of cryptographic modules with SP 800-56A until the revisions are done? Short-term problem won't be solved like that for everybody. For deployments that require FIPS compliance, the implementation itself needs to be certified. At this moment there's no way to get it certified, so we are at least 2-3 years away from a certified implementation of x25519 being available even if NIST marked x25519 as approved tomorrow. Or are you saying that, independently of NIST's decisions, the services in question are for some reason specifically requiring what's typically called the "NIST curves", namely the fifteen NSA curves that NIST standardized? Or the subset of those that NIST hasn't deprecated yet? Because NIST is a trend-setter, many other compliance organisations reuse those curves (French ANSSI, German BSI, Japanese IPA, etc.). Similarly Common Criteria certifications, while they're international, they're similarly heavily influenced by what NIST and NSA recommends. All of them will have a lot of inertia. And to address what John Mattsson wrote in a separate email: yes, IETF is international and should not be bound by particular government requirements for IETF standards to be actually usable in practice, they do need to take into account what governmental bodies require. What gets published by IETF can be superset of what govs want. So, while I'd love to see x25519 in governmental standards, I think it's better to spend energy making sure that we deploy ML-KEM as soon as possible, in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256 and P-384). -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Curve-popularity data?
On Thursday, 6 June 2024 00:57:52 CEST, A A wrote: "E.g. a client might also have legitimate reasons to nudge servers to use a stronger curve than P-256 in the initial CH and only fall back to weaker curves by explicit request via HRR. Probably the reason for Chrome for requesting HRR for P-256 is the attempt to nudge servers to use an algorithm which is believed to provide advantages for the client-side implementation (possibly both, speed/power or security or bandwidth) in comparison to P-256." About speed: https://bench.cr.yp.to/results-dh.html shows that on amd64; Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz; hertz, supercop-20240425, nistp256(P-256) needs 202616 cycles to generate a key pair, 535274 cycles to compute a shared secret; Curve25519 needs 101289cycles to generate a key pair, 109491 cycles to compute a shared secret; And, X25519's key share only need 32 bytes, P-256 needs 65 bytes. Conclusion: P-256 neither has security nor performance (power) advantage compare with X25519. That's not the performance delta I see in practice. Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H x25519 derive shared secret: 35062.2 op/s P-256 derive shared secret: 22741.1 op/s (run `openssl speed ecdhp256; openssl speed ecdhx25519` to try yourself) 05.06.2024, 22:05, "Björn Haase" : Hi Eric, Hi all, One more thing: we are finalizing RFC 8446-bis right now, so if there is WG consensus to require that clients offer all MTI curves in the key_shares of their initial CH, then that would be a straightforward text change. I think that we might rather keep a mechanism that preserves the possibility of the client-side to express a preference regarding a specific cipher suite / curve and accept other curves only using the HRR-mechanism. E.g. a client might also have legitimate reasons to nudge servers to use a stronger curve than P-256 in the initial CH and only fall back to weaker curves by explicit request via HRR. Probably the reason for Chrome for requesting HRR for P-256 is the attempt to nudge servers to use an algorithm which is believed to provide advantages for the client-side implementation (possibly both, speed/power or security or bandwidth) in comparison to P-256. Björn. Mit freundlichen Grüßen | Best Regards Dr. Björn Haase Senior Expert Electronics | TGREH Electronics Hardware Endress+Hauser Liquid Analysis Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany Phone: +49 7156 209 10377 bjoern.ha...@endress.com | www.ehla.endress.com Endress+Hauser Conducta GmbH+Co.KG Amtsgericht Stuttgart HRA 201908 Sitz der Gesellschaft: Gerlingen Persönlich haftende Gesellschafterin: Endress+Hauser Conducta Verwaltungsgesellschaft mbH Sitz der Gesellschaft: Gerlingen Amtsgericht Stuttgart HRA 201929 Geschäftsführer: Dr. Manfred Jagiella Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben. Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach. Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such. , -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Curve-popularity data?
On Wednesday, 5 June 2024 15:38:57 CEST, Eric Rescorla wrote: On Wed, Jun 5, 2024 at 6:35 AM Eric Rescorla wrote: On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann wrote: Nick Harper writes: I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves be present in the key_share extension if that extension is non-empty. Just because it's possible to rules-lawyer your way around something doesn't make it valid (I also see nothing in the spec saying a TLS 1.3 implementation can't reformat your hard drive, for example, so presumably that's OK too). The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI keyex in its client hello, making it a noncompliant TLS 1.3 implementation. I don't believe this analysis is correct. You state: As Nick notes, RFC 8446 explicitly permits the extension to be empty, so it clearly cannot be the case that mere failure to provide an MTI key_share in CH makes an implementation noncompliant, contra your statement above. The only question at hand is whether the specification permits you to send a non-empty key_shares field that excludes the MTI. However, the specification *also* permits you to send a subset of supported groups: the same order. However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups. Such a situation could arise if the most preferred groups I think the best reading of this text is that you are free to send *any* subset of the supported groups, whether it includes the MTI or not. The requirement in S 9.1 is merely that the application "support key exchange with secp256r1", which Chrome does: it's in "supported_groups" and (presumably) works if the server sends an HRR. Given the above more explicit text about "key_shares", I don't think it's reasonable to infer that MTI requires more than this. This isn't to say anything about whether this is the best implementation choice, which is a distinct question from what the specification requires. One more thing: we are finalizing RFC 8446-bis right now, so if there is WG consensus to require that clients offer all MTI curves in the key_shares of their initial CH, then that would be a straightforward text change. I definitely don't agree with such a requirement. -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Curve-popularity data?
On Wednesday, 5 June 2024 09:19:51 CEST, Stephen Farrell wrote: On 05/06/2024 06:56, John Mattsson wrote: I think P-384 is the most required of the NIST P-curves. I've heard that some. Oddly, I use a test server that only supports p384 as a way to trigger HRR when testing ECH, which seems to work for most clients who test with my servers, so I wonder if, when using a hybrid KEM, we're heading to a world where one large set of clients emit x25519 and x25519+pq and another large set emit p256 and p384+pq? I guess if that meant there wasn't a real need for much use of p256+pq that might be a small saving and worth documenting somewhere even if we do define a codepoint for p256+pq. 1. P-256 with OpenSSL 3.1.1 on my machine is quite literally over 20 times faster than P-384 2. While NIST FIPS 186-5 includes Ed25519 as an approved algorithm, it does not include X25519 as an approved algorithm. 3. we're likely years before we will get first FIPS certified ML-KEM implementation so I expect that most regular servers will use x25519+ML-KEM, the ones that have a requirement for FIPS compliance will have to use P-256+ML-KEM, and the ones that have Common Critera requirements will have to use P-384+ML-KEM. -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Curve-popularity data?
On Wednesday, 5 June 2024 07:56:21 CEST, John Mattsson wrote: Andrei Popov wrote: CNSA requires P384, so we’ll also need a hybrid that includes this EC. Yes, I am not sure about the statement that P-256 is required. The requirement for FIPS in the next few years should be one of the NIST P-curves. I think P-384 is the most required of the NIST P-curves. P-256 is the fastest of the NIST curves and fine for everyday use. (both because it's one of the smaller ones but also because it has one of the most optimised implementations around. P-384 is the only curve allowed for CNSA 1.0, so it will be needed for the transition period. we need both Scott Fluhrer wrote: I believe that it is unreasonable to expect that a single combination would satisfy everyone’s needs. Yes, that is completely unreasonable. TLS is MUCH larger than the Web. There will clearly be registrations for combinations of most current curves (P-curves, X-curves, Brainpool, SM, GOST) with most PQC KEMs (ML-KEM, BIKE/HQC, Classic McEliece, FrodoKEM, future Isogeny? (Isogenies was the hottest topic at Eurocrypt this year) ). European countries say that hybrids will be a must for a long-time. Cheers, John From: Andrei Popov Date: Wednesday, 5 June 2024 at 07:24 To: Eric Rescorla , Stephen Farrell Cc: tls@ietf.org Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? CNSA requires P384, so we’ll also need a hybrid that includes this EC. Cheers, Andrei From: Eric Rescorla Sent: Monday, June 3, 2024 12:53 PM To: Stephen Farrell Cc: Loganaden Velvindron ; Andrei Popov ; Salz, Rich ; tls@ietf.org Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell wrote: I'm afraid I have no measurements to offer, but... On 03/06/2024 19:05, Eric Rescorla wrote: The question is rather what the minimum set of algorithms we need is. My point is that that has to include P-256. It may well be the case that it needs to also include X25519. Yep, the entirely obvious answer here is we'll end up defining at least x25519+PQ and p256+PQ. Arguing for one but not the other (in the TLS WG) seems pretty pointless to me. (That said, the measurements offered are as always interesting, so the discussion is less pointless than the argument:-) Yes, this seems correct to me. -Ekr Cheers, S. -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
core.git: desktop/source sfx2/source
desktop/source/lib/init.cxx |1 +
sfx2/source/control/unoctitm.cxx |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
New commits:
commit f67e7fc5c71308e1866c78a1c48c9a6c070886cc
Author: Hubert Figuière
AuthorDate: Tue May 28 17:08:07 2024 -0400
Commit: Caolán McNamara
CommitDate: Thu May 30 10:10:06 2024 +0200
cool#9174 - Enable .uno:ChangeBezier
This allow Convert to Curve in COOL
Signed-off-by: Hubert Figuière
Change-Id: Id1aa0bc68238ac29221edb1c1ec7dda6e16ce103
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168170
Reviewed-by: Caolán McNamara
Tested-by: Jenkins CollaboraOffice
(cherry picked from commit c5a7ff366fd9094c3ee1aba4c016b59c5635ea9b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168194
Tested-by: Jenkins
diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index 4e484cf71a34..464c2498cf9f 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -3853,6 +3853,7 @@ static void doc_iniUnoCommands ()
u".uno:CellProtection"_ustr,
u".uno:MoveKeepInsertMode"_ustr,
u".uno:ToggleSheetGrid"_ustr,
+u".uno:ChangeBezier"_ustr,
};
util::URL aCommandURL;
diff --git a/sfx2/source/control/unoctitm.cxx b/sfx2/source/control/unoctitm.cxx
index b267c6157b57..6dd55fc06a2d 100644
--- a/sfx2/source/control/unoctitm.cxx
+++ b/sfx2/source/control/unoctitm.cxx
@@ -1117,7 +1117,8 @@ static void InterceptLOKStateChangeEvent(sal_uInt16 nSID,
SfxViewFrame* pViewFra
aEvent.FeatureURL.Path == "InsertDateContentControl" ||
aEvent.FeatureURL.Path == "InsertDropdownContentControl" ||
aEvent.FeatureURL.Path == "InsertPlainTextContentControl" ||
- aEvent.FeatureURL.Path == "InsertPictureContentControl")
+ aEvent.FeatureURL.Path == "InsertPictureContentControl" ||
+ aEvent.FeatureURL.Path == "ChangeBezier")
{
aBuffer.append(aEvent.IsEnabled ? std::u16string_view(u"enabled") :
std::u16string_view(u"disabled"));
}
core.git: Branch 'distro/collabora/co-24.04' - desktop/source sfx2/source
desktop/source/lib/init.cxx |1 +
sfx2/source/control/unoctitm.cxx |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
New commits:
commit c5a7ff366fd9094c3ee1aba4c016b59c5635ea9b
Author: Hubert Figuière
AuthorDate: Tue May 28 17:08:07 2024 -0400
Commit: Caolán McNamara
CommitDate: Wed May 29 16:34:12 2024 +0200
cool#9174 - Enable .uno:ChangeBezier
This allow Convert to Curve in COOL
Signed-off-by: Hubert Figuière
Change-Id: Id1aa0bc68238ac29221edb1c1ec7dda6e16ce103
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168170
Reviewed-by: Caolán McNamara
Tested-by: Jenkins CollaboraOffice
diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index 86f0efda8857..70634fefa269 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -3928,6 +3928,7 @@ static void doc_iniUnoCommands ()
u".uno:CellProtection"_ustr,
u".uno:MoveKeepInsertMode"_ustr,
u".uno:ToggleSheetGrid"_ustr,
+u".uno:ChangeBezier"_ustr,
};
util::URL aCommandURL;
diff --git a/sfx2/source/control/unoctitm.cxx b/sfx2/source/control/unoctitm.cxx
index d289cd2616a8..ac3a85cc336a 100644
--- a/sfx2/source/control/unoctitm.cxx
+++ b/sfx2/source/control/unoctitm.cxx
@@ -1117,7 +1117,8 @@ static void InterceptLOKStateChangeEvent(sal_uInt16 nSID,
SfxViewFrame* pViewFra
aEvent.FeatureURL.Path == "InsertDateContentControl" ||
aEvent.FeatureURL.Path == "InsertDropdownContentControl" ||
aEvent.FeatureURL.Path == "InsertPlainTextContentControl" ||
- aEvent.FeatureURL.Path == "InsertPictureContentControl")
+ aEvent.FeatureURL.Path == "InsertPictureContentControl" ||
+ aEvent.FeatureURL.Path == "ChangeBezier")
{
aBuffer.append(aEvent.IsEnabled ? std::u16string_view(u"enabled") :
std::u16string_view(u"disabled"));
}
[NTG-context] lua error in `back-exp.lmt`
ConTeXt LMTX version: 2024.05.27 18:16 Sample tex file: \setupbackend[export=yes] \starttext x \startsectionlevel \startitemize \item \startitemize \item \startitemize \item \stopitemize \stopitemize \stopitemize \stopsectionlevel \stoptext Error log: tex error > tex error on line 1 in file ./input.tex: lua error: registered function call [252]: ...mtx/tex/texmf-context/tex/context/base/mkxl/back-exp.lmt:1426: attempt to get length of a nil value (local 'td') stack traceback: ...mtx/tex/texmf-context/tex/context/base/mkxl/back-exp.lmt:1426: in upvalue 'pushcontent' ...mtx/tex/texmf-context/tex/context/base/mkxl/back-exp.lmt:1597: in upvalue 'collectresults' ...mtx/tex/texmf-context/tex/context/base/mkxl/back-exp.lmt:1867: in upvalue 'collectresults' ...mtx/tex/texmf-context/tex/context/base/mkxl/back-exp.lmt:1867: in upvalue 'collectresults' . ...mtx/tex/texmf-context/tex/context/base/mkxl/back-exp.lmt:1867: in upvalue 'collectresults' ...mtx/tex/texmf-context/tex/context/base/mkxl/back-exp.lmt:1969: in upvalue 'nodes_handlers_export' [string "local tonut = nodes.tonut..."]:27: in function <[string "local tonut = nodes.tonut..."]:12> (...tail calls...) ...mtx/tex/texmf-context/tex/context/base/mkxl/node-shp.lmt:38: in function <...mtx/tex/texmf-context/tex/context/base/mkxl/node-shp.lmt:37> (...tail calls...) 1 >> \setupbackend[export=yes] 2 3 \starttext 4 x 5 \startsectionlevel 6 \startitemize 7 \item 8 \startitemize 9 \item 10 \startitemize 11 \item mtx-context | fatal error: return code: 1 ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: lua error in `strc-lev.lua`
I rerun `install.sh` after replacing `strc-lev.lua` and the error goes away. Thanks Hans! On Tue, 28 May 2024 at 20:20, Hans Hagen wrote: > On 5/28/2024 10:48 AM, Sylvain Hubert wrote: > > ConTeXt LMTX version: 2024.05.27 18:16 > > > > Reproducible example: > > > > \definesectionlevels > > [default] > > [section, subsection, subsubsection, subsubsubsection, > subsubsubsubsection] > > > > \starttext > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stoptext > > > > lua error > lua error on line 19 in file ./input.tex: > > > > registered function call [969]: > > ...mtx/tex/texmf-context/tex/context/base/mkiv/strc-lev.lua:75: attempt > > to index a nil value (field '?') > > stack traceback: > > ...mtx/tex/texmf-context/tex/context/base/mkiv/strc-lev.lua:75: > > in function > <...mtx/tex/texmf-context/tex/context/base/mkiv/strc-lev.lua:66> > > (...tail calls...) > can you test with the attached ... (remake the format) > > \starttext > \startsectionlevel[title=level 1] > \startsectionlevel[title=level 2 ] > \startsectionlevel[title=level 3] > \startsectionlevel[title=level 4] > \startsectionlevel[title=level 5] > \startsectionlevel[title=level 6] > \startsectionlevel[title=level 7] > \startsectionlevel[title=level 8] > \startsectionlevel[title=level 9] > \startsectionlevel[title=level 10 ] > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stoptext > > > - >Hans Hagen | PRAGMA ADE >Ridderstraat 27 | 8061 GH Hasselt | The Netherlands > tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl > - > ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: lua error in `strc-lev.lua`
I replaced `strc-lev.lua` and rerun `context` but the error message stays the same. `context` command doesn't seem to recognize the change of `strc-lev.lua`. Should I run `mtxrun` or something before? On Tue, 28 May 2024 at 20:20, Hans Hagen wrote: > On 5/28/2024 10:48 AM, Sylvain Hubert wrote: > > ConTeXt LMTX version: 2024.05.27 18:16 > > > > Reproducible example: > > > > \definesectionlevels > > [default] > > [section, subsection, subsubsection, subsubsubsection, > subsubsubsubsection] > > > > \starttext > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \startsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stopsectionlevel > > \stoptext > > > > lua error > lua error on line 19 in file ./input.tex: > > > > registered function call [969]: > > ...mtx/tex/texmf-context/tex/context/base/mkiv/strc-lev.lua:75: attempt > > to index a nil value (field '?') > > stack traceback: > > ...mtx/tex/texmf-context/tex/context/base/mkiv/strc-lev.lua:75: > > in function > <...mtx/tex/texmf-context/tex/context/base/mkiv/strc-lev.lua:66> > > (...tail calls...) > can you test with the attached ... (remake the format) > > \starttext > \startsectionlevel[title=level 1] > \startsectionlevel[title=level 2 ] > \startsectionlevel[title=level 3] > \startsectionlevel[title=level 4] > \startsectionlevel[title=level 5] > \startsectionlevel[title=level 6] > \startsectionlevel[title=level 7] > \startsectionlevel[title=level 8] > \startsectionlevel[title=level 9] > \startsectionlevel[title=level 10 ] > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stopsectionlevel > \stoptext > > > - >Hans Hagen | PRAGMA ADE >Ridderstraat 27 | 8061 GH Hasselt | The Netherlands > tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl > - > ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] lua error in `strc-lev.lua`
ConTeXt LMTX version: 2024.05.27 18:16 Reproducible example: \definesectionlevels [default] [section, subsection, subsubsection, subsubsubsection, subsubsubsubsection] \starttext \startsectionlevel \startsectionlevel \startsectionlevel \startsectionlevel \startsectionlevel \startsectionlevel \startsectionlevel \stopsectionlevel \stopsectionlevel \stopsectionlevel \stopsectionlevel \stopsectionlevel \stopsectionlevel \stopsectionlevel \stoptext lua error > lua error on line 19 in file ./input.tex: registered function call [969]: ...mtx/tex/texmf-context/tex/context/base/mkiv/strc-lev.lua:75: attempt to index a nil value (field '?') stack traceback: ...mtx/tex/texmf-context/tex/context/base/mkiv/strc-lev.lua:75: in function <...mtx/tex/texmf-context/tex/context/base/mkiv/strc-lev.lua:66> (...tail calls...) ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
core.git: Branch 'distro/collabora/co-23.05' - sd/source
sd/source/ui/view/drviews5.cxx | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) New commits: commit 496be6be71ca9ce107213da793f3502a3bfda022 Author: Hubert Figuière AuthorDate: Mon May 20 11:15:35 2024 -0400 Commit: Caolán McNamara CommitDate: Thu May 23 12:48:07 2024 +0200 cool#9019: draw/impress: disable the Grid for now So that the grid isn't shown in the thumbnail. This will need to be reverted later for cool#7406 Change-Id: I01fbc7ebc9e33a27fb866b7ea6dbaaac68ae8f9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167872 Tested-by: Jenkins CollaboraOffice Reviewed-by: Caolán McNamara (cherry picked from commit 41130a39ad68310a0136605cbced1f191396c456) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167826 Tested-by: Jenkins (cherry picked from commit 09f23b8c6cd369b5d0594119f3df62941346a610) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167933 diff --git a/sd/source/ui/view/drviews5.cxx b/sd/source/ui/view/drviews5.cxx index c6774537cfea..160b5c5edf27 100644 --- a/sd/source/ui/view/drviews5.cxx +++ b/sd/source/ui/view/drviews5.cxx @@ -312,7 +312,15 @@ void DrawViewShell::WriteFrameViewData() mpFrameView->SetGridCoarse( mpDrawView->GetGridCoarse() ); mpFrameView->SetGridFine( mpDrawView->GetGridFine() ); mpFrameView->SetSnapGridWidth(mpDrawView->GetSnapGridWidthX(), mpDrawView->GetSnapGridWidthY()); -mpFrameView->SetGridVisible( mpDrawView->IsGridVisible() ); + +// In LOK, Grid isn't implemented, and it appears in the slide thumbnails +// Remove this when Grid is implemented and/or thumbnails are fixed to no longer +// show the grid. +if (comphelper::LibreOfficeKit::isActive()) +mpFrameView->SetGridVisible( false ); +else +mpFrameView->SetGridVisible( mpDrawView->IsGridVisible() ); + mpFrameView->SetGridFront( mpDrawView->IsGridFront() ); mpFrameView->SetSnapAngle( mpDrawView->GetSnapAngle() ); mpFrameView->SetGridSnap( mpDrawView->IsGridSnap() );
core.git: sd/source
sd/source/ui/view/drviews5.cxx | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) New commits: commit 09f23b8c6cd369b5d0594119f3df62941346a610 Author: Hubert Figuière AuthorDate: Mon May 20 11:15:35 2024 -0400 Commit: Caolán McNamara CommitDate: Tue May 21 11:59:02 2024 +0200 cool#9019: draw/impress: disable the Grid for now So that the grid isn't shown in the thumbnail. This will need to be reverted later for cool#7406 Change-Id: I01fbc7ebc9e33a27fb866b7ea6dbaaac68ae8f9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167872 Tested-by: Jenkins CollaboraOffice Reviewed-by: Caolán McNamara (cherry picked from commit 41130a39ad68310a0136605cbced1f191396c456) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167826 Tested-by: Jenkins diff --git a/sd/source/ui/view/drviews5.cxx b/sd/source/ui/view/drviews5.cxx index 8583ecc182c7..fa744fe49bcd 100644 --- a/sd/source/ui/view/drviews5.cxx +++ b/sd/source/ui/view/drviews5.cxx @@ -315,7 +315,15 @@ void DrawViewShell::WriteFrameViewData() mpFrameView->SetGridCoarse( mpDrawView->GetGridCoarse() ); mpFrameView->SetGridFine( mpDrawView->GetGridFine() ); mpFrameView->SetSnapGridWidth(mpDrawView->GetSnapGridWidthX(), mpDrawView->GetSnapGridWidthY()); -mpFrameView->SetGridVisible( mpDrawView->IsGridVisible() ); + +// In LOK, Grid isn't implemented, and it appears in the slide thumbnails +// Remove this when Grid is implemented and/or thumbnails are fixed to no longer +// show the grid. +if (comphelper::LibreOfficeKit::isActive()) +mpFrameView->SetGridVisible( false ); +else +mpFrameView->SetGridVisible( mpDrawView->IsGridVisible() ); + mpFrameView->SetGridFront( mpDrawView->IsGridFront() ); mpFrameView->SetSnapAngle( mpDrawView->GetSnapAngle() ); mpFrameView->SetGridSnap( mpDrawView->IsGridSnap() );
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast edited https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast edited https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -6,17 +6,21 @@
// RUN: %clang_cc1 -triple powerpc-ibm-aix -mlong-double-64 -emit-llvm -o - %s
| FileCheck -check-prefix=CHECK %s
// RUN: %clang_cc1 -triple powerpc64-ibm-aix -mlong-double-64 -emit-llvm -o -
%s | FileCheck -check-prefix=CHECK %s
+long double input = 0.0L;
+
int main()
{
int DummyInt;
long double DummyLongDouble;
long double returnValue;
returnValue = __builtin_modfl(1.0L, );
- returnValue = __builtin_frexpl(0.0L, );
+ returnValue = __builtin_frexpl(input, );
hubert-reinterpretcast wrote:
Once the handling of the second parameter is corrected, the change to the test
should become unnecessary.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -14674,6 +14676,31 @@ static bool TryEvaluateBuiltinNaN(const ASTContext
,
return true;
}
+// Checks that the value x is in the range (-1;-0.5], [0.5; 1)
+static bool isInFrexpResultRange(const llvm::APFloat ) {
+ llvm::APFloat minusOne(x.getSemantics(), "-1.0");
+ llvm::APFloat minusHalf(x.getSemantics(), "-0.5");
+ llvm::APFloat half(x.getSemantics(), "0.5");
+ llvm::APFloat one(x.getSemantics(), "1.0");
+
+ return ((x.compare(minusOne) == llvm::APFloat::cmpGreaterThan &&
+ x.compare(minusHalf) != llvm::APFloat::cmpGreaterThan) ||
+ (x.compare(half) != llvm::APFloat::cmpLessThan &&
+ x.compare(one) == llvm::APFloat::cmpLessThan));
+}
+
+void FloatExprEvaluator::StoreExponent(LValue Pointer, int exp) {
+ const APValue::LValueBase Base = Pointer.getLValueBase();
+ auto *VD = const_cast(Base.dyn_cast());
+ if (auto *VarD = dyn_cast(VD)) {
+clang::IntegerLiteral *IL =
+clang::IntegerLiteral::Create(Info.Ctx, llvm::APSInt(32, exp),
+ Info.Ctx.IntTy, clang::SourceLocation());
+VarD->setInit(IL);
hubert-reinterpretcast wrote:
See use of `handleAssignment` for `__builtin_add_overflow`:
https://github.com/llvm/llvm-project/blob/b2d7d72ff2408dcc27048e08d50ac719ff03a89e/clang/lib/AST/ExprConstant.cpp#L13071
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
core.git: Branch 'distro/collabora/co-24.04' - sd/source
sd/source/ui/view/drviews5.cxx | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) New commits: commit 41130a39ad68310a0136605cbced1f191396c456 Author: Hubert Figuière AuthorDate: Mon May 20 11:15:35 2024 -0400 Commit: Caolán McNamara CommitDate: Mon May 20 18:36:02 2024 +0200 cool#9019: draw/impress: disable the Grid for now So that the grid isn't shown in the thumbnail. This will need to be reverted later for cool#7406 Change-Id: I01fbc7ebc9e33a27fb866b7ea6dbaaac68ae8f9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167872 Tested-by: Jenkins CollaboraOffice Reviewed-by: Caolán McNamara diff --git a/sd/source/ui/view/drviews5.cxx b/sd/source/ui/view/drviews5.cxx index 8583ecc182c7..fa744fe49bcd 100644 --- a/sd/source/ui/view/drviews5.cxx +++ b/sd/source/ui/view/drviews5.cxx @@ -315,7 +315,15 @@ void DrawViewShell::WriteFrameViewData() mpFrameView->SetGridCoarse( mpDrawView->GetGridCoarse() ); mpFrameView->SetGridFine( mpDrawView->GetGridFine() ); mpFrameView->SetSnapGridWidth(mpDrawView->GetSnapGridWidthX(), mpDrawView->GetSnapGridWidthY()); -mpFrameView->SetGridVisible( mpDrawView->IsGridVisible() ); + +// In LOK, Grid isn't implemented, and it appears in the slide thumbnails +// Remove this when Grid is implemented and/or thumbnails are fixed to no longer +// show the grid. +if (comphelper::LibreOfficeKit::isActive()) +mpFrameView->SetGridVisible( false ); +else +mpFrameView->SetGridVisible( mpDrawView->IsGridVisible() ); + mpFrameView->SetGridFront( mpDrawView->IsGridFront() ); mpFrameView->SetSnapAngle( mpDrawView->GetSnapAngle() ); mpFrameView->SetGridSnap( mpDrawView->IsGridSnap() );
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -3622,15 +3623,15 @@ def Fma : FPMathTemplate, LibBuiltin<"math.h"> {
def Fmax : FPMathTemplate, LibBuiltin<"math.h"> {
let Spellings = ["fmax"];
- let Attributes = [NoThrow, Const];
+ let Attributes = [NoThrow, Const, Constexpr];
hubert-reinterpretcast wrote:
Same comment re: making the non-prefixed versions `constexpr` only for C++23
and up.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -3622,15 +3623,15 @@ def Fma : FPMathTemplate, LibBuiltin<"math.h"> {
def Fmax : FPMathTemplate, LibBuiltin<"math.h"> {
let Spellings = ["fmax"];
- let Attributes = [NoThrow, Const];
+ let Attributes = [NoThrow, Const, Constexpr];
let Prototype = "T(T, T)";
let AddBuiltinPrefixedAlias = 1;
let OnlyBuiltinPrefixedAliasIsConstexpr = 1;
}
def Fmin : FPMathTemplate, LibBuiltin<"math.h"> {
let Spellings = ["fmin"];
- let Attributes = [NoThrow, Const];
+ let Attributes = [NoThrow, Const, Constexpr];
hubert-reinterpretcast wrote:
Same comment re: making the non-prefixed versions `constexpr` only for C++23
and up.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -14683,6 +14710,23 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexp:
+ case Builtin::BI__builtin_frexpf:
+ case Builtin::BI__builtin_frexpl: {
hubert-reinterpretcast wrote:
`__builtin_frexpf16` and `__builtin_frexp128` should probably be added at the
same time as the other `__builtin_*` cases.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -3452,9 +3452,10 @@ def Fmod : FPMathTemplate, LibBuiltin<"math.h"> {
def Frexp : FPMathTemplate, LibBuiltin<"math.h"> {
hubert-reinterpretcast wrote:
There is a separate `FrexpF16F128` that should probably also be updated.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -3452,9 +3452,10 @@ def Fmod : FPMathTemplate, LibBuiltin<"math.h"> {
def Frexp : FPMathTemplate, LibBuiltin<"math.h"> {
let Spellings = ["frexp"];
- let Attributes = [NoThrow];
+ let Attributes = [NoThrow, Constexpr];
hubert-reinterpretcast wrote:
> IMO we'd probably want to introduce the concept of "constexpr since C++xy".
@philnik777, are you envisioning something where `LangOptions` are passed into
`Builtin::Context::isConstantEvaluated`?
https://github.com/llvm/llvm-project/blob/fb2c6597e39e9e1a775525ea0236b2f89e46acff/clang/include/clang/Basic/Builtins.h#L279
I think the existing `Constexpr`/"`E`" attribute can be left alone for use in
"always `constexpr`" cases.
For the selectively-`constexpr` cases, `LibBuiltin` in
`clang/include/clang/Basic/BuiltinsBase.td` should have
`OnlyBuiltinPrefixedAliasIsConstexpr` renamed to
`BuiltinPrefixedAliasIsConstexpr`. Then adding a new string property for
`UnprefixedOnlyConstexprSince` makes sense to me. It can be encoded into
`Builtin::Info` (and I think using the `LangFeatures` enumeration from
`"clang/Basic/LangStandard.h"` is not terribly wrong).
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast edited https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -3452,9 +3452,10 @@ def Fmod : FPMathTemplate, LibBuiltin<"math.h"> {
def Frexp : FPMathTemplate, LibBuiltin<"math.h"> {
let Spellings = ["frexp"];
- let Attributes = [NoThrow];
+ let Attributes = [NoThrow, Constexpr];
hubert-reinterpretcast wrote:
The `Constexpr` here makes the non-`__builtin_`-prefixed version of the
function `constexpr` under all language levels.
I checked the code: The `OnlyBuiltinPrefixedAliasIsConstexpr` flag can _add_
`constexpr`-ness; it does not _restrict_ it.
For reference:
https://github.com/llvm/llvm-project/blob/702198fc9ac5dba392f9d9ba7c56467996343c0a/clang/utils/TableGen/ClangBuiltinsEmitter.cpp#L225-L226
We may need a new builtin attribute that expresses `constexpr` for the
non-prefixed functions only for C++23 and up (but we might end up with
C++26-and-up, etc. in the future). However, it seems making the non-prefixed
functions actually non-`constexpr` (as opposed to simply failing to evaluate)
is only a QoI concern (see
https://github.com/llvm/llvm-project/pull/88978#issuecomment-2119080104 for
more context).
@philnik777, thoughts?
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
hubert-reinterpretcast wrote:
> Some more thought is needed on how to handle the non-`__builtin_`-prefixed
> cases under non-C++23-or-higher language modes. The specific implications of
> those functions being non-`constexpr` under said modes (as required, for C++,
> by https://wg21.link/constexpr.functions) may determine the solution to apply
> in this PR.
It seems that Clang _does_ care whether or not a function is `constexpr`
(outside of an actual attempt to evaluate it during constant evaluation) when
it is trying to diagnose the pre-C++23 IFNDR situation of a `constexpr`
function that never produces a constant expression:
https://godbolt.org/z/hnfqrrrdM
```cpp
extern "C" double fmin(double, double); // expected-note {{declared here}}
constexpr double contrived() { return fmin(0., 0.); }
// expected-error@-1 {{constexpr function never produces a constant expression}}
// expected-note@-2 {{non-constexpr function 'fmin' cannot be used in a
constant expression}}
```
Aside: Clang checks the arguments before the function declaration.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
[[FREXP2:%.*]] = alloca double, align 8
+// LNX-NEXT:[[FREXP3:%.*]] = alloca double, align 8
+// LNX-NEXT:[[FREXP4:%.*]] = alloca float, align 4
+// LNX-NEXT:[[FREXP5:%.*]] = alloca float, align 4
+// LNX-NEXT:[[FREXP6:%.*]] = alloca float, align 4
+// LNX-NEXT:[[FREXP7:%.*]] = alloca float, align 4
+// LNX-NEXT:[[FREXP8:%.*]] = alloca x86_fp80, align 16
+// LNX-NEXT:store i32 0, ptr [[I]], align 4
+// LNX-NEXT:store double 1.30e+00, ptr [[MIN1]], align 8
+// LNX-NEXT:store double -0.00e+00, ptr [[MIN2]], align 8
+// LNX-NEXT:store double -0.00e+00, ptr [[MIN3]], align 8
+// LNX-NEXT:store float 0x7FF8, ptr [[MIN4]], align 4
+// LNX-NEXT:store float -1.00e+00, ptr [[MIN5]], align 4
+// LNX-NEXT:store float 0xFFF0, ptr [[MIN6]], align 4
+// LNX-NEXT:store float 0.00e+00, ptr [[MIN7]], align 4
+// LNX-NEXT:store x86_fp80 0xK4005F6E978D4FDF3B646, ptr [[MIN8]], align 16
+// LNX-NEXT:store double 1.524000e+01, ptr [[MAX1]], align 8
+// LNX-NEXT:store double 0.00e+00, ptr [[MAX2]], align 8
+// LNX-NEXT:store double 0.00e+00, ptr [[MAX3]], align 8
+// LNX-NEXT:store float -1.00e+00, ptr [[MAX4]], align 4
+// LNX-NEXT:store float 0x7FF0, ptr [[MAX5]], align 4
+// LNX-NEXT:store float 0.00e+00, ptr [[MAX6]], align 4
+// LNX-NEXT:store float 0x7FF8, ptr [[MAX7]], align 4
+// LNX-NEXT:store x86_fp80 0xK4008C540C49BA5E353F8, ptr [[MAX8]], align 16
+// LNX-NEXT:store double 0x3FEEDCCD, ptr [[FREXP1]], align 8
+// LNX-NEXT:store double 0.00e+00, ptr [[FREXP2]], align 8
+// LNX-NEXT:store double -0.00e+00, ptr [[FREXP3]], align 8
+// LNX-NEXT:store float 0x7FF8, ptr [[FREXP4]], align 4
+// LNX-NEXT:store float 0xFFF8, ptr [[FREXP5]], align 4
+// LNX-NEXT:store float 0x7FF0, ptr [[FREXP6]], align 4
+// LNX-NEXT:store float 0x7FF0, ptr [[FREXP7]], align 4
+// LNX-NEXT:store x86_fp80 0xK3FFE81A9FBE76C8B4396, ptr [[FREXP8]], align
16
+// LNX-NEXT:ret i32 0
+//
+int func()
+{
+ int i;
+
+ // fmin
+ constexpr double min1 = __builtin_fmin(15.24, 1.3);
+ constexpr double min2 = __builtin_fmin(-0.0, +0.0);
+ constexpr double min3 = __builtin_fmin(+0.0, -0.0);
+ constexpr float min4 = __builtin_fminf(NAN, NAN);
+ constexpr float min5 = __builtin_fminf(NAN, -1);
+ constexpr float min6 = __builtin_fminf(-INFINITY, 0);
+ constexpr float min7 = __builtin_fminf(INFINITY, 0);
+ constexpr long double min8 = __builtin_fminl(123.456L, 789.012L);
+
+ // fmax
+ constexpr double max1 = __builtin_fmax(15.24, 1.3);
+ constexpr double max2 = __builtin_fmax(-0.0, +0.0);
+ constexpr double max3 = __builtin_fmax(+0.0, -0.0);
+ constexpr float max4 = __builtin_fmaxf(NAN, -1);
+ constexpr float max5 = __builtin_fmaxf(+INFINITY, 0);
+ constexpr float max6 = __builtin_fmaxf(-INFINITY, 0);
+ constexpr float max7 = __builtin_fmaxf(NAN, NAN);
+ constexpr long double max8 = __builtin_fmaxl(123.456L, 789.012L);
+
+ // frexp
+ constexpr double frexp1 = __builtin_frexp(123.45, );
+ constexpr double frexp2 = __builtin_frexp(0.0, );
+ constexpr double frexp3 = __builtin_frexp(-0.0, );
+ constexpr float frexp4 = __builtin_frexpf(NAN, );
+ constexpr float frexp5 = __builtin_frexpf(-NAN, );
+ constexpr float frexp6 = __builtin_frexpf(INFINITY, );
+ constexpr float frexp7 = __builtin_frexpf(INFINITY, );
--------
hubert-reinterpretcast wrote:
Fix "copy/paste error":
```suggestion
constexpr float frexp6 = __builtin_frexpf(+INFINITY, );
constexpr float frexp7 = __builtin_frexpf(-INFINITY, );
```
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -0,0 +1,52 @@ +// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s +// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s hubert-reinterpretcast wrote: Duplicate this run line for `-std=c++20`. Modify the test to use the `__builtin_*` functions only for the `-std=c++20` case. Use the non-`__builtin_*` functions for the `-std=c++23` case. https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -14683,6 +14710,23 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexp:
hubert-reinterpretcast wrote:
The non-`__builtin_`-prefixed cases need to be added in as per @philnik777's
comment
(https://github.com/llvm/llvm-project/pull/88978#discussion_r1582059951). Same
for the other two function families.
Some more thought is needed on how to handle the non-`__builtin_`-prefixed
cases under non-C++23-or-higher language modes. The specific implications of
those functions being non-`constexpr` under said modes (as required, for C++,
by https://wg21.link/constexpr.functions) may determine the solution to apply
in this PR.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
[[FREXP2:%.*]] = alloca double, align 8
+// LNX-NEXT:[[FREXP3:%.*]] = alloca double, align 8
+// LNX-NEXT:[[FREXP4:%.*]] = alloca float, align 4
+// LNX-NEXT:[[FREXP5:%.*]] = alloca float, align 4
+// LNX-NEXT:[[FREXP6:%.*]] = alloca float, align 4
+// LNX-NEXT:[[FREXP7:%.*]] = alloca float, align 4
+// LNX-NEXT:[[FREXP8:%.*]] = alloca x86_fp80, align 16
+// LNX-NEXT:store i32 0, ptr [[I]], align 4
+// LNX-NEXT:store double 1.30e+00, ptr [[MIN1]], align 8
+// LNX-NEXT:store double -0.00e+00, ptr [[MIN2]], align 8
+// LNX-NEXT:store double -0.00e+00, ptr [[MIN3]], align 8
+// LNX-NEXT:store float 0x7FF8, ptr [[MIN4]], align 4
+// LNX-NEXT:store float -1.00e+00, ptr [[MIN5]], align 4
+// LNX-NEXT:store float 0xFFF0, ptr [[MIN6]], align 4
+// LNX-NEXT:store float 0.00e+00, ptr [[MIN7]], align 4
+// LNX-NEXT:store x86_fp80 0xK4005F6E978D4FDF3B646, ptr [[MIN8]], align 16
+// LNX-NEXT:store double 1.524000e+01, ptr [[MAX1]], align 8
+// LNX-NEXT:store double 0.00e+00, ptr [[MAX2]], align 8
+// LNX-NEXT:store double 0.00e+00, ptr [[MAX3]], align 8
+// LNX-NEXT:store float -1.00e+00, ptr [[MAX4]], align 4
+// LNX-NEXT:store float 0x7FF0, ptr [[MAX5]], align 4
+// LNX-NEXT:store float 0.00e+00, ptr [[MAX6]], align 4
+// LNX-NEXT:store float 0x7FF8, ptr [[MAX7]], align 4
+// LNX-NEXT:store x86_fp80 0xK4008C540C49BA5E353F8, ptr [[MAX8]], align 16
+// LNX-NEXT:store double 0x3FEEDCCD, ptr [[FREXP1]], align 8
+// LNX-NEXT:store double 0.00e+00, ptr [[FREXP2]], align 8
+// LNX-NEXT:store double -0.00e+00, ptr [[FREXP3]], align 8
+// LNX-NEXT:store float 0x7FF8, ptr [[FREXP4]], align 4
+// LNX-NEXT:store float 0xFFF8, ptr [[FREXP5]], align 4
+// LNX-NEXT:store float 0x7FF0, ptr [[FREXP6]], align 4
+// LNX-NEXT:store float 0x7FF0, ptr [[FREXP7]], align 4
+// LNX-NEXT:store x86_fp80 0xK3FFE81A9FBE76C8B4396, ptr [[FREXP8]], align
16
+// LNX-NEXT:ret i32 0
+//
+int func()
+{
+ int i;
+
+ // fmin
+ constexpr double min1 = __builtin_fmin(15.24, 1.3);
+ constexpr double min2 = __builtin_fmin(-0.0, +0.0);
+ constexpr double min3 = __builtin_fmin(+0.0, -0.0);
+ constexpr float min4 = __builtin_fminf(NAN, NAN);
+ constexpr float min5 = __builtin_fminf(NAN, -1);
+ constexpr float min6 = __builtin_fminf(-INFINITY, 0);
+ constexpr float min7 = __builtin_fminf(INFINITY, 0);
+ constexpr long double min8 = __builtin_fminl(123.456L, 789.012L);
+
+ // fmax
+ constexpr double max1 = __builtin_fmax(15.24, 1.3);
--------
hubert-reinterpretcast wrote:
Formatting nit:
```suggestion
constexpr double max1 = __builtin_fmax(15.24, 1.3);
```
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+extern "C" void abort() noexcept;
+extern "C" int write(int, const void*, unsigned long);
+
+#define assert(condition) \
+ do { \
+if (!(condition)) {\
+ write(2, "Assertion failed: ", 18); \
+ write(2, #condition, sizeof(#condition) - 1);\
+ write(2, "\n", 1); \
+ abort(); \
+} \
+ } while (false)
+
+int main() {
+int i;
+
+// fmin
+static_assert(__builtin_fmin(15.24, 1.3) == 1.3, "");
+static_assert(__builtin_fmin(-0.0, +0.0) == -0.0, "");
+static_assert(__builtin_fmin(+0.0, -0.0) == -0.0, "");
+assert(__builtin_isnan(__builtin_fminf(NAN,NAN)));
+assert(__builtin_isnan(__builtin_fminf(NAN, -1)));
+assert(__builtin_isnan(__builtin_fminf(-INFINITY, 0)));
+assert(__builtin_iszero(__builtin_fminf(+INFINITY, 0)));
+
+// frexp
+static_assert(__builtin_frexp(123.45, ) == 0.9644531250002);
hubert-reinterpretcast wrote:
Here is an example of checking both the fraction and exponent values by
"identity" instead of by comparisons.
```cpp
template constexpr bool is_same_val = false;
template constexpr bool is_same_val = true;
template
struct FrexpResult {
T fraction;
int exponent;
};
template
constexpr auto simulateFrexp(T value) {
FrexpResult result;
result.fraction = __builtin_frexp(value, );
return result;
}
static_assert(is_same_val);
```
https://godbolt.org/z/Whx6o5Y7E
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
hubert-reinterpretcast wrote: Re: https://github.com/llvm/llvm-project/pull/88978#discussion_r1578762448 > It means that INT_MAX and INT_MIN is fine (based on the wording). The committee reflector discussion reached a conclusion that this behaviour is okay. Implementations need not agree on the values. Indeed, an implementation is not required to consistently produce the same value. https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -14638,6 +14649,8 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
return true;
}
+ case Builtin::BIfmin:
+ case Builtin::BIfminf:
hubert-reinterpretcast wrote:
At the Clang C/C++ Language Workgroup call on 2024-05-15, it was agreed that
`-fno-builtin[-*]` should remain capable of disabling built-in treatment even
when that treatment would be required for conformance w.r.t. `constexpr`
behaviour of functions shared with C.
For me, the first expectation for this PR (on that subject) is an update to the
documentation of `-fno-builtin[-*]`.
@AaronBallman @ldionne, I am no sure how we want to handle this w.r.t.
documenting the C++23 implementation status. Does it go in both the Clang
documentation (for the functions shared with C) and the libc++ documentation
(for the overloads added by C++)?
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -2922,7 +2922,7 @@ static bool handleFloatFloatBinOp(EvalInfo , const
BinaryOperator *E,
// If during the evaluation of an expression, the result is not
// mathematically defined [...], the behavior is undefined.
// FIXME: C++ rules require us to not conform to IEEE 754 here.
- if (LHS.isNaN()) {
+ if (!Info.getLangOpts().CPlusPlus23 && LHS.isNaN()) {
----
hubert-reinterpretcast wrote:
I do not think there is any particular reason why this change is C++23 specific.
The question remains whether the change should be made at all.
If the primary rationale here is to facilitate testing using the Windows header
definitions, I suspect the answer is that the Windows definition of NaN is not
a C++ constant expression.
@jcranmer-intel's comment
(https://github.com/llvm/llvm-project/pull/88978/files#discussion_r1576817678),
supports the interpretation that operations that result in NaN from non-qNaN
inputs are not valid in a constant expression.
Other than wanting to use the Windows header definitions for the tests here, is
there a reason why this change belongs in this PR?
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast edited https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -14574,9 +14574,17 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexpl:
+// AIX library function `frexpl` has 'long double' type and not
+// PPCDoubleDouble type. To make sure we generate the right value, don't
+// constant evaluate it and instead defer to a libcall.
+if (Info.Ctx.getTargetInfo().getTriple().isPPC() &&
+(().getLongDoubleFormat() !=
+ ::APFloat::PPCDoubleDouble()))
+ return false;
+LLVM_FALLTHROUGH;
case Builtin::BI__builtin_frexp:
- case Builtin::BI__builtin_frexpf:
- case Builtin::BI__builtin_frexpl: {
+ case Builtin::BI__builtin_frexpf: {
----
hubert-reinterpretcast wrote:
> I was referring to
> https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGBuiltin.cpp#L3543.
That affects the IR generated by Clang when Clang _does not_ constant-evaluate
(and was motivated by backend issues).
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -14574,9 +14574,17 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexpl:
+// AIX library function `frexpl` has 'long double' type and not
+// PPCDoubleDouble type. To make sure we generate the right value, don't
+// constant evaluate it and instead defer to a libcall.
+if (Info.Ctx.getTargetInfo().getTriple().isPPC() &&
+(().getLongDoubleFormat() !=
+ ::APFloat::PPCDoubleDouble()))
+ return false;
+LLVM_FALLTHROUGH;
case Builtin::BI__builtin_frexp:
- case Builtin::BI__builtin_frexpf:
- case Builtin::BI__builtin_frexpl: {
+ case Builtin::BI__builtin_frexpf: {
----
hubert-reinterpretcast wrote:
> With this change (special casing frexpl for AIX) the IR produced is: `call {
> double, i32 } @llvm.frexp.f64.i32(double 1.234500e+02)`
>
> without this change the IR is: `store double 0.00e+00, ptr %returnValue,
> align 8`
>
> This doesn't seem correct to me.
Ignoring considerations around storing to `DummyInt`, the original test code
was:
```
returnValue = __builtin_frexpl(0.0L, );
```
I don't know where the `123.45` came from. That the result is zero for an input
of zero is correct.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -14574,9 +14574,17 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexpl:
+// AIX library function `frexpl` has 'long double' type and not
+// PPCDoubleDouble type. To make sure we generate the right value, don't
+// constant evaluate it and instead defer to a libcall.
+if (Info.Ctx.getTargetInfo().getTriple().isPPC() &&
+(().getLongDoubleFormat() !=
+ ::APFloat::PPCDoubleDouble()))
+ return false;
+LLVM_FALLTHROUGH;
case Builtin::BI__builtin_frexp:
- case Builtin::BI__builtin_frexpf:
- case Builtin::BI__builtin_frexpl: {
+ case Builtin::BI__builtin_frexpf: {
----
hubert-reinterpretcast wrote:
> Does the evaluation produce the same results as would happen at runtime
> despite the different format?
There is no different format. The default format for the `long double` type on
AIX (and the only one supported by Clang for AIX) is IEEE double.
The IR generated for basic `long double` operations might clarify:
https://godbolt.org/z/W4jqr6Kva
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -14574,9 +14574,17 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexpl:
+// AIX library function `frexpl` has 'long double' type and not
+// PPCDoubleDouble type. To make sure we generate the right value, don't
+// constant evaluate it and instead defer to a libcall.
+if (Info.Ctx.getTargetInfo().getTriple().isPPC() &&
+(().getLongDoubleFormat() !=
+ ::APFloat::PPCDoubleDouble()))
+ return false;
+LLVM_FALLTHROUGH;
case Builtin::BI__builtin_frexp:
- case Builtin::BI__builtin_frexpf:
- case Builtin::BI__builtin_frexpl: {
+ case Builtin::BI__builtin_frexpf: {
----
hubert-reinterpretcast wrote:
The comment is incorrect. The _actual_ AIX library function `frexpl` has (some
version of) `PPCDoubleDouble` type. Because of that, Clang (which only supports
64-bit `long double` on AIX) has to map calls to `__builtin_frexpl` to `frexp`.
For compile-time evaluation, the `APFloat`s associated with `long double` on
AIX have the IEEE double format (and the evaluation works fine).
The solution to the failing test is to change it. The problem with the test is
that the first input argument is a constant; changing it to refer to a global
variable should work.
https://github.com/llvm/llvm-project/blob/566fbb450092bf8c9f966a6ab1b0381626e3e535/clang/test/CodeGen/aix-builtin-mapping.c#L16
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast edited https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -14572,6 +14572,9 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
int FrexpExp;
llvm::RoundingMode RM = getActiveRoundingMode(Info, E);
Result = llvm::frexp(Result, FrexpExp, RM);
+if (!Result.isZero() && !Result.isNaN() && !Result.isInfinity())
+ assert(llvm::APFloat::isInRange(Result) &&
+"The value is not in the expected range for frexp.");
hubert-reinterpretcast wrote:
assert((Result.isZero() || Result.isNaN() || Result.isInfinity() || ...) &&
"...");
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
@@ -951,6 +951,19 @@ class APFloat : public APFloatBase {
bool needsCleanup() const { APFLOAT_DISPATCH_ON_SEMANTICS(needsCleanup()); }
+ // Checks that the value x is in the range (-1;-0.5], [0.5; 1)
+ static bool isInRange(const llvm::APFloat ) {
hubert-reinterpretcast wrote:
I don't think this should be a member function of `APFloat`. It can be an
implementation detail of `ExprConstant.cpp`. In either case, the function
should be named something like `isInFrexpResultRange`.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin, fmax and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast commented: Partial review comments. https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
core.git: sfx2/source
sfx2/source/control/unoctitm.cxx |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
New commits:
commit fd0a249ad1f4a55677e97bd6355e5316a863f9e6
Author: Hubert Figuière
AuthorDate: Wed May 8 17:34:47 2024 -0400
Commit: Caolán McNamara
CommitDate: Thu May 9 17:13:37 2024 +0200
lokit: Properly handle state update for .uno:ToggleSheetGrid
This is a follow up on cool#8066
Signed-off-by: Hubert Figuière
Change-Id: I7d6ce4c9dfe7c2e9a2dda110e587c8c825c4df2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167370
Reviewed-by: Szymon Kłos
Tested-by: Jenkins CollaboraOffice
(cherry picked from commit 9bbe40cc2d39f89ffcae57875d4c7ef7688d83d7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167317
Tested-by: Jenkins
Reviewed-by: Caolán McNamara
diff --git a/sfx2/source/control/unoctitm.cxx b/sfx2/source/control/unoctitm.cxx
index 7d518f435d81..6fb25977796e 100644
--- a/sfx2/source/control/unoctitm.cxx
+++ b/sfx2/source/control/unoctitm.cxx
@@ -940,8 +940,7 @@ static void InterceptLOKStateChangeEvent(sal_uInt16 nSID,
SfxViewFrame* pViewFra
aEvent.FeatureURL.Path == "SpacePara15" ||
aEvent.FeatureURL.Path == "SpacePara2" ||
aEvent.FeatureURL.Path == "DataFilterAutoFilter" ||
-aEvent.FeatureURL.Path == "CellProtection" ||
-aEvent.FeatureURL.Path == "ToggleSheetGrid")
+aEvent.FeatureURL.Path == "CellProtection")
{
bool bTemp = false;
aEvent.State >>= bTemp;
@@ -1222,7 +1221,8 @@ static void InterceptLOKStateChangeEvent(sal_uInt16 nSID,
SfxViewFrame* pViewFra
}
}
else if (aEvent.FeatureURL.Path == "ToggleMergeCells" ||
- aEvent.FeatureURL.Path == "SheetRightToLeft")
+ aEvent.FeatureURL.Path == "SheetRightToLeft" ||
+ aEvent.FeatureURL.Path == "ToggleSheetGrid")
{
bool aBool;
core.git: Branch 'distro/collabora/co-24.04' - sfx2/source
sfx2/source/control/unoctitm.cxx |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
New commits:
commit 9bbe40cc2d39f89ffcae57875d4c7ef7688d83d7
Author: Hubert Figuière
AuthorDate: Wed May 8 17:34:47 2024 -0400
Commit: Szymon Kłos
CommitDate: Thu May 9 08:52:37 2024 +0200
lokit: Properly handle state update for .uno:ToggleSheetGrid
This is a follow up on cool#8066
Signed-off-by: Hubert Figuière
Change-Id: I7d6ce4c9dfe7c2e9a2dda110e587c8c825c4df2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167370
Reviewed-by: Szymon Kłos
Tested-by: Jenkins CollaboraOffice
diff --git a/sfx2/source/control/unoctitm.cxx b/sfx2/source/control/unoctitm.cxx
index 6572761c11ea..d289cd2616a8 100644
--- a/sfx2/source/control/unoctitm.cxx
+++ b/sfx2/source/control/unoctitm.cxx
@@ -940,8 +940,7 @@ static void InterceptLOKStateChangeEvent(sal_uInt16 nSID,
SfxViewFrame* pViewFra
aEvent.FeatureURL.Path == "SpacePara15" ||
aEvent.FeatureURL.Path == "SpacePara2" ||
aEvent.FeatureURL.Path == "DataFilterAutoFilter" ||
-aEvent.FeatureURL.Path == "CellProtection" ||
-aEvent.FeatureURL.Path == "ToggleSheetGrid")
+aEvent.FeatureURL.Path == "CellProtection")
{
bool bTemp = false;
aEvent.State >>= bTemp;
@@ -1224,7 +1223,8 @@ static void InterceptLOKStateChangeEvent(sal_uInt16 nSID,
SfxViewFrame* pViewFra
}
}
else if (aEvent.FeatureURL.Path == "ToggleMergeCells" ||
- aEvent.FeatureURL.Path == "SheetRightToLeft")
+ aEvent.FeatureURL.Path == "SheetRightToLeft" ||
+ aEvent.FeatureURL.Path == "ToggleSheetGrid")
{
bool aBool;
[kicad] Re: Question on compilation/linking
Thanks Mark, where can I find this modification ? Le mardi 7 mai 2024 à 21:38:46 UTC-4, mark@gmail.com a écrit : > You were trying to use libeval which lived in `common` inside common.cpp > which lives in `kicommon` > > `common` -> static library, depends on kicommon > `kicommon` -> shared library, cannot depend on common > > So that's just invalid. Yea theres two libraries, they are slowly being > moved to kicommon as bad code boundaries are refactored. > > In this case, I moved libeval to kicommon for you. > > On Tuesday, May 7, 2024 at 1:17:34 PM UTC-4 huber...@gmail.com wrote: > >> Hey guys, thanks for welcoming me in this group. >> >> I don't know if it's the right place to ask this question, let me know if >> another place would suit better. >> >> I was trying to work on integrating math evaluation in variable >> substitution brackets in eeschema and pcbnew. I dove into the code and >> write something that looks promising. I wanted to show this to you. I >> hadn't pulled modifications for 3 months. When pulling and rebasing my >> code, it wasn't not compiling anymore. Here is the error I got : >> https://gitlab.com/montagnard.py/kicad/-/jobs/6782065751 >> >> Indeed, common/CMakeFiles/common.dir/libeval/numeric_evaluator.cpp.o is >> compiled with fvisibility=hidden flag and no symbol are exported. >> >> Now i don't understand how my code compiled before. I am a bit lost in >> the compilation process, can you help me understand or give me some insight >> on how to debug thos type of things. Mainly i ran ninja -nv | grep >> numeric_evaluator >> >> Am I using the right strategy to use libeval.cpp ? >> >> Thanks for your time, >> Samuel >> > -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to devlist+unsubscr...@kicad.org. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/c8e371ce-6a68-437b-9b37-d540aba1618bn%40kicad.org.
[clang] [driver] Only check for unused plugin options (PR #91522)
https://github.com/hubert-reinterpretcast approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/91522 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [driver] Only check for unused plugin options (PR #91522)
@@ -23,5 +23,5 @@
// Plugins are only relevant for the -cc1 phase. No warning should be raised
// when only using the assembler. See GH #88173.
-// RUN: %clang -c -fpass-plugin=bar.so -fplugin=bar.so -fplugin-arg-bar-option
-Werror -x assembler %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-PLUGIN-ASM
-// CHECK-PLUGIN-ASM-NOT: argument unused during compilation
+// RUN: %clang -c -fpass-plugin=bar.so -fplugin=bar.so -fplugin-arg-bar-option
-Wunused-command-line-argument -x assembler %s -### 2>&1 | FileCheck %s
--check-prefix=CHECK-PLUGIN-ASM
+// CHECK-PLUGIN-ASM-NOT: argument unused during compilation:
'-f{{[a-z-]*-plugin[^']*}}'
--------
hubert-reinterpretcast wrote:
Sorry for my mistake "offline"; we want to catch `-fplugin*` too:
```suggestion
// CHECK-PLUGIN-ASM-NOT: argument unused during compilation:
'-f{{[a-z-]*plugin[^']*}}'
```
https://github.com/llvm/llvm-project/pull/91522
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[kicad] Question on compilation/linking
Hey guys, thanks for welcoming me in this group. I don't know if it's the right place to ask this question, let me know if another place would suit better. I was trying to work on integrating math evaluation in variable substitution brackets in eeschema and pcbnew. I dove into the code and write something that looks promising. I wanted to show this to you. I hadn't pulled modifications for 3 months. When pulling and rebasing my code, it wasn't not compiling anymore. Here is the error I got : https://gitlab.com/montagnard.py/kicad/-/jobs/6782065751 Indeed, common/CMakeFiles/common.dir/libeval/numeric_evaluator.cpp.o is compiled with fvisibility=hidden flag and no symbol are exported. Now i don't understand how my code compiled before. I am a bit lost in the compilation process, can you help me understand or give me some insight on how to debug thos type of things. Mainly i ran ninja -nv | grep numeric_evaluator Am I using the right strategy to use libeval.cpp ? Thanks for your time, Samuel -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to devlist+unsubscr...@kicad.org. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/f65a957a-effe-4796-9a66-3465ca7d2e52n%40kicad.org.
[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt ) {
incrementProfileCounter();
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCodeGenOpts().getFiniteLoops() ==
+ CodeGenOptions::FiniteLoopsKind::Never)
+return false;
+
+ // Now apply rules for plain C (see 6.8.5.6 in C11).
+ // Loops with constant conditions do not have to make progress in any C
+ // version.
+ // As an extension, we consisider loops whose constant expression
+ // can be constant-folded.
+ Expr::EvalResult Result;
+ bool CondIsConstInt =
hubert-reinterpretcast wrote:
> So... we treat it as a manifestly constant-evaluated for the purpose of
> checking whether the loop is trivial, but then flips to not manifestly
> constant-evaluated for the actual evaluation at runtime?
Yes.
> The wording could use some clarification...
The absence of wording to change the condition itself (that is, what is used at
runtime) to be manifestly constant-evaluated is intentional. This wording is
not unique. It is also used for the _determination_ of constant initialization,
which #89565 (that you referred to) points out is also broken in Clang
(however, in contrast to the condition case, once determined to be constant
initialization, the initializer itself is considered manifestly
constant-evaluated).
> Maybe we can run constant-evaluation before Sema::CheckForImmediateInvocation
> runs, though.
I think that makes sense. The _constant-expression_ that we are evaluating
introduces an immediate function context that suppresses immediate invocations
(https://eel.is/c++draft/expr.const#16).
Example:
```cpp
struct A {
constexpr A(const int ) : p() {}
const int *p;
};
consteval A a() { return {42}; }
enum { X = (a(), 0) }; // OK, no immediate invocations; Clang and GCC both
accept
```
https://github.com/llvm/llvm-project/pull/90066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: \dt shows table but \d says the table doesn't exist ?
On Fri, May 03, 2024 at 04:58:26PM -0400, David Gauthier wrote: > Soo... what am I missing ? > owner is "cron_user". \dt shows cron_user is the owner of the table. Magnus already helped you, but you might want to check this: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_upper_case_table_or_column_names and generally read the whole "Don't Do This" wiki page. Best regards, depesz
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+int main() {
+int i;
+
+// fmin
+static_assert(__builtin_fmin(15.24, 1.3) == 1.3, "");
+static_assert(__builtin_fmin(-0.0, +0.0) == -0.0, "");
+static_assert(__builtin_fmin(+0.0, -0.0) == -0.0, "");
hubert-reinterpretcast wrote:
... also, optional `static_assert` message should be removed if not used in a
helpful manner.
Example (please apply to other lines too):
```suggestion
static_assert(is_same_val<__builtin_fmin(-0.0, +0.0), -0.0>);
static_assert(is_same_val<__builtin_fmin(+0.0, -0.0), -0.0>);
```
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \
+// RUN: -DWIN -emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN
+
+// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \
+// RUN: -emit-llvm -o - %s | FileCheck %s --check-prefixes=LNX
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+int func()
+{
+ int i;
+
+ // fmin
+ constexpr double f1 = __builtin_fmin(15.24, 1.3);
+ constexpr double f2 = __builtin_fmin(-0.0, +0.0);
+ constexpr double f3 = __builtin_fmin(+0.0, -0.0);
+ constexpr float f4 = __builtin_fminf(NAN, NAN);
+ constexpr float f5 = __builtin_fminf(NAN, -1);
+ constexpr float f6 = __builtin_fminf(-INFINITY, 0);
+ constexpr float f7 = __builtin_fminf(INFINITY, 0);
+ constexpr long double f8 = __builtin_fminl(123.456L, 789.012L);
+
+ // frexp
+ constexpr double f9 = __builtin_frexp(123.45, );
+ constexpr double f10 = __builtin_frexp(0.0, );
+ constexpr double f11 = __builtin_frexp(-0.0, );
+ constexpr double f12 = __builtin_frexpf(NAN, );
+ constexpr double f13 = __builtin_frexpf(-NAN, );
+ constexpr double f14 = __builtin_frexpf(INFINITY, );
--------
hubert-reinterpretcast wrote:
Copy/paste errors?
```suggestion
constexpr float f12 = __builtin_frexpf(NAN, );
constexpr float f13 = __builtin_frexpf(-NAN, );
constexpr float f14 = __builtin_frexpf(INFINITY, );
```
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,59 @@ +// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \ +// RUN: -DWIN -emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN + +// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \ +// RUN: -emit-llvm -o - %s | FileCheck %s --check-prefixes=LNX hubert-reinterpretcast wrote: None of the `CHECK` lines were being checked... ```suggestion // RUN: -DWIN -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,WIN // RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \ // RUN: -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,LNX ``` https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \
+// RUN: -DWIN -emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN
+
+// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \
+// RUN: -emit-llvm -o - %s | FileCheck %s --check-prefixes=LNX
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+int func()
+{
+ int i;
+
+ // fmin
+ constexpr double f1 = __builtin_fmin(15.24, 1.3);
+ constexpr double f2 = __builtin_fmin(-0.0, +0.0);
+ constexpr double f3 = __builtin_fmin(+0.0, -0.0);
+ constexpr float f4 = __builtin_fminf(NAN, NAN);
+ constexpr float f5 = __builtin_fminf(NAN, -1);
+ constexpr float f6 = __builtin_fminf(-INFINITY, 0);
+ constexpr float f7 = __builtin_fminf(INFINITY, 0);
+ constexpr long double f8 = __builtin_fminl(123.456L, 789.012L);
+
+ // frexp
+ constexpr double f9 = __builtin_frexp(123.45, );
+ constexpr double f10 = __builtin_frexp(0.0, );
+ constexpr double f11 = __builtin_frexp(-0.0, );
+ constexpr double f12 = __builtin_frexpf(NAN, );
+ constexpr double f13 = __builtin_frexpf(-NAN, );
+ constexpr double f14 = __builtin_frexpf(INFINITY, );
+ constexpr double f15 = __builtin_frexpf(INFINITY, );
+ constexpr long double f16 = __builtin_frexpl(259.328L, );
+
+ return 0;
+}
+
+// CHECK: store double 1.30e+00, ptr {{.*}}
+// CHECK: store double -0.00e+00, ptr {{.*}}
+// CHECK: store double -0.00e+00, ptr {{.*}}
+// WIN: store float 0xFFF8, ptr {{.*}}
+// LNX: store float 0x7FF8, ptr {{.*}}
+// CHECK: store float -1.00e+00, ptr {{.*}}
+// CHECK: store float 0xFFF0, ptr {{.*}}
--------
hubert-reinterpretcast wrote:
This only checks three of the four `float` values. Maybe the test can use
`CHECK-NEXT`, `WIN-NEXT`, etc.?
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+int main() {
+int i;
+
+// fmin
+static_assert(__builtin_fmin(15.24, 1.3) == 1.3, "");
+static_assert(__builtin_fmin(-0.0, +0.0) == -0.0, "");
+static_assert(__builtin_fmin(+0.0, -0.0) == -0.0, "");
+static_assert(__builtin_fminf(NAN, -1) == -1, "");
+static_assert(__builtin_fminf(+INFINITY, 0) == 0, "");
+static_assert(__builtin_isinf(__builtin_fminf(-INFINITY, 0)), "");
+static_assert(__builtin_isnan(__builtin_fminf(NAN,NAN)), "");
+
+// frexp
+static_assert(__builtin_frexp(123.45, ) == 0.9644531250002);
hubert-reinterpretcast wrote:
Use `123.45 / 128.` instead of `0.9644531250002`.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+int main() {
--------
hubert-reinterpretcast wrote:
Use identity instead of comparisons/classifications for validation:
```suggestion
template constexpr bool is_same_val = false;
template constexpr bool is_same_val = true;
int main() {
```
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \
+// RUN: -DWIN -emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN
+
+// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \
+// RUN: -emit-llvm -o - %s | FileCheck %s --check-prefixes=LNX
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+int func()
+{
+ int i;
+
+ // fmin
+ constexpr double f1 = __builtin_fmin(15.24, 1.3);
+ constexpr double f2 = __builtin_fmin(-0.0, +0.0);
+ constexpr double f3 = __builtin_fmin(+0.0, -0.0);
+ constexpr float f4 = __builtin_fminf(NAN, NAN);
+ constexpr float f5 = __builtin_fminf(NAN, -1);
+ constexpr float f6 = __builtin_fminf(-INFINITY, 0);
+ constexpr float f7 = __builtin_fminf(INFINITY, 0);
+ constexpr long double f8 = __builtin_fminl(123.456L, 789.012L);
+
+ // frexp
+ constexpr double f9 = __builtin_frexp(123.45, );
+ constexpr double f10 = __builtin_frexp(0.0, );
+ constexpr double f11 = __builtin_frexp(-0.0, );
+ constexpr double f12 = __builtin_frexpf(NAN, );
+ constexpr double f13 = __builtin_frexpf(-NAN, );
+ constexpr double f14 = __builtin_frexpf(INFINITY, );
+ constexpr double f15 = __builtin_frexpf(INFINITY, );
--------
hubert-reinterpretcast wrote:
Copy/paste errors?
```suggestion
constexpr float f15 = __builtin_frexpf(-INFINITY, );
```
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+int main() {
+int i;
+
+// fmin
+static_assert(__builtin_fmin(15.24, 1.3) == 1.3, "");
+static_assert(__builtin_fmin(-0.0, +0.0) == -0.0, "");
+static_assert(__builtin_fmin(+0.0, -0.0) == -0.0, "");
+static_assert(__builtin_fminf(NAN, -1) == -1, "");
+static_assert(__builtin_fminf(+INFINITY, 0) == 0, "");
+static_assert(__builtin_isinf(__builtin_fminf(-INFINITY, 0)), "");
+static_assert(__builtin_isnan(__builtin_fminf(NAN,NAN)), "");
+
+// frexp
+static_assert(__builtin_frexp(123.45, ) == 0.9644531250002);
+static_assert(!__builtin_isnan(__builtin_frexp(123.45, )), "");
hubert-reinterpretcast wrote:
Why is this necessary?
```suggestion
```
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt ) {
incrementProfileCounter();
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCodeGenOpts().getFiniteLoops() ==
+ CodeGenOptions::FiniteLoopsKind::Never)
+return false;
+
+ // Now apply rules for plain C (see 6.8.5.6 in C11).
+ // Loops with constant conditions do not have to make progress in any C
+ // version.
+ // As an extension, we consisider loops whose constant expression
+ // can be constant-folded.
+ Expr::EvalResult Result;
+ bool CondIsConstInt =
hubert-reinterpretcast wrote:
> As a standards-wording issue, the standard has to do something here
This was extensively discussed in CWG. The wording makes the evaluation for the
purposes of determining whether the loop is trivially infinite a manifestly
constant-evaluated context. It leaves the normal evaluation as not a manifestly
constant-evaluated context.
The operative words are "interpreted as a _constant-expression_" in
https://eel.is/c++draft/stmt.iter.general#3.
https://github.com/llvm/llvm-project/pull/90066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -14547,6 +14547,20 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexp:
+ case Builtin::BI__builtin_frexpf:
+ case Builtin::BI__builtin_frexpl: {
+LValue Pointer;
+if (!EvaluateFloat(E->getArg(0), Result, Info) ||
+!EvaluatePointer(E->getArg(1), Pointer, Info))
+ return false;
+llvm::RoundingMode RM = getActiveRoundingMode(Info, E);
+int FrexpExp;
+FrexpExp = ilogb(Result);
+FrexpExp = FrexpExp == llvm::detail::IEEEFloat::IEK_Zero ? 0 : FrexpExp +
1;
+Result = scalbn(Result, -FrexpExp, RM);
----
hubert-reinterpretcast wrote:
This is not an improvement over
https://github.com/llvm/llvm-project/blob/d7050b53a75a23024502a9e4f56b385256c4722f/clang/lib/AST/ExprConstant.cpp#L14558
It is still the case that no attempt is made to store the value of `FrexpExp`
via `Pointer`.
Additionally, (although potentially "better" than the status quo of
`llvm::frexp`) this adds yet another place where the calculation for IBM
double-double would potentially need special maintenance. See
https://github.com/llvm/llvm-project/issues/90287.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt ) {
incrementProfileCounter();
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCodeGenOpts().getFiniteLoops() ==
+ CodeGenOptions::FiniteLoopsKind::Never)
+return false;
+
+ // Now apply rules for plain C (see 6.8.5.6 in C11).
+ // Loops with constant conditions do not have to make progress in any C
+ // version.
+ // As an extension, we consisider loops whose constant expression
+ // can be constant-folded.
+ Expr::EvalResult Result;
+ bool CondIsConstInt =
hubert-reinterpretcast wrote:
The following does not have UB according to the standard, but Clang treats it
as UB:
```
int main(void) {
int x = 1;
while (__builtin_is_constant_evaluated() || x);
return 0;
}
```
https://github.com/llvm/llvm-project/pull/90066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)
https://github.com/hubert-reinterpretcast commented: @cor3ntin, can you take a look at the case I added? Thanks. https://github.com/llvm/llvm-project/pull/90066 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)
https://github.com/hubert-reinterpretcast edited https://github.com/llvm/llvm-project/pull/90066 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[jira] [Updated] (EMAIL-209) InputStreamDataSource#getInputStream() violates javax.activation.DataSource contract
[ https://issues.apache.org/jira/browse/EMAIL-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Hubert updated EMAIL-209: -- Description: After upgrading from commons-email 1.5 to 1.6.0 an integration test of a custom MessageHandler implementation taking care of attachments broke, as attachments were no longer correctly processed. I had a brief look at this custom implementation and noticed that org.apache.commons.mail.util.MimeMessageParser#getAttachmentList was used to retrieve the list of attachment data source and processed it twice relying on the javax.activation.DataSource contract of #getInputStream(): "Note that a new InputStream object must be returned each time this method is called, and the stream must be positioned at the beginning of the data." which was working just fine with commons-email 1.5 being backed by javax.mail.util.ByteArrayDataSource. It looks like with EMAIL-207 a new implementation org.apache.commons.mail.activation.InputStreamDataSource was introduced which current implementation seems to violate this contract. Calling getInputStream does not provide a fresh InputStream at the beginning of the data, but returns the existing object in the state of the previous usage, resulting in incomplete data processing. was: After upgrading from commons-email 1.5 to 1.6.0 an integration test of a custom MessageHandler implementation taking care of attachment broke, as attachments were no longer correctly processed. I had a brief look at this custom implementation and noticed that org.apache.commons.mail.util.MimeMessageParser#getAttachmentList was used to retrieve the list of attachment data source and processed it twice relying on the javax.activation.DataSource contract of #getInputStream(): "Note that a new InputStream object must be returned each time this method is called, and the stream must be positioned at the beginning of the data." which was working just fine with commons-email 1.5 being backed by javax.mail.util.ByteArrayDataSource. It looks like with EMAIL-207 a new implementation org.apache.commons.mail.activation.InputStreamDataSource was introduced which current implementation seems to violate this contract. Calling getInputStream does not provide a fresh InputStream at the beginning of the data, but returns the existing object in the state of the previous usage, resulting in incomplete data processing. > InputStreamDataSource#getInputStream() violates javax.activation.DataSource > contract > > > Key: EMAIL-209 > URL: https://issues.apache.org/jira/browse/EMAIL-209 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Eric Hubert >Priority: Major > > After upgrading from commons-email 1.5 to 1.6.0 an integration test of a > custom MessageHandler implementation taking care of attachments broke, as > attachments were no longer correctly processed. > I had a brief look at this custom implementation and noticed that > org.apache.commons.mail.util.MimeMessageParser#getAttachmentList > was used to retrieve the list of attachment data source and processed it > twice relying on the javax.activation.DataSource contract of > #getInputStream(): > "Note that a new InputStream object must be returned each time this method is > called, and the stream must be positioned at the beginning of the data." > which was working just fine with commons-email 1.5 being backed by > javax.mail.util.ByteArrayDataSource. > It looks like with EMAIL-207 a new implementation > org.apache.commons.mail.activation.InputStreamDataSource was introduced which > current implementation seems to violate this contract. Calling getInputStream > does not provide a fresh InputStream at the beginning of the data, but > returns the existing object in the state of the previous usage, resulting in > incomplete data processing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (EMAIL-209) InputStreamDataSource#getInputStream() violates javax.activation.DataSource contract
Eric Hubert created EMAIL-209: - Summary: InputStreamDataSource#getInputStream() violates javax.activation.DataSource contract Key: EMAIL-209 URL: https://issues.apache.org/jira/browse/EMAIL-209 Project: Commons Email Issue Type: Bug Affects Versions: 1.6.0 Reporter: Eric Hubert After upgrading from commons-email 1.5 to 1.6.0 an integration test of a custom MessageHandler implementation taking care of attachment broke, as attachments were no longer correctly processed. I had a brief look at this custom implementation and noticed that org.apache.commons.mail.util.MimeMessageParser#getAttachmentList was used to retrieve the list of attachment data source and processed it twice relying on the javax.activation.DataSource contract of #getInputStream(): "Note that a new InputStream object must be returned each time this method is called, and the stream must be positioned at the beginning of the data." which was working just fine with commons-email 1.5 being backed by javax.mail.util.ByteArrayDataSource. It looks like with EMAIL-207 a new implementation org.apache.commons.mail.activation.InputStreamDataSource was introduced which current implementation seems to violate this contract. Calling getInputStream does not provide a fresh InputStream at the beginning of the data, but returns the existing object in the state of the previous usage, resulting in incomplete data processing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast edited https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+extern "C" void abort() noexcept;
+extern "C" int write(int, const void*, unsigned long);
+
+#define assert(condition) \
+ do { \
+if (!(condition)) {\
+ write(2, "Assertion failed: ", 18); \
+ write(2, #condition, sizeof(#condition) - 1);\
+ write(2, "\n", 1); \
+ abort(); \
+} \
+ } while (false)
+
+int main() {
+int i;
+
+// fmin
+static_assert(__builtin_fmin(15.24, 1.3) == 1.3, "");
+static_assert(__builtin_fmin(-0.0, +0.0) == -0.0, "");
+static_assert(__builtin_fmin(+0.0, -0.0) == -0.0, "");
+assert(__builtin_isnan(__builtin_fminf(NAN,NAN)));
+assert(__builtin_isnan(__builtin_fminf(NAN, -1)));
+assert(__builtin_isnan(__builtin_fminf(-INFINITY, 0)));
+assert(__builtin_iszero(__builtin_fminf(+INFINITY, 0)));
+
+// frexp
+static_assert(__builtin_frexp(123.45, ) == 0.9644531250002);
hubert-reinterpretcast wrote:
@zahiraam, make `simulateFrexp` a `constexpr` function (maybe with `float` and
`long double` overloads as well).
```
template
struct FrexpResult {
constexpr FrexpResult(T fraction, int exponent) : fraction(fraction),
exponent(exponent) {}
T fraction;
int exponent;
friend constexpr bool operator<=>(const FrexpResult &, const FrexpResult &) =
default;
};
constexpr auto q() { return FrexpResult{0.5, 0}; };
static_assert(q() == FrexpResult{0.5, 0});
```
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast edited https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+extern "C" void abort() noexcept;
+extern "C" int write(int, const void*, unsigned long);
+
+#define assert(condition) \
+ do { \
+if (!(condition)) {\
+ write(2, "Assertion failed: ", 18); \
+ write(2, #condition, sizeof(#condition) - 1);\
+ write(2, "\n", 1); \
+ abort(); \
+} \
+ } while (false)
+
+int main() {
+int i;
+
+// fmin
+static_assert(__builtin_fmin(15.24, 1.3) == 1.3, "");
+static_assert(__builtin_fmin(-0.0, +0.0) == -0.0, "");
+static_assert(__builtin_fmin(+0.0, -0.0) == -0.0, "");
+assert(__builtin_isnan(__builtin_fminf(NAN,NAN)));
+assert(__builtin_isnan(__builtin_fminf(NAN, -1)));
+assert(__builtin_isnan(__builtin_fminf(-INFINITY, 0)));
+assert(__builtin_iszero(__builtin_fminf(+INFINITY, 0)));
+
+// frexp
+static_assert(__builtin_frexp(123.45, ) == 0.9644531250002);
hubert-reinterpretcast wrote:
Just because a function is `constexpr` does not mean an invocation of it would
be allowed in a constant expression even if the arguments were constant
expressions.
The specific issue is that the semantics of `frexp` has it write a value
through it's second parameter. In order to modify the stored value of an object
in constant evaluation, the object has to begin its lifetime in that constant
evaluation.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -14638,6 +14649,8 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
return true;
}
+ case Builtin::BIfmin:
+ case Builtin::BIfminf:
hubert-reinterpretcast wrote:
I think we'll be missing at least "pedantic" diagnostics if we don't restrict
the `constexpr`-ness to C++23 and up. So we do need that restriction.
The interaction with `-fno-builtin[-*]` may need more discussion. At least the
documentation for that option would need to be updated if the C++23 `constexpr`
math would break with it.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -14638,6 +14649,8 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
return true;
}
+ case Builtin::BIfmin:
+ case Builtin::BIfminf:
hubert-reinterpretcast wrote:
> How would that help?
I guess it doesn't... The functions would be ambiguous when called...
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
core.git: desktop/source sfx2/source
desktop/source/lib/init.cxx |3 ++-
sfx2/source/control/unoctitm.cxx |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
New commits:
commit 9648f81f98d07cd4aef8611a50a77f11fb7ba86e
Author: Hubert Figuière
AuthorDate: Thu Apr 25 14:01:11 2024 -0400
Commit: Caolán McNamara
CommitDate: Mon Apr 29 09:31:06 2024 +0200
cool#8066: calc: enable .uno:ToggleSheetGrid
Signed-off-by: Hubert Figuière
Change-Id: Ibe5bca4d0622c4015030a21d4ecccd41d5e9f483
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166529
Tested-by: Jenkins
Reviewed-by: Caolán McNamara
diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index f13bc1f48e26..f06151be6cfa 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -3847,7 +3847,8 @@ static void doc_iniUnoCommands ()
u".uno:InsertPictureContentControl"_ustr,
u".uno:DataFilterAutoFilter"_ustr,
u".uno:CellProtection"_ustr,
-u".uno:MoveKeepInsertMode"_ustr
+u".uno:MoveKeepInsertMode"_ustr,
+u".uno:ToggleSheetGrid"_ustr,
};
util::URL aCommandURL;
diff --git a/sfx2/source/control/unoctitm.cxx b/sfx2/source/control/unoctitm.cxx
index 0691a6bad444..c6250e27d170 100644
--- a/sfx2/source/control/unoctitm.cxx
+++ b/sfx2/source/control/unoctitm.cxx
@@ -940,7 +940,8 @@ static void InterceptLOKStateChangeEvent(sal_uInt16 nSID,
SfxViewFrame* pViewFra
aEvent.FeatureURL.Path == "SpacePara15" ||
aEvent.FeatureURL.Path == "SpacePara2" ||
aEvent.FeatureURL.Path == "DataFilterAutoFilter" ||
-aEvent.FeatureURL.Path == "CellProtection")
+aEvent.FeatureURL.Path == "CellProtection" ||
+aEvent.FeatureURL.Path == "ToggleSheetGrid")
{
bool bTemp = false;
aEvent.State >>= bTemp;
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -14638,6 +14649,8 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
return true;
}
+ case Builtin::BIfmin:
+ case Builtin::BIfminf:
hubert-reinterpretcast wrote:
Makes me wonder how far C++ stdlibs will get if they included the C library
headers in an inline namespace under the global namespace (and count on `extern
"C"` to handle the linkage names).
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,55 @@
+// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \
+// RUN: -DWIN -emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN
+
+// RUN: %clang_cc1 -x c++ -triple x86_64-unknown-unknown -std=c++23 \
+// RUN: -emit-llvm -o - %s | FileCheck %s --check-prefixes=LNX
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+int func()
+{
+ int i;
+
+ // fmin
--------
hubert-reinterpretcast wrote:
No testing for `long double`?
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -3440,7 +3440,7 @@ def Fmod : FPMathTemplate, LibBuiltin<"math.h"> {
def Frexp : FPMathTemplate, LibBuiltin<"math.h"> {
let Spellings = ["frexp"];
- let Attributes = [NoThrow];
+ let Attributes = [NoThrow, Constexpr];
let Prototype = "T(T, int*)";
let AddBuiltinPrefixedAlias = 1;
hubert-reinterpretcast wrote:
Should probably match `Fmin` on this:
```suggestion
let AddBuiltinPrefixedAlias = 1;
let OnlyBuiltinPrefixedAliasIsConstexpr = 1;
```
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+extern "C" void abort() noexcept;
+extern "C" int write(int, const void*, unsigned long);
+
+#define assert(condition) \
+ do { \
+if (!(condition)) {\
+ write(2, "Assertion failed: ", 18); \
+ write(2, #condition, sizeof(#condition) - 1);\
+ write(2, "\n", 1); \
+ abort(); \
+} \
+ } while (false)
+
+int main() {
+int i;
+
+// fmin
+static_assert(__builtin_fmin(15.24, 1.3) == 1.3, "");
+static_assert(__builtin_fmin(-0.0, +0.0) == -0.0, "");
+static_assert(__builtin_fmin(+0.0, -0.0) == -0.0, "");
+assert(__builtin_isnan(__builtin_fminf(NAN,NAN)));
+assert(__builtin_isnan(__builtin_fminf(NAN, -1)));
+ assert(__builtin_isnan(__builtin_fminf(-INFINITY, 0)));
hubert-reinterpretcast wrote:
I doubt the runtime assertions are working (or appropriate in the Clang LIT
testing).
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -14638,6 +14649,8 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
return true;
}
+ case Builtin::BIfmin:
+ case Builtin::BIfminf:
hubert-reinterpretcast wrote:
Don't make these evaluate in `constexpr`. Not only does this extend C (not a
stated intent of the patch), it will cause accidental dependencies that break
when `-fno-builtin` is used.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -14547,6 +14547,17 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexpf:
+ case Builtin::BI__builtin_frexp: {
hubert-reinterpretcast wrote:
Why no `long double`?
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast requested changes to this pull request. https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+extern "C" void abort() noexcept;
+extern "C" int write(int, const void*, unsigned long);
+
+#define assert(condition) \
+ do { \
+if (!(condition)) {\
+ write(2, "Assertion failed: ", 18); \
+ write(2, #condition, sizeof(#condition) - 1);\
+ write(2, "\n", 1); \
+ abort(); \
+} \
+ } while (false)
+
+int main() {
+int i;
+
+// fmin
+static_assert(__builtin_fmin(15.24, 1.3) == 1.3, "");
+static_assert(__builtin_fmin(-0.0, +0.0) == -0.0, "");
+static_assert(__builtin_fmin(+0.0, -0.0) == -0.0, "");
+assert(__builtin_isnan(__builtin_fminf(NAN,NAN)));
+assert(__builtin_isnan(__builtin_fminf(NAN, -1)));
+assert(__builtin_isnan(__builtin_fminf(-INFINITY, 0)));
+assert(__builtin_iszero(__builtin_fminf(+INFINITY, 0)));
+
+// frexp
+static_assert(__builtin_frexp(123.45, ) == 0.9644531250002);
hubert-reinterpretcast wrote:
This should not be a constant expression. This line is not supposed to compile.
`i` is supposed to be written to, but it lives outside of the constant
expression evaluation.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -14547,6 +14547,17 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexpf:
+ case Builtin::BI__builtin_frexp: {
+LValue Pointer;
+if (!EvaluateFloat(E->getArg(0), Result, Info) ||
+!EvaluatePointer(E->getArg(1), Pointer, Info))
+ return false;
+llvm::RoundingMode RM = getActiveRoundingMode(Info, E);
+int FrexpExp;
+Result = llvm::frexp(Result, FrexpExp, RM);
----
hubert-reinterpretcast wrote:
The value in `FrexpExp` is just ignored?
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
https://github.com/hubert-reinterpretcast edited https://github.com/llvm/llvm-project/pull/88978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
core.git: Branch 'distro/collabora/co-24.04' - desktop/source sfx2/source
desktop/source/lib/init.cxx |3 ++-
sfx2/source/control/unoctitm.cxx |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
New commits:
commit dd78abffa4ab89507310e3080be25586f21c2021
Author: Hubert Figuière
AuthorDate: Thu Apr 25 14:01:11 2024 -0400
Commit: Caolán McNamara
CommitDate: Thu Apr 25 20:42:57 2024 +0200
cool#8066: calc: enable .uno:ToggleSheetGrid
Signed-off-by: Hubert Figuière
Change-Id: Ibe5bca4d0622c4015030a21d4ecccd41d5e9f483
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166647
Tested-by: Jenkins CollaboraOffice
Reviewed-by: Caolán McNamara
diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index 5f51d05615d8..ba9b45230093 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -3900,7 +3900,8 @@ static void doc_iniUnoCommands ()
u".uno:InsertPictureContentControl"_ustr,
u".uno:DataFilterAutoFilter"_ustr,
u".uno:CellProtection"_ustr,
-u".uno:MoveKeepInsertMode"_ustr
+u".uno:MoveKeepInsertMode"_ustr,
+u".uno:ToggleSheetGrid"_ustr,
};
util::URL aCommandURL;
diff --git a/sfx2/source/control/unoctitm.cxx b/sfx2/source/control/unoctitm.cxx
index 37286cc2d71d..19bc307a1011 100644
--- a/sfx2/source/control/unoctitm.cxx
+++ b/sfx2/source/control/unoctitm.cxx
@@ -940,7 +940,8 @@ static void InterceptLOKStateChangeEvent(sal_uInt16 nSID,
SfxViewFrame* pViewFra
aEvent.FeatureURL.Path == "SpacePara15" ||
aEvent.FeatureURL.Path == "SpacePara2" ||
aEvent.FeatureURL.Path == "DataFilterAutoFilter" ||
-aEvent.FeatureURL.Path == "CellProtection")
+aEvent.FeatureURL.Path == "CellProtection" ||
+aEvent.FeatureURL.Path == "ToggleSheetGrid")
{
bool bTemp = false;
aEvent.State >>= bTemp;
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -2922,7 +2922,7 @@ static bool handleFloatFloatBinOp(EvalInfo , const
BinaryOperator *E,
// If during the evaluation of an expression, the result is not
// mathematically defined [...], the behavior is undefined.
// FIXME: C++ rules require us to not conform to IEEE 754 here.
- if (LHS.isNaN()) {
+ if (!Info.getLangOpts().CPlusPlus23 && LHS.isNaN()) {
----
hubert-reinterpretcast wrote:
> Do we want to do the same for C++23? If not what's exactly an "unspecified"
> value?
It means that `INT_MAX` and `INT_MIN` is fine (based on the wording). The
committee discussion had already decided that the constexpr evaluation need not
match the target's runtime in terms of implementation-defined behavior with
respect to:
- what cases are errors, and
- how non-error cases of NaNs and infinities, etc. are handled.
Instead, C's Annex F was to specify the behaviour; however, that C's Annex F
did not fully specify the result (as in the case in question) was not discussed.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [6lo] [IPv6] Can We Turn the Global Network into a Firewall Protecting All End Users?
On Wed, Apr 24, 2024, 07:46 Mark Andrews wrote: > > > > On 23 Apr 2024, at 16:51, Hubert W wrote: > > > > Dear WG, > > > > > > I woke up with one idea and I would like to challenge it. > > In IPv6, every device receives a routable address. To protect endpoints > effectively, we require firewalls to filter unwanted traffic. > > Apart from packet volume this is a false assertion. No device should > require a firewall. > > > But what if we could stop such traffic at the source? Could this > approach convince more people toward adopting IPv6? > > > > According to RFC 7381: “In a /48 assignment, typical for a site, there > are then still 65,535 /64 blocks.” and “All user access networks should be > a /64.” > > /64 is typical not required. > > > Can we use then bit 63 to convey a message: “I don’t want any incoming > traffic initiated towards me!!!”? Of course a response would be accepted. > > > > We could divide the /64 allocations into two groups: one for servers, > and these accept incoming traffic (bit 63 = 0): > > > > for example 2001:0db8::::/64 > > > > And the second group: endpoints, these never accept incoming traffic > (bit 63 = 1): > > > > for example 2001:0db8::0001::/64 > > > > We only need all systems to understand the message. If a router or > firewall sees such a packet, then drops it. > > Every TCP packet with flag SYN, where destination address (IPv6) has bit > 63 equal 1, must be dropped. > > All the world is not TCP. Additionally for TCP the filtering device would > need to track state and that implies symmetric routing. > > > Would it be theoretically possible? > > No. > > > Best regards > > > > Hubert Wisniewski > > > > > > IETF IPv6 working group mailing list > > i...@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org I think there would be no issue with asymmetric traffic if we only check SYN flag, but I understand that is not a good idea. Thank you for your opinion. Hubert Wisniewski ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)
@@ -2922,7 +2922,7 @@ static bool handleFloatFloatBinOp(EvalInfo , const
BinaryOperator *E,
// If during the evaluation of an expression, the result is not
// mathematically defined [...], the behavior is undefined.
// FIXME: C++ rules require us to not conform to IEEE 754 here.
- if (LHS.isNaN()) {
+ if (!Info.getLangOpts().CPlusPlus23 && LHS.isNaN()) {
----
hubert-reinterpretcast wrote:
My understanding of the intended design was that operations producing NaNs from
non-NaNs in C++ constexpr cause the expression to not be constant. That said,
NaNs are still in play because of `numeric_limits`.
For `frexp` though, I think there being an "unspecified" value stored for the
exponent is a problem where the design could use more clarity. I would think
that the operation could still be performed, but the "unspecified" value should
probably be considered indeterminate.
https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: Password forgotten
On Tue, Apr 23, 2024 at 08:14:15AM -0400, Arbol One wrote: > Hello. > In my Debian box, after entering this command to psql-16, *psql -h localhost > -U postgres* You might want to read https://www.depesz.com/2008/11/28/recovering-lost-postgresql-password/ Best regards, depesz
[6lo] Can We Turn the Global Network into a Firewall Protecting All End Users?
Dear WG, I woke up with one idea and I would like to challenge it. In IPv6, every device receives a routable address. To protect endpoints effectively, we require firewalls to filter unwanted traffic. But what if we could stop such traffic at the source? Could this approach convince more people toward adopting IPv6? According to RFC 7381: “In a /48 assignment, typical for a site, there are then still 65,535 /64 blocks.” and “All user access networks should be a /64.” Can we use then bit 63 to convey a message: “I don’t want any incoming traffic initiated towards me!!!”? Of course a response would be accepted. We could divide the /64 allocations into two groups: one for servers, and these accept incoming traffic (bit 63 = 0): for example 2001:0db8::::/64 And the second group: endpoints, these never accept incoming traffic (bit 63 = 1): for example 2001:0db8::0001::/64 We only need all systems to understand the message. If a router or firewall sees such a packet, then drops it. Every TCP packet with flag SYN, where destination address (IPv6) has bit 63 equal 1, must be dropped. Would it be theoretically possible? Best regards Hubert Wisniewski ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [TLS] [EXT] Deprecating Static DH certificates in the obsolete key exchange document
On Sunday, 21 April 2024 23:26:56 CEST, Blumenthal, Uri - 0553 - MITLL wrote: I see two possibilities: 1. Nobody in the real world employs static DH anymore – in which case this draft is useless/pointless; or even if everybody agreed, making official, public statement on a particular topic as a group is still worthwhile, even if for no other reason than making it clear that is the position of the group Especially as the view of the group changed over time. 2. On private networks people employ static DH to implicitly authenticate their peers (a-lá MQV) – in which case this draft is harmful. Don't see how: just because the attack is harder to perform, lack of forward secrecy and higher vulnerability to side-channel attacks is an issue there too. Overall, I’m amazed by drafts like this one. Is nothing constructive remains out there to spend time and efforts on? -- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. - C. A. R. Hoare From: TLS on behalf of Viktor Dukhovni Date: Sunday, April 21, 2024 at 14:07 To: tls@ietf.org Subject: [EXT] Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document !---| This Message Is From an External Sender This message came from outside the Laboratory. |---! On Sat, Apr 20, 2024 at 04:12:48AM +, Peter Gutmann wrote: I realise that absence of evidence != evidence of absence, but in response to my previous request for anyone who has such a thing to comment on it, and even better to send me a sample so I can see one, no-one has mentioned, or produced, even one example of "a legitimate CA-issued [static-epmeheral DH certificate] rather than something someone ran up in their basement for fun". ... Can't say I've seen any static DH certificates in the wild, but I have seen code to support these, and perhaps the point is to bless deprecating/disabling/removing such code? In any case, this feels like cosmetic cleanup, rather than an effort to migrate a significant population of existing users to better practice. -- Viktor. -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] IANA Recommendations for Obsolete Key Exchange
On Monday, 15 April 2024 19:30:29 CEST, Joseph Salowey wrote:
At IETF 119 we had discussion on how to mark the ciphersuites
deprecated by draft-ietf-tls-deprecate-obsolete-kex in the IANA
Registry. At the meeting there was support for ('D' means
discouraged):
RSA ciphersuites should be marked with a "D"
FFDH ciphersuites should be marked with a "D"
FFDHE ciphersuites should be marked with a "D"
ECDH ciphersuites should be marked with a "D"
This aligns with the deprecation intent of the draft. The draft
states ECDH are a SHOULD NOT instead of a MUST NOT, but the
sentiment was they should be generally discouraged.
Please respond with any comments on this proposal by April 30,2024.
I still don't like deprecating/discouraging/SHOULD NOTig FFDHE, but
I'm still for the proposal, and OK with using "D" for marking in IANA.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[jira] [Commented] (MCOMPILER-589) Compilation fails due to removed generated-sources after upgrade from 3.11.0 to 3.12.0+
[
https://issues.apache.org/jira/browse/MCOMPILER-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838936#comment-17838936
]
Eric Hubert commented on MCOMPILER-589:
---
It looks like we can close the issue as invalid. It all seems to be caused by a
wrong/unintended configuration of the compiler plugin in the Maven project
which I think was a result of a non-optimal naming of the compiler plugin's
configuration parameter "generatedSourcesDirectory".
Other than the name may make suggest, it is only meant to be used for sources
generated by annotation processors (also properly documented via JavaDoc). With
this in mind, the above code (specifically the comments and the error message
make totally sense).
The project was configured like this:
{code}
${project.basedir}/generated-sources
{code}
placing annotation generated sources (if there were any) right next to other
generated sources instead of as by default in a subdirectory annotations. All
the years this configuration never caused issues, but with the added cleaning
of this directory before the compilation not only annotation processor
generated sources, but all sources were removed resulting in compilation errors.
> Compilation fails due to removed generated-sources after upgrade from 3.11.0
> to 3.12.0+
> ---
>
> Key: MCOMPILER-589
> URL: https://issues.apache.org/jira/browse/MCOMPILER-589
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.0, 3.12.1, 3.13.0
>Reporter: Eric Hubert
>Priority: Major
>
> After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the
> class compilation fails, because generated resources are no longer present in
> the generated-sources folder.
> The project is setup in a way that during the generate-sources phase a plugin
> generates java sources which are stored in the configured generated-sources
> folder. Within the same phase these are added to the source using the
> build-helper-maven-plugin's add-source goal.
> When debugging the maven execution one can verify how the files are generated
> and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
> executed, the generated sources are deleted before the actual source code is
> compiled finally resulting in a compilation error. The issue can be
> reproduced with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
> I did not yet find the time to debug the plugin, but briefly checked the
> release notes and found the ticket MCOMPILER-333 which might be the cause.
> Update: I now disabled incremental compilation by adding
> {code}
> -Dmaven.compiler.useIncrementalCompilation=false
> {code}
> on the command line to the Maven execution and all compiles fine and the
> generated-sources are used as expected. I think this way I put more evidence
> towards the changeset of MCOMPILER-333 to be the cause (therefore linking the
> ticket).
> I now also had a glance at the source code and have to admit that I do not
> really understand the reasoning of this change introducing an unconditional
> deletion of ALL files under generated-sources for incremental compilation
> (which is active by default). The generated sources are usually generated for
> a reason and must be processed during compilation. I'd expect this to break
> many use cases. What do I overlook here? I cannot see any direct relation to
> annotation processing as specified in the error message.
> {code}
> // MCOMPILER-333: Cleanup the generated source files created by
> annotation processing
> // to avoid issues with `javac` compiler when the source code is
> rebuild.
> if (getGeneratedSourcesDirectory() != null) {
> try (Stream walk =
> Files.walk(getGeneratedSourcesDirectory().toPath())) {
>
> walk.sorted(Comparator.reverseOrder()).map(Path::toFile).forEach(File::delete);
> // MCOMPILER-567: The directory must already exist
> because javac does not create it.
>
> Files.createDirectories(getGeneratedSourcesDirectory().toPath());
> } catch (IOException ex) {
> getLog().warn("I/O error deleting the annotation
> processing generated files: " + ex.getMessage());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-589) Compilation fails due to removed generated-sources after upgrade from 3.11.0 to 3.12.0+
[
https://issues.apache.org/jira/browse/MCOMPILER-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Hubert updated MCOMPILER-589:
--
Description:
After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the class
compilation fails, because generated resources are no longer present in the
generated-sources folder.
The project is setup in a way that during the generate-sources phase a plugin
generates java sources which are stored in the configured generated-sources
folder. Within the same phase these are added to the source using the
build-helper-maven-plugin's add-source goal.
When debugging the maven execution one can verify how the files are generated
and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
executed, the generated sources are deleted before the actual source code is
compiled finally resulting in a compilation error. The issue can be reproduced
with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
I did not yet find the time to debug the plugin, but briefly checked the
release notes and found the ticket MCOMPILER-333 which might be the cause.
Update: I now disabled incremental compilation by adding
{code}
-Dmaven.compiler.useIncrementalCompilation=false
{code}
on the command line to the Maven execution and all compiles fine and the
generated-sources are used as expected. I think this way I put more evidence
towards the changeset of MCOMPILER-333 to be the cause (therefore linking the
ticket).
I now also had a glance at the source code and have to admit that I do not
really understand the reasoning of this change introducing an unconditional
deletion of ALL files under generated-sources for incremental compilation
(which is active by default). The generated source are usually generated for a
reason and must be processed during compilation. I'd expect this to break many
use cases. What do I overlook here? I cannot see any direct relation to
annotation processing as specified in the error message.
{code}
// MCOMPILER-333: Cleanup the generated source files created by
annotation processing
// to avoid issues with `javac` compiler when the source code is
rebuild.
if (getGeneratedSourcesDirectory() != null) {
try (Stream walk =
Files.walk(getGeneratedSourcesDirectory().toPath())) {
walk.sorted(Comparator.reverseOrder()).map(Path::toFile).forEach(File::delete);
// MCOMPILER-567: The directory must already exist because
javac does not create it.
Files.createDirectories(getGeneratedSourcesDirectory().toPath());
} catch (IOException ex) {
getLog().warn("I/O error deleting the annotation processing
generated files: " + ex.getMessage());
}
}
{code}
was:
After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the class
compilation fails, because generated resources are no longer present in the
generated-sources folder.
The project is setup in a way that during the generate-sources phase a plugin
generates java sources which are stored in the configured generated-sources
folder. Within the same phase these are added to the source using the
build-helper-maven-plugin's add-source goal.
When debugging the maven execution one can verify how the files are generated
and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
executed, the generated sources are deleted before the actual source code is
compiled finally resulting in a compilation error. The issue can be reproduced
with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
I did not yet find the time to debug the plugin, but briefly checked the
release notes and found the ticket MCOMPILER-333 which might be the cause.
Update: I now disabled incremental compilation by adding
{code}
-Dmaven.compiler.useIncrementalCompilation=false
{code}
on the command line to the Maven execution and all compiles fine and the
generated-sources are used as expected. I think this way I put more evidence
towards the changeset of MCOMPILER-333 to be the cause (therefore linking the
ticket).
I now also had a glance at the source code and have to admit that I do not
really understand the reasoning of this change introducing an unconditional
deletion of ALL files under generated-sources for incremental compilation
(which active by default). The generated source are usually generated for a
reason and must be processed during compilation. I'd expect this to break many
use cases. What do I overlook here? I cannot see any direct relation to
annotation processing as specified in the error message.
{code}
// MCOMPILER-333: Cleanup the generated source files created by
annotation processing
// to avoid issues with `javac` compiler when the source
[jira] [Updated] (MCOMPILER-589) Compilation fails due to removed generated-sources after upgrade from 3.11.0 to 3.12.0+
[
https://issues.apache.org/jira/browse/MCOMPILER-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Hubert updated MCOMPILER-589:
--
Description:
After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the class
compilation fails, because generated resources are no longer present in the
generated-sources folder.
The project is setup in a way that during the generate-sources phase a plugin
generates java sources which are stored in the configured generated-sources
folder. Within the same phase these are added to the source using the
build-helper-maven-plugin's add-source goal.
When debugging the maven execution one can verify how the files are generated
and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
executed, the generated sources are deleted before the actual source code is
compiled finally resulting in a compilation error. The issue can be reproduced
with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
I did not yet find the time to debug the plugin, but briefly checked the
release notes and found the ticket MCOMPILER-333 which might be the cause.
Update: I now disabled incremental compilation by adding
{code}
-Dmaven.compiler.useIncrementalCompilation=false
{code}
on the command line to the Maven execution and all compiles fine and the
generated-sources are used as expected. I think this way I put more evidence
towards the changeset of MCOMPILER-333 to be the cause (therefore linking the
ticket).
I now also had a glance at the source code and have to admit that I do not
really understand the reasoning of this change introducing an unconditional
deletion of ALL files under generated-sources for incremental compilation
(which active by default). The generated source are usually generated for a
reason and must be processed during compilation. I'd expect this to break many
use cases. What do I overlook here? I cannot see any direct relation to
annotation processing as specified in the error message.
{code}
// MCOMPILER-333: Cleanup the generated source files created by
annotation processing
// to avoid issues with `javac` compiler when the source code is
rebuild.
if (getGeneratedSourcesDirectory() != null) {
try (Stream walk =
Files.walk(getGeneratedSourcesDirectory().toPath())) {
walk.sorted(Comparator.reverseOrder()).map(Path::toFile).forEach(File::delete);
// MCOMPILER-567: The directory must already exist because
javac does not create it.
Files.createDirectories(getGeneratedSourcesDirectory().toPath());
} catch (IOException ex) {
getLog().warn("I/O error deleting the annotation processing
generated files: " + ex.getMessage());
}
}
{code}
was:
After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the class
compilation fails, because generated resources are no longer present in the
generated-sources folder.
The project is setup in a way that during the generate-sources phase a plugin
generates java sources which are stored in the configured generated-sources
folder. Within the same phase these are added to the source using the
build-helper-maven-plugin's add-source goal.
When debugging the maven execution one can verify how the files are generated
and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
executed, the generated sources are deleted before the actual source code is
compiled finally resulting in a compilation error. The issue can be reproduced
with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
I did not yet find the time to debug the plugin, but briefly checked the
release notes and found the ticket MCOMPILER-333 which might be the cause.
Update: I now disabled incremental compilation by adding
{code}
-Dmaven.compiler.useIncrementalCompilation=false
{code}
on the command line to the Maven execution and all compiles fine and the
generated-sources are used as expected. I think this way I put more evidence
towards the changeset of MCOMPILER-333 to be the cause (therefore linking the
ticket).
I now also had a glance at the source code and have to admit that I do not
really understand the reasoning of this change introducing an unconditional
deletion of all files under generated-sources for incremental compilation
(which active by default). The generated source are usually generated for a
reason and must be processed during compilation. I'd expect this to break many
use cases. What do I overlook here?
{code}
// MCOMPILER-333: Cleanup the generated source files created by
annotation processing
// to avoid issues with `javac` compiler when the source code is
rebuild.
if (getGeneratedSourcesDirectory() != null) {
[jira] [Updated] (MCOMPILER-589) Compilation fails due to removed generated-sources after upgrade from 3.11.0 to 3.12.0+
[
https://issues.apache.org/jira/browse/MCOMPILER-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Hubert updated MCOMPILER-589:
--
Description:
After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the class
compilation fails, because generated resources are no longer present in the
generated-sources folder.
The project is setup in a way that during the generate-sources phase a plugin
generates java sources which are stored in the configured generated-sources
folder. Within the same phase these are added to the source using the
build-helper-maven-plugin's add-source goal.
When debugging the maven execution one can verify how the files are generated
and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
executed, the generated sources are deleted before the actual source code is
compiled finally resulting in a compilation error. The issue can be reproduced
with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
I did not yet find the time to debug the plugin, but briefly checked the
release notes and found the ticket MCOMPILER-333 which might be the cause.
Update: I now disabled incremental compilation by adding
{code}
-Dmaven.compiler.useIncrementalCompilation=false
{code}
on the command line to the Maven execution and all compiles fine and the
generated-sources are used as expected. I think this way I put more evidence
towards the changeset of MCOMPILER-333 to be the cause (therefore linking the
ticket).
I now also had a glance at the source code and have to admit that I do not
really understand the reasoning of this change introducing an unconditional
deletion of all files under generated-sources for incremental compilation
(which active by default). The generated source are usually generated for a
reason and must be processed during compilation. I'd expect this to break many
use cases. What do I overlook here?
{code}
// MCOMPILER-333: Cleanup the generated source files created by
annotation processing
// to avoid issues with `javac` compiler when the source code is
rebuild.
if (getGeneratedSourcesDirectory() != null) {
try (Stream walk =
Files.walk(getGeneratedSourcesDirectory().toPath())) {
walk.sorted(Comparator.reverseOrder()).map(Path::toFile).forEach(File::delete);
// MCOMPILER-567: The directory must already exist because
javac does not create it.
Files.createDirectories(getGeneratedSourcesDirectory().toPath());
} catch (IOException ex) {
getLog().warn("I/O error deleting the annotation processing
generated files: " + ex.getMessage());
}
}
{code}
was:
After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the class
compilation fails, because generated resources are no longer present in the
generated-sources folder.
The project is setup in a way that during the generate-sources phase a plugin
generates java sources which are stored in the configured generated-sources
folder. Within the same phase these are added to the source using the
build-helper-maven-plugin's add-source goal.
When debugging the maven execution one can verify how the files are generated
and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
executed, the generated sources are deleted before the actual source code is
compiled finally resulting in a compilation error. The issue can be reproduced
with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
I did not yet find the time to debug the plugin, but briefly checked the
release notes and found the ticket MCOMPILER-333 which might be the cause.
Update: I now disabled incremental compilation by adding
{code}
-Dmaven.compiler.useIncrementalCompilation=false
{code}
on the command line to the Maven execution and all compiles fine and the
generated-sources are used as expected. I think this way I put more evidence
towards the changeset of MCOMPILER-333 to be the cause (therefore linking the
ticket).
> Compilation fails due to removed generated-sources after upgrade from 3.11.0
> to 3.12.0+
> ---
>
> Key: MCOMPILER-589
> URL: https://issues.apache.org/jira/browse/MCOMPILER-589
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.0, 3.12.1, 3.13.0
>Reporter: Eric Hubert
>Priority: Major
>
> After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the
> class compilation fails, because generated resources are no longer present in
> the generated-sources folder.
> The project is setup in a way that during the generate-s
[jira] [Updated] (MCOMPILER-589) Compilation fails due to removed generated-sources after upgrade from 3.11.0 to 3.12.0+
[
https://issues.apache.org/jira/browse/MCOMPILER-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Hubert updated MCOMPILER-589:
--
Description:
After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the class
compilation fails, because generated resources are no longer present in the
generated-sources folder.
The project is setup in a way that during the generate-sources phase a plugin
generates java sources which are stored in the configured generated-sources
folder. Within the same phase these are added to the source using the
build-helper-maven-plugin's add-source goal.
When debugging the maven execution one can verify how the files are generated
and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
executed, the generated sources are deleted before the actual source code is
compiled finally resulting in a compilation error. The issue can be reproduced
with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
I did not yet find the time to debug the plugin, but briefly checked the
release notes and found the ticket MCOMPILER-333 which might be the cause.
Update: I now disabled incremental compilation by adding
{code}
-Dmaven.compiler.useIncrementalCompilation=false
{code}
on the command line to the Maven execution and all compiles fine and the
generated-sources are used as expected. I think this way I put more evidence
towards the changeset of MCOMPILER-333 to be the cause (therefore linking the
ticket).
was:
After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the class
compilation fails, because generated resources are no longer present in the
generated-sources folder.
The project is setup in a way that during the generate-sources phase a plugin
generates java sources which are stored in the configured generated-sources
folder. Within the same phase these are added to the source using the
build-helper-maven-plugin's add-source goal.
When debugging the maven execution one can verify how the files are generated
and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
executed, the generated sources are deleted before the actual source code is
compiled finally resulting in a compilation error. The issue can be reproduced
with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
I did not yet find the time to debug the plugin, but briefly checked the
release notes and found the ticket MCOMPILER-333 which might be the cause.
> Compilation fails due to removed generated-sources after upgrade from 3.11.0
> to 3.12.0+
> ---
>
> Key: MCOMPILER-589
> URL: https://issues.apache.org/jira/browse/MCOMPILER-589
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.0, 3.12.1, 3.13.0
>Reporter: Eric Hubert
>Priority: Major
>
> After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the
> class compilation fails, because generated resources are no longer present in
> the generated-sources folder.
> The project is setup in a way that during the generate-sources phase a plugin
> generates java sources which are stored in the configured generated-sources
> folder. Within the same phase these are added to the source using the
> build-helper-maven-plugin's add-source goal.
> When debugging the maven execution one can verify how the files are generated
> and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is
> executed, the generated sources are deleted before the actual source code is
> compiled finally resulting in a compilation error. The issue can be
> reproduced with 3.12.1 and 3.12.0 and does not happen with 3.11.0.
> I did not yet find the time to debug the plugin, but briefly checked the
> release notes and found the ticket MCOMPILER-333 which might be the cause.
> Update: I now disabled incremental compilation by adding
> {code}
> -Dmaven.compiler.useIncrementalCompilation=false
> {code}
> on the command line to the Maven execution and all compiles fine and the
> generated-sources are used as expected. I think this way I put more evidence
> towards the changeset of MCOMPILER-333 to be the cause (therefore linking the
> ticket).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCOMPILER-589) Compilation fails due to removed generated-sources after upgrade from 3.11.0 to 3.12.0+
Eric Hubert created MCOMPILER-589: - Summary: Compilation fails due to removed generated-sources after upgrade from 3.11.0 to 3.12.0+ Key: MCOMPILER-589 URL: https://issues.apache.org/jira/browse/MCOMPILER-589 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.13.0, 3.12.1, 3.12.0 Reporter: Eric Hubert After upgrading the used maven-compiler-plugin from 3.11.0 to 3.13.0 the class compilation fails, because generated resources are no longer present in the generated-sources folder. The project is setup in a way that during the generate-sources phase a plugin generates java sources which are stored in the configured generated-sources folder. Within the same phase these are added to the source using the build-helper-maven-plugin's add-source goal. When debugging the maven execution one can verify how the files are generated and placed in the correct folder. Once the maven-compiler-plugin > 3.11.0 is executed, the generated sources are deleted before the actual source code is compiled finally resulting in a compilation error. The issue can be reproduced with 3.12.1 and 3.12.0 and does not happen with 3.11.0. I did not yet find the time to debug the plugin, but briefly checked the release notes and found the ticket MCOMPILER-333 which might be the cause. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[clang] [llvm] [PowerPC] Tune AIX shared library TLS model at function level by heuristic (PR #84132)
https://github.com/hubert-reinterpretcast commented: See inline comments for rationale re: scoping to LD -> IE only (and not performing IE -> LD). https://github.com/llvm/llvm-project/pull/84132 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [PowerPC] Tune AIX shared library TLS model at function level by heuristic (PR #84132)
@@ -3362,6 +3362,64 @@ SDValue PPCTargetLowering::LowerGlobalTLSAddress(SDValue
Op,
return LowerGlobalTLSAddressLinux(Op, DAG);
}
+/// updateForAIXShLibTLSModelOpt - Helper to initialize TLS model opt settings,
+/// and then apply the update.
+static void updateForAIXShLibTLSModelOpt(TLSModel::Model ,
+ SelectionDAG ,
+ const TargetMachine ) {
+ // Initialize TLS model opt setting lazily:
+ // (1) Use initial-exec for single TLS var references within current
function.
+ // (2) Use local-dynamic for multiple TLS var references within current
+ // function.
+ PPCFunctionInfo *FuncInfo =
+ DAG.getMachineFunction().getInfo();
+ if (!FuncInfo->isAIXFuncUseInitDone()) {
+SmallPtrSet TLSGV;
+// Iterate over all instructions within current function, collect all TLS
+// global variables (global variables taken as the first parameter to
+// Intrinsic::threadlocal_address).
+const Function = DAG.getMachineFunction().getFunction();
+for (Function::const_iterator BI = Func.begin(), BE = Func.end(); BI != BE;
+ ++BI)
+ for (BasicBlock::const_iterator II = BI->begin(), IE = BI->end();
+ II != IE; ++II)
+if (II->getOpcode() == Instruction::Call)
+ if (const CallInst *CI = dyn_cast(&*II))
+if (Function *CF = CI->getCalledFunction())
+ if (CF->isDeclaration() &&
+ CF->getIntrinsicID() == Intrinsic::threadlocal_address)
+if (const GlobalValue *GV =
+dyn_cast(II->getOperand(0))) {
+ TLSModel::Model GVModel = TM.getTLSModel(GV);
+ if (GVModel == TLSModel::InitialExec ||
hubert-reinterpretcast wrote:
We should only count the number of `local-dynamic` accesses.
Rationale:
The option can be taken as providing the information that the shared object is
loaded with the executable (not `dlopen`ed later). In that case, all variables
accessed using the `local-dynamic` model can be accessed using `initial-exec`;
however, there would still be variables accessed using `initial-exec` that
cannot be accessed using `local-dynamic`.
https://github.com/llvm/llvm-project/pull/84132
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [PowerPC] Tune AIX shared library TLS model at function level by heuristic (PR #84132)
@@ -3362,6 +3362,64 @@ SDValue PPCTargetLowering::LowerGlobalTLSAddress(SDValue
Op,
return LowerGlobalTLSAddressLinux(Op, DAG);
}
+/// updateForAIXShLibTLSModelOpt - Helper to initialize TLS model opt settings,
+/// and then apply the update.
+static void updateForAIXShLibTLSModelOpt(TLSModel::Model ,
+ SelectionDAG ,
+ const TargetMachine ) {
+ // Initialize TLS model opt setting lazily:
+ // (1) Use initial-exec for single TLS var references within current
function.
+ // (2) Use local-dynamic for multiple TLS var references within current
+ // function.
+ PPCFunctionInfo *FuncInfo =
+ DAG.getMachineFunction().getInfo();
+ if (!FuncInfo->isAIXFuncUseInitDone()) {
+SmallPtrSet TLSGV;
+// Iterate over all instructions within current function, collect all TLS
+// global variables (global variables taken as the first parameter to
+// Intrinsic::threadlocal_address).
+const Function = DAG.getMachineFunction().getFunction();
+for (Function::const_iterator BI = Func.begin(), BE = Func.end(); BI != BE;
+ ++BI)
+ for (BasicBlock::const_iterator II = BI->begin(), IE = BI->end();
+ II != IE; ++II)
+if (II->getOpcode() == Instruction::Call)
+ if (const CallInst *CI = dyn_cast(&*II))
+if (Function *CF = CI->getCalledFunction())
+ if (CF->isDeclaration() &&
+ CF->getIntrinsicID() == Intrinsic::threadlocal_address)
+if (const GlobalValue *GV =
+dyn_cast(II->getOperand(0))) {
+ TLSModel::Model GVModel = TM.getTLSModel(GV);
+ if (GVModel == TLSModel::InitialExec ||
+ GVModel == TLSModel::LocalDynamic)
+TLSGV.insert(GV);
+}
+
+unsigned TLSGVCnt = TLSGV.size();
+LLVM_DEBUG(dbgs() << format("TLSGV count:%d\n", TLSGVCnt));
+if (TLSGVCnt == 1)
+ FuncInfo->setAIXFuncUseTLSIE();
+else if (TLSGVCnt > 1)
+ FuncInfo->setAIXFuncUseTLSLD();
hubert-reinterpretcast wrote:
We should need to set only one thing (to represent "use IE instead of LD"). The
threshold number should not be repeated in more than one place.
Additionally, the threshold number may need to be increased (tests via
experiments).
https://github.com/llvm/llvm-project/pull/84132
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
