Re: [PATCH] D16579: Warn if friend function depends on template parameters.

sepavloff updated this revision to Diff 63386. sepavloff added a comment. Updated patch http://reviews.llvm.org/D16579 Files: include/clang/AST/TypeInstantiationMatcher.h include/clang/AST/TypeMatcher.h include/clang/Basic/DiagnosticGroups.td include/clang/Basic/DiagnosticSemaKinds.td

Re: [PATCH] D16579: Warn if friend function depends on template parameters.

sepavloff updated this revision to Diff 63387. sepavloff added a comment. Repared file modes. http://reviews.llvm.org/D16579 Files: include/clang/AST/TypeInstantiationMatcher.h include/clang/AST/TypeMatcher.h include/clang/Basic/DiagnosticGroups.td include/clang/Basic/DiagnosticSemaKind

Re: [PATCH] D16579: Warn if friend function depends on template parameters.

sepavloff marked 6 inline comments as done. Comment at: include/clang/Sema/Sema.h:9469 @@ +9468,3 @@ + /// of proper templates, but they are needed for checks. + SmallVector FriendsOfTemplates; + Do we really need it? When compiler is compiling a module containi

Re: [PATCH] D14326: ASTImporter: expressions, pt.2

2016-07-01 15:26 GMT+06:00 Aleksei Sidorin : > a.sidorin updated this revision to Diff 62474. > a.sidorin added a comment. > > Fix some issues pointed by Serge Pavlov. > Serge: putting a check of FriendDecls to `IsStructurallyEquivalent()` > seems like a good idea for me, but we need some addition

Re: [PATCH] D16989: Change interpretation of function definition in friend declaration of template class.

Any feedback? Thanks, --Serge 2016-06-20 1:52 GMT+06:00 Serge Pavlov : > sepavloff updated this revision to Diff 61220. > sepavloff added a comment. > > Updated patch > > Added handling of FunctionTemplateDecl to > shouldLinkDependentDeclWithPrevious. It is not > used now but is required for sub

Re: [PATCH] D14286: ASTImporter: expressions, pt.1

2016-02-19 20:52 GMT+06:00 Aleksei Sidorin : > a.sidorin added a comment. > > Serge Pavlov: I'll enable tests from you patch ( > http://reviews.llvm.org/D14224) after all node types your patch supports > will be supported. If you're agree, of course. > > Yes, sure, that would be nice! I cannot c

Re: [PATCH] D16396: Warn if variable cannot be implicitly instantiated

Any feedback? Thanks, --Serge 2016-01-21 14:33 GMT+06:00 Serge Pavlov : > sepavloff created this revision. > sepavloff added a reviewer: rsmith. > sepavloff added subscribers: cfe-commits, silvas. > > Instantiation of static class members may be a source of user > misunderstanding, > especially

Re: [PATCH] D16396: Warn if variable cannot be implicitly instantiated

sepavloff added a subscriber: sepavloff. sepavloff added a comment. Any feedback? Thanks, --Serge http://reviews.llvm.org/D16396 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14286: ASTImporter: expressions, pt.1

sepavloff added a comment. I still cannot build project with your changes, now compiler cannot find symbol `hasSubStmt`. When committing the change please make sure that all prerequisites are committed and unit tests run successfully. I would recommend you to take tests from http://reviews.llvm

Re: [PATCH] D14286: ASTImporter: expressions, pt.1

sepavloff added a subscriber: sepavloff. sepavloff added a comment. On Windows (VS2015 update1) two unit tests fail: [ RUN ] ImportExpr.ImportGNUNullExpr input.cc:1:23: warning: expression result unused [-Wunused-value] void declToImport() { __null; } ^~ G

Re: [PATCH] D14286: ASTImporter: expressions, pt.1

On Windows (VS2015 update1) two unit tests fail: ``` [ RUN ] ImportExpr.ImportGNUNullExpr input.cc:1:23: warning: expression result unused [-Wunused-value] void declToImport() { __null; } ^~ G:\arbeit\llvm2\llvm\tools\clang\unittests\AST\ASTImporterTest.cpp(149): err

Re: [PATCH] D16989: Change interpretation of function definition in friend declaration of template class.

sepavloff added a comment. Topic of friend function instantiation in C++ Standard discussion group

Re: [PATCH] D16579: Warn if friend function depends on template parameters.

Ping. Thanks, --Serge 2016-02-26 12:20 GMT+06:00 Serge Pavlov : > Could someone provide a feedback? > > Thanks, > --Serge > > 2016-01-26 20:55 GMT+06:00 Serge Pavlov : > >> sepavloff created this revision. >> sepavloff added a subscriber: cfe-commits. >> >> Declaration of friend function may dep

Re: [PATCH] D14286: ASTImporter: expressions, pt.1

sepavloff added a comment. The last changes didn't help. AST generated in `ImportGNUNullExpr` is: TranslationUnitDecl 0xc46238 <> … | `-BuiltinType 0xc46290 'char' `-FunctionDecl 0xc468a0 col:6 declToImport 'void (void)' `-CompoundStmt 0xc46948 `-GNUNullExpr 0xc46938 'in

Re: [PATCH] D16579: Warn if friend function depends on template parameters.

sepavloff updated this revision to Diff 51017. sepavloff added a comment. Do not emit warning on class methods. http://reviews.llvm.org/D16579 Files: include/clang/Basic/DiagnosticGroups.td include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaDecl.cpp test/CXX/drs/dr3xx.cpp test/CX

Re: [PATCH] D16579: Warn if friend function depends on template parameters.

2016-03-18 0:35 GMT+06:00 Arthur O'Dwyer : > I'm not qualified to comment on the implementation, but I'm a bit > skeptical that this warning is appropriate in the first place. I've often > declared friend non-template functions, e.g. swap(). I've never intended to > declare a friend *template spec

Re: [PATCH] D14286: ASTImporter: expressions, pt.1

With the latest changes unit tests are successfully passed on Windows! You can go forward in completing the fix. Thanks, --Serge 2016-03-18 21:44 GMT+06:00 Aleksei Sidorin : > a.sidorin updated this revision to Diff 51027. > a.sidorin added a comment. > > Serge, thank you for help! > GNUNullExpr

Re: [PATCH] D16989: Change interpretation of function definition in friend declaration of template class.

sepavloff updated this revision to Diff 51817. sepavloff added a comment. Changed implementation This implementation uses another approach. Previous version of the patch put friend functions into redeclaration chains but modified search algorithm so that it skipped such functions. In this versi

Re: [PATCH] D16989: Change interpretation of function definition in friend declaration of template class.

2016-03-18 20:50 GMT+06:00 Richard Smith : > rsmith added a comment. > > Can we instead not add the function to the redeclaration chain until it's > instantiated (like we do if it's dependent)? > > I prepared implementation that uses this approach. In this variant information about potential defin

r256503 - Avoid crash when dumping LocInfoType.

Author: sepavloff Date: Mon Dec 28 11:19:12 2015 New Revision: 256503 URL: http://llvm.org/viewvc/llvm-project?rev=256503&view=rev Log: Avoid crash when dumping LocInfoType. LocInfoType is a helper type used internally inside Sema and Parser, it does not exist in valid AST. LocInfoType uses code

r256511 - Do not crash if class is defined in wrong scope.

Author: sepavloff Date: Mon Dec 28 13:40:14 2015 New Revision: 256511 URL: http://llvm.org/viewvc/llvm-project?rev=256511&view=rev Log: Do not crash if class is defined in wrong scope. This patch fixes PR16677. The latter represents the case when due to misprinted character class definition occur

Re: [PATCH] D15450: Avoid double deletion in Clang driver.

Any feedback? Thanks, --Serge 2015-12-11 20:24 GMT+06:00 Serge Pavlov : > sepavloff created this revision. > sepavloff added a subscriber: cfe-commits. > > Llvm module object is shared between CodeGenerator and BackendConsumer, > in both classes it is stored as std::unique_ptr, which is not a go

[PATCH] D16396: Warn if variable cannot be implicitly instantiated

sepavloff created this revision. sepavloff added a reviewer: rsmith. sepavloff added subscribers: cfe-commits, silvas. Instantiation of static class members may be a source of user misunderstanding, especially in the case of using modules, PR24425 describes one of such examples. This patch impleme

[PATCH] D16579: Warn if friend function depends on template parameters.

sepavloff created this revision. sepavloff added a subscriber: cfe-commits. Declaration of friend function may depend on template parameters, however it does not become a template function: template class C1 { friend void func(T x); }; It may be not obvious for user, so compiler co

Re: [PATCH] D15450: Avoid double deletion in Clang driver.

Can somebody have a look at this fix? Thank you! --Serge 2016-01-11 23:50 GMT+06:00 Serge Pavlov : > Any feedback? > > Thanks, > --Serge > > 2015-12-11 20:24 GMT+06:00 Serge Pavlov : > >> sepavloff created this revision. >> sepavloff added a subscriber: cfe-commits. >> >> Llvm module object is s

Re: [PATCH] D15450: Avoid double deletion in Clang driver.

test would be practical. The fact that an object is owned by two unique_ptr's may be enought to change implementation. However any thoughts how to test this behavior are wellcome. Thanks, --Serge 2016-01-30 0:54 GMT+06:00 Jonathan Roelofs : > > > On 1/29/16 11:51 AM, Serge Pavlov vi

Re: [PATCH] D14286: ASTImporter: expressions, pt.1

sepavloff added a comment. Unit test, of course, checks import facility but i would say this is overkill. You need to create tests for all nodes you implement in imported, this is huge amount of work. I would propose you to move tests from http://reviews.llvm.org/D14224 for nodes that are impl

Re: [PATCH] D14286: ASTImporter: expressions, pt.1

sepavloff added a comment. If you are going to make unit tests, consider alternative approach also. In repository `test-suite` the directory `SingleSource/UnitTests` contains runtime tests obtained from single file. You could modify Makefile that runs these tests in such a way that each test ru

[PATCH] D15158: [PGO] Instrument only base constructors and destructors.

sepavloff created this revision. sepavloff added a reviewer: bogner. sepavloff added subscribers: cfe-commits, silvas. Constructors and destructors may be represented by several functions in IR. Only the base structors correspond to source code, others are small pieces of code and eventually call

Re: [PATCH] D15158: [PGO] Instrument only base constructors and destructors.

sepavloff updated this revision to Diff 41744. sepavloff added a comment. Changes according to reviewer's notes. http://reviews.llvm.org/D15158 Files: lib/CodeGen/CGBlocks.cpp lib/CodeGen/CGObjC.cpp lib/CodeGen/CGStmt.cpp lib/CodeGen/CGStmtOpenMP.cpp lib/CodeGen/CodeGenFunction.cpp

Re: [PATCH] D15158: [PGO] Instrument only base constructors and destructors.

Thank you, Justin. 2015-12-03 5:37 GMT+06:00 Justin Bogner : > Serge Pavlov writes: > > sepavloff created this revision. > > sepavloff added a reviewer: bogner. > > sepavloff added subscribers: cfe-commits, silvas. > > > > Constructors and destructors may be represented by several functions > >

r254876 - [PGO] Instrument only base constructors and destructors.

Author: sepavloff Date: Sun Dec 6 08:32:39 2015 New Revision: 254876 URL: http://llvm.org/viewvc/llvm-project?rev=254876&view=rev Log: [PGO] Instrument only base constructors and destructors. Constructors and destructors may be represented by several functions in IR. Only base structors correspo

Re: [PATCH] D15158: [PGO] Instrument only base constructors and destructors.

This revision was automatically updated to reflect the committed changes. Closed by commit rL254876: [PGO] Instrument only base constructors and destructors. (authored by sepavloff). Changed prior to commit: http://reviews.llvm.org/D15158?vs=41744&id=42011#toc Repository: rL LLVM http://rev

[PATCH] D15450: Avoid double deletion in Clang driver.

sepavloff created this revision. sepavloff added a subscriber: cfe-commits. Llvm module object is shared between CodeGenerator and BackendConsumer, in both classes it is stored as std::unique_ptr, which is not a good design solution and can cause double deletion error. Usually it does not occur be

[clang] [clang] Macro for constant rounding mode (PR #92699)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/92699 >From f8cd2539fb7f0388d7f3955f58b61b09da03bf0c Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Sun, 19 May 2024 18:43:08 +0700 Subject: [PATCH 1/4] [clang] Macro for constant rounding mode MIME-Version: 1.0 Co

[clang] [clang] Macro for constant rounding mode (PR #92699)

spavloff wrote: The discussion for the proposed mechanism is open here: https://discourse.llvm.org/t/rfc-calling-functions-if-pragma-fenv-round-is-present/79372 > > This change introduces macro ROUNDING_MODE, which is a string dependent on > > the constant rounding mode > > It expands to an id

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/85605 >From 07e171e0566ab584299a57c210106bb8220c6261 Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Mon, 18 Mar 2024 13:20:15 +0700 Subject: [PATCH 1/4] [clang] Set correct FPOptions if attribute 'optnone' present

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

spavloff wrote: Ping. https://github.com/llvm/llvm-project/pull/85605 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

spavloff wrote: A little about the significance of this fix. To implement pragma FENV_ROUND, we need to apply the FP options stored in the instance of CompoundStmt to the builder object, so that it uses the specified rounding mode. It can be done using the class CGFPOptionsRAII. However in thi

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

https://github.com/spavloff created https://github.com/llvm/llvm-project/pull/89617 This pragma is introduced by forthcoming C2x standard and can be used to set particular rounding mode without need to call 'fesetmode' or accessing control mode registers directly. Previously this pragma was im

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/89617 >From fc7aab600c25b39b2df039c0cbcf517719736311 Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 14 Apr 2022 18:00:14 +0700 Subject: [PATCH] Implementation of '#pragma STDC FENV_ROUND' This pragma is intro

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

https://github.com/spavloff closed https://github.com/llvm/llvm-project/pull/85605 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

spavloff wrote: Thanks! > Is there any existing bookkeeping we no longer need to do if we're going to > have this RAII object in scope during function parsing? It seems handling fast-math is the only case that prevented using this RAII object. https://github.com/llvm/llvm-project/pull/85605

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/89617 >From 0fc5c57264ecf51f8b9fe8303520a51cb1fee40e Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 14 Apr 2022 18:00:14 +0700 Subject: [PATCH] Implementation of '#pragma STDC FENV_ROUND' This pragma is intro

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/89617 >From 0fc5c57264ecf51f8b9fe8303520a51cb1fee40e Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 14 Apr 2022 18:00:14 +0700 Subject: [PATCH 1/2] Implementation of '#pragma STDC FENV_ROUND' This pragma is i

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

spavloff wrote: Hi @dyung. The observed difference is due to the FP contraction turned off if optnone is specified. In O0 this optimization is still applied. As a result, the function with optnone contains separate fadd and fmul, while without this attribute the function contains combined ope

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

https://github.com/spavloff created https://github.com/llvm/llvm-project/pull/90877 Conversion of floating-point literal to binary representation must be made using constant rounding mode, which can be changed using pragma FENV_ROUND. For example, the literal "0.1F" should be representes by ei

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/90877 >From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 2 May 2024 22:28:05 +0700 Subject: [PATCH 1/2] [clang] Use constant rounding mode for floating literals Conv

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/90877 >From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 2 May 2024 22:28:05 +0700 Subject: [PATCH 1/4] [clang] Use constant rounding mode for floating literals Conv

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/90877 >From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 2 May 2024 22:28:05 +0700 Subject: [PATCH 1/5] [clang] Use constant rounding mode for floating literals Conv

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

@@ -79,3 +79,16 @@ float V7 = []() -> float { 0x0.01p0F); }(); // CHECK: @V7 = {{.*}} float 1.00e+00 + +template struct L { + constexpr L() : value(V) {} + float value; +}; + +#pragma STDC FENV_ROUND FE_DOWNWARD spavloff wrote: In this snippet `Val

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

@@ -79,3 +79,16 @@ float V7 = []() -> float { 0x0.01p0F); }(); // CHECK: @V7 = {{.*}} float 1.00e+00 + +template struct L { + constexpr L() : value(V) {} + float value; +}; + +#pragma STDC FENV_ROUND FE_DOWNWARD spavloff wrote: > Does the FENV_ROUN

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/90877 >From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 2 May 2024 22:28:05 +0700 Subject: [PATCH 1/7] [clang] Use constant rounding mode for floating literals Conv

[clang] [clang] Enable FPContract with optnone (PR #91061)

https://github.com/spavloff created https://github.com/llvm/llvm-project/pull/91061 Previously treatment of the attribute `optnone` was modified in https://github.com/llvm/llvm-project/pull/85605 ([clang] Set correct FPOptions if attribute 'optnone' presents). As a side effect FPContract was d

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

spavloff wrote: Hi @wjristow, Thank you for your detailed analysis. Indeed, FPContract looks more like mandatory option rather than optional optimization. I prepared PR: https://github.com/llvm/llvm-project/pull/91061, which fixes this issue. https://github.com/llvm/llvm-project/pull/85605 __

[clang] [clang] Enable FPContract with optnone (PR #91061)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/91061 >From 32c0ec8a03b0c669dc595894730dd6f8a7933dea Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Sat, 4 May 2024 12:26:22 +0700 Subject: [PATCH 1/2] [clang] Enable FPContract with optnone Previously treatment o

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/90877 >From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 2 May 2024 22:28:05 +0700 Subject: [PATCH 1/8] [clang] Use constant rounding mode for floating literals Conv

[clang] [clang] Enable FPContract with optnone (PR #91061)

@@ -968,10 +968,7 @@ class FPOptionsOverride { setAllowFPContractAcrossStatement(); } - void setDisallowOptimizations() { -setFPPreciseEnabled(true); -setDisallowFPContract(); - } + void setDisallowOptimizations() { setFPPreciseEnabled(true); } -

[clang] [clang] Enable FPContract with optnone (PR #91061)

https://github.com/spavloff closed https://github.com/llvm/llvm-project/pull/91061 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/90877 >From 5d906b537636ca0d8706a8a888dd78edfbec684f Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 2 May 2024 22:28:05 +0700 Subject: [PATCH 01/10] [clang] Use constant rounding mode for floating literals C

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

@@ -79,3 +79,16 @@ float V7 = []() -> float { 0x0.01p0F); }(); // CHECK: @V7 = {{.*}} float 1.00e+00 + +template struct L { + constexpr L() : value(V) {} + float value; +}; + +#pragma STDC FENV_ROUND FE_DOWNWARD spavloff wrote: Explicit instantiati

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/89617 >From ec8838685fb7af618445c3ff1bae953778996c37 Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Thu, 14 Apr 2022 18:00:14 +0700 Subject: [PATCH 1/3] Implementation of '#pragma STDC FENV_ROUND' This pragma is i

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

https://github.com/spavloff edited https://github.com/llvm/llvm-project/pull/89617 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Implementation of '#pragma STDC FENV_ROUND' (PR #89617)

spavloff wrote: > 7.6.2p4 does clearly state that floating constants need to be evaluated > according to the standard rounding mode, so that the constant 0.1 evaluates > to a different value in FE_DOWNWARD versus FE_UPWARD. Treatment of floating-point constants is fixed in https://github.com/

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

spavloff wrote: Hi @SLTozer, Thank you for the report. There is an issue somewhere around the code that reads/wtites records FP_PRAGMA_OPTIONS and/or FLOAT_CONTROL_PRAGMA_OPTIONS, which sometimes manifest itseld in broken synchronization of FP options. I will prepare fix soon. https://github

[clang] [clang] Store FPOptions earlier when parsing function (PR #92146)

https://github.com/spavloff created https://github.com/llvm/llvm-project/pull/92146 After https://github.com/llvm/llvm-project/pull/85605 ([clang] Set correct FPOptions if attribute 'optnone' presents) the current FP options in Sema are saved during parsing function because Sema can modify the

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

spavloff wrote: PR https://github.com/llvm/llvm-project/pull/92146 does not solve the problem of serialization mentioned above, but it is simple and quick solution for the reported crash. https://github.com/llvm/llvm-project/pull/85605 ___ cfe-commit

[clang] [clang] Store FPOptions earlier when parsing function (PR #92146)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/92146 >From 4f6f0acb47d21b25e4e86733a81d609f4de7dc3c Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Tue, 14 May 2024 23:11:21 +0700 Subject: [PATCH 1/2] [clang] Store FPOptions earlier when parsing function After

[clang] [clang] Store FPOptions earlier when parsing function (PR #92146)

@@ -0,0 +1,6 @@ +// RUN: %clang_cc1 -emit-pch -DHEADER -x c++-header %s -o %t.pch +// RUN: %clang_cc1 -emit-llvm -include-pch %t.pch %s -o /dev/null + +#ifdef HEADER +__attribute__((optnone)) void foo() {} +#endif spavloff wrote: It is to avoid redefinition error

[clang] [clang] Store FPOptions earlier when parsing function (PR #92146)

https://github.com/spavloff closed https://github.com/llvm/llvm-project/pull/92146 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

spavloff wrote: Are there any other comments? Can this PR be considered as approved? https://github.com/llvm/llvm-project/pull/90877 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

spavloff wrote: > The changes should come with a release note so that users know about the > behavioral change, but otherwise LGTM. Pragma FENV_ROUND is still officially unsupported, compiler issues a warning about this. It is https://github.com/llvm/llvm-project/pull/89617 that makes FENV_RO

[clang] [clang] Use constant rounding mode for floating literals (PR #90877)

https://github.com/spavloff closed https://github.com/llvm/llvm-project/pull/90877 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Macro for constant rounding mode (PR #92699)

https://github.com/spavloff created https://github.com/llvm/llvm-project/pull/92699 The forthcoming C standard defines pragma FENV_ROUND to support constant rounding mode. It also requires some functions to be evaluated with such mode, N3096 7.6.2p4 states: Within the scope of an FENV_ROU

[clang] [clang] Macro for constant rounding mode (PR #92699)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/92699 >From f8cd2539fb7f0388d7f3955f58b61b09da03bf0c Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Sun, 19 May 2024 18:43:08 +0700 Subject: [PATCH] [clang] Macro for constant rounding mode MIME-Version: 1.0 Conten

[clang] [clang] Macro for constant rounding mode (PR #92699)

@@ -0,0 +1,55 @@ +// RUN: %clang_cc1 -emit-llvm -triple i386-linux -Wno-unknown-pragmas %s -o - | FileCheck %s spavloff wrote: No, this macro is managed by the code in Sema, because pragma FENV_ROUND is processed there. If only `-E` is specified, __ROUNDING_MOD

[clang] [clang] Macro for constant rounding mode (PR #92699)

https://github.com/spavloff ready_for_review https://github.com/llvm/llvm-project/pull/92699 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Macro for constant rounding mode (PR #92699)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/92699 >From f8cd2539fb7f0388d7f3955f58b61b09da03bf0c Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Sun, 19 May 2024 18:43:08 +0700 Subject: [PATCH 1/2] [clang] Macro for constant rounding mode MIME-Version: 1.0 Co

[clang] [clang] Macro for constant rounding mode (PR #92699)

@@ -0,0 +1,55 @@ +// RUN: %clang_cc1 -emit-llvm -triple i386-linux -Wno-unknown-pragmas %s -o - | FileCheck %s spavloff wrote: Parsing pragma FENV_ROUND has been moved to the preprocessor. https://github.com/llvm/llvm-project/pull/92699

[clang] [clang] Macro for constant rounding mode (PR #92699)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/92699 >From f8cd2539fb7f0388d7f3955f58b61b09da03bf0c Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Sun, 19 May 2024 18:43:08 +0700 Subject: [PATCH 1/3] [clang] Macro for constant rounding mode MIME-Version: 1.0 Co

[clang] [clang] Macro for constant rounding mode (PR #92699)

@@ -965,6 +965,16 @@ void Preprocessor::Lex(Token &Result) { LastTokenWasAt = Result.is(tok::at); --LexLevel; + if (Result.is(tok::l_brace)) { +CurlyBraceLevel++; + } else if (Result.is(tok::r_brace)) { +if (!RoundingPragmas.empty() && spavloff w

[clang] [clang] Macro for constant rounding mode (PR #92699)

spavloff wrote: Thanks! I will commit it in a couple of day, if no additional feedback is provided. https://github.com/llvm/llvm-project/pull/92699 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo

[clang] [clang] Allow `ConditionalOperator` fast-math flags to be overridden by `pragma float_control` (PR #105912)

spavloff wrote: I don't think think setting FPOptions in `ConditionalOperator` is a good idea. This operator does not represent any floating-point operation so setting FP properties on it does not look reasonable. Instead, I would like to propose you using FPOptions from CompoundStmt, you cou

[clang] [clang] Allow `ConditionalOperator` fast-math flags to be overridden by `pragma float_control` (PR #105912)

spavloff wrote: > Any instruction that returns a floating-point value can have fast-math flags > attached to it, and because we need to check the fast-math flags on input > operands, the select instruction generated by the conditional operator needs > the flags set when fast-math is enabled. T

[clang] [clang] Set FPOptions at the beginning of CompoundStmt (PR #111654)

https://github.com/spavloff created https://github.com/llvm/llvm-project/pull/111654 CompoundStmt has FPOptions, that should be set for IRBuilder when generating code if that statement. It must fix the issue #84648. >From a7f150c90c301cdd5f55cf6eb44f4e8cf77625f1 Mon Sep 17 00:00:00 2001 From:

[clang] [clang] Allow `ConditionalOperator` fast-math flags to be overridden by `pragma float_control` (PR #105912)

spavloff wrote: I made an alternative PR, which does not need changes in ConditionalOperator: https://github.com/llvm/llvm-project/pull/111654. https://github.com/llvm/llvm-project/pull/105912 ___ cfe-commits mailing list cfe-commits@lists.llvm.org h

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

spavloff wrote: > This sounds like a rejection of safe-by-default. What do you mean by "safe-by-default"? Implementation must be correct, and produce the code that executes in accordance to standards and documentation. Any deviation from them is an error and should be fixed. Does it mean that

[clang] [clang] Set FPOptions at the beginning of CompoundStmt (PR #111654)

spavloff wrote: Ping. https://github.com/llvm/llvm-project/pull/111654 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

spavloff wrote: > > Right, we would need to introduce new llvm.fadd etc. to carry bundles. If > > there are no bundles these could fold back to the regular instruction > > Good. The new intrinsics will be unknown to the optimization passes and thus > be "safe by default". Optimization passes

[clang] [clang] Set FPOptions at the beginning of CompoundStmt (PR #111654)

https://github.com/spavloff updated https://github.com/llvm/llvm-project/pull/111654 >From a47216330a0e14025ba2c29a884d6a96d472dd73 Mon Sep 17 00:00:00 2001 From: Serge Pavlov Date: Wed, 9 Oct 2024 12:55:22 +0700 Subject: [PATCH 1/2] [clang] Set FPOptions at the beginning of CompoundStmt Compo

[clang] [clang] Set FPOptions at the beginning of CompoundStmt (PR #111654)

@@ -1,4 +1,4 @@ -// RUN: %clang_cc1 -ffast-math -ffp-contract=fast -emit-llvm -o - %s | FileCheck %s +// RUN: %clang_cc1 -ffast-math -ffp-contract=fast -emit-llvm -O2 -o - %s | FileCheck %s spavloff wrote: Yes, this fact is reflected in #84648. Actually the pro

[clang] [clang] Set FPOptions at the beginning of CompoundStmt (PR #111654)

@@ -1684,6 +1684,15 @@ class CompoundStmt final return hasStoredFPFeatures() ? getStoredFPFeatures() : FPOptionsOverride(); } + /// Get FPOptions inside this statement. They may differ from the outer + /// options due to pragmas. + /// \param CurFPOptions FPOptions ou

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

https://github.com/spavloff created https://github.com/llvm/llvm-project/pull/109798 Currently floating-point operations in general form (beyond the default mode) are always represented by calls to constrained intrinsics. In addition to the side effect, they carry additional information in the

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

@@ -2994,6 +2994,29 @@ A "convergencectrl" operand bundle is only valid on a ``convergent`` operation. When present, the operand bundle must contain exactly one value of token type. See the :doc:`ConvergentOperations` document for details. +.. _ob_fpe: + +Floating-point Envir

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

@@ -4282,6 +4282,64 @@ static void upgradeDbgIntrinsicToDbgRecord(StringRef Name, CallBase *CI) { CI->getParent()->insertDbgRecordBefore(DR, CI->getIterator()); } +static CallBase *upgradeConstrainedIntrinsicCall(CallBase *CB, Function *F, +

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

spavloff wrote: > I don't think attaching these operand bundles to the existing set of > intrinsics is what we want to do. I'd prefer to deprecate the existing > intrinsics and define some new scheme that uses these bundles on intrinsics > that may be used in other ways. > > One of the origin

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

@@ -4282,6 +4282,64 @@ static void upgradeDbgIntrinsicToDbgRecord(StringRef Name, CallBase *CI) { CI->getParent()->insertDbgRecordBefore(DR, CI->getIterator()); } +static CallBase *upgradeConstrainedIntrinsicCall(CallBase *CB, Function *F, +

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

@@ -2994,6 +2994,29 @@ A "convergencectrl" operand bundle is only valid on a ``convergent`` operation. When present, the operand bundle must contain exactly one value of token type. See the :doc:`ConvergentOperations` document for details. +.. _ob_fpe: + +Floating-point Envir

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

@@ -357,6 +357,9 @@ class IRBuilderBase { void setConstrainedFPCallAttr(CallBase *I) { I->addFnAttr(Attribute::StrictFP); +MemoryEffects ME = MemoryEffects::inaccessibleMemOnly(); spavloff wrote: If a constrained intrinsic like `experimental_constra

[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)

@@ -43,6 +43,15 @@ enum ExceptionBehavior : uint8_t { } +inline bool isValidExceptionBehavior(unsigned X) { spavloff wrote: I think this is historically, because the functionality was implemented by different people. We have "FPE.h" and "FloatingPointMode.h

<    1   2   3   4   5   >