spavloff wrote:
Added commit:
https://github.com/llvm/llvm-project/commit/93ae26331592f41bf2b1d10b048743d80c468385
to run the test on x86 only.
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -710,9 +710,11 @@ class Sema final {
return result;
}
+ // Saves the current floating-point pragma stack and clear it in this Sema.
class FpPragmaStackSaveRAII {
public:
-FpPragmaStackSaveRAII(Sema &S) : S(S), SavedStack(S.FpPragmaStack) {}
+FpPragmaSta
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/70646
>From e1623db8f86a8584d17729f000a455f5672adad4 Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 30 Oct 2023 14:38:50 +0700
Subject: [PATCH 1/3] [clang] Do not clear FP pragma stack when instantiating
func
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/70646
>From 7882ea746ecf8721356fc6afbd7798b8db4e185d Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 30 Oct 2023 14:38:50 +0700
Subject: [PATCH 1/3] [clang] Do not clear FP pragma stack when instantiating
func
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 6d30bc00858941043ea7d45938192adfd1020922
44b096810d88da1d1331be12802c68cdf8e1785b --
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/70646
>From 7882ea746ecf8721356fc6afbd7798b8db4e185d Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 30 Oct 2023 14:38:50 +0700
Subject: [PATCH 1/2] [clang] Do not clear FP pragma stack when instantiating
func
tru wrote:
17.0.5 is going to be released tomorrow, is this fix good to go for the
backport?
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
https://github.com/rjmccall commented:
Otherwise LGTM
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -710,9 +710,11 @@ class Sema final {
return result;
}
+ // Saves the current floating-point pragma stack and clear it in this Sema.
class FpPragmaStackSaveRAII {
public:
-FpPragmaStackSaveRAII(Sema &S) : S(S), SavedStack(S.FpPragmaStack) {}
+FpPragmaSta
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
> pragma pack uses pragma stack and it is allowed in any place:
> https://godbolt.org/z/f8fP1vn63 . If such pragma presents in the late-parsed
> template, and push-pop operations in it are not balanced, the late parse of
> such function can break the pragma stack and next templ
spavloff wrote:
`pragma pack` uses pragma stack and it is allowed in any place:
https://godbolt.org/z/f8fP1vn63 . If such pragma presents in the late-parsed
template, and push-pop operations in it are not balanced, the late parse of
such function can break the pragma stack and next templates c
tru wrote:
Can this be merged and ready for a backport next week?
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
> > The upshot is that we don't (and shouldn't) ever late-parse at file
> > context, which by design means we can't see stack-manipulating pragmas
> > because they're all restricted to file context. In late parsing, we only
> > ever observe and change the innermost state of the
AaronBallman wrote:
> > > And contrariwise, if there's some sneaky way to put push/pop pragmas in
> > > non-file contexts, that also seems like a serious problem, because the
> > > way we process them is not designed to understand local scopes, which
> > > means we're just doing random stuff i
rjmccall wrote:
> > And contrariwise, if there's some sneaky way to put push/pop pragmas in
> > non-file contexts, that also seems like a serious problem, because the way
> > we process them is not designed to understand local scopes, which means
> > we're just doing random stuff instead of im
AaronBallman wrote:
> And contrariwise, if there's some sneaky way to put push/pop pragmas in
> non-file contexts, that also seems like a serious problem, because the way we
> process them is not designed to understand local scopes, which means we're
> just doing random stuff instead of implem
rjmccall wrote:
It's certainly possible to see push/pop pragmas in late-parsed code, but Sema
should immediately emit an error and ignore them because, like I said, they're
only allowed at file context, and AFAIK late-parsed code is never at file
context. If there's some sneaky way to late-pa
spavloff wrote:
Late parsing (in contrast to template instantiation) is sensitive to the pragma
stack because the late parsed text may contain pragmas. If, for example, the
parsed text contains unbalanced pus/pop pragmas, it is detected if the pragma
stack is empty, but can be missed if there
rjmccall wrote:
I see, that makes sense. It shouldn't really need to be saved even during late
template parsing, right? Late template parsing is never at the top level, and
push/pop are only allowed at the top level.
https://github.com/llvm/llvm-project/pull/70646
___
spavloff wrote:
Actually the pragma stack is not saved during template instantiation. It is
saved during late template parsing using class `FpPragmaStackSaveRAII`. For
template instantiation the dependency on the stack can be considered as an
error, because all information about FP options sho
rjmccall wrote:
That makes sense. Out of curiosity, since presumably the instantiation path is
using the RAII class, and the RAII class seems to save and restore the entire
stack, what actually ends up going wrong? It doesn't look like your test case
has local changes to the stack within the
spavloff wrote:
> To be clear, we're still ensuring the current pragma state during
> instantiation is what it was when the template is parsed, we're just not
> incorrectly dropping all of the saved pragma state when we're doing it?
Yes, the pragma is used at parse stage to set correct FP opti
tru wrote:
Our code compiles without warnings with this patch!
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall commented:
To be clear, we're still ensuring the current pragma state during instantiation
is what it was when the template is parsed, we're just not incorrectly dropping
all of the saved pragma state when we're doing it?
https://github.com/llvm/llvm-project/pull/70
tru wrote:
Thanks for the patch @spavloff - I will make sure to try it today!
https://github.com/llvm/llvm-project/pull/70646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Serge Pavlov (spavloff)
Changes
When instantiation function, a call to Sema::resetFPOption was used to set the
FP options associated with AST node. However this function also cleared FP
pragma stack, and it is incorrect. Template instanti
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/70646
When instantiation function, a call to Sema::resetFPOption was used to set the
FP options associated with AST node. However this function also cleared FP
pragma stack, and it is incorrect. Template instantiatio
29 matches
Mail list logo
