RE: [PATCH] D87528: Enable '#pragma STDC FENV_ACCESS' in frontend

[Blower, Melanie I via cfe-commits]

Thank you.  I don't know the solution but I can remove the assert and create a 
bug report to have it resolved.

> -Original Message-
> From: dmajor via Phabricator 
> Sent: Tuesday, October 27, 2020 11:58 AM
> To: Blower, Melanie I ; sepavl...@gmail.com;
> rjmcc...@gmail.com; rich...@metafoo.co.uk; aaron.ball...@gmail.com
> Cc: dma...@mozilla.com; dexonsm...@apple.com; sca...@apple.com;
> kevin.n...@sas.com; cfe-commits@lists.llvm.org; mlek...@skidmore.edu;
> blitzrak...@gmail.com; shen...@google.com; paul.robin...@sony.com
> Subject: [PATCH] D87528: Enable '#pragma STDC FENV_ACCESS' in frontend
> 
> dmajor added a comment.
> 
> After this commit our bots have a failure on the wasm target, could you please
> take a look?
> 
> test.c:
> 
>   double a, b;
>   c() {
>   #pragma STDC FENV_ACCESS ON
> b == a;
>   }
> 
> Run `clang -cc1 -triple wasm32-unknown-wasi -emit-obj test.c` (clang needs to
> be build with `-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly`)
> 
> Result:
> 
>   clang: /home/vm/src/llvm-
> project/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3764: bool
> (anonymous namespace)::SelectionDAGLegalize::ExpandNode(llvm::SDNode *):
> Assertion `!IsStrict && "Don't know how to expand for strict nodes."' failed.
> 
> 
> Repository:
>   rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D87528/new/
> 
> https://reviews.llvm.org/D87528

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D87528: Enable '#pragma STDC FENV_ACCESS' in frontend

[Blower, Melanie I via cfe-commits]

Actually kludging it by just removing the assert isn't going to work. I'll ping 
Pengfei to see about developing a patch for this problem. 

> -Original Message-
> From: dmajor via Phabricator 
> Sent: Tuesday, October 27, 2020 11:58 AM
> To: Blower, Melanie I ; sepavl...@gmail.com;
> rjmcc...@gmail.com; rich...@metafoo.co.uk; aaron.ball...@gmail.com
> Cc: dma...@mozilla.com; dexonsm...@apple.com; sca...@apple.com;
> kevin.n...@sas.com; cfe-commits@lists.llvm.org; mlek...@skidmore.edu;
> blitzrak...@gmail.com; shen...@google.com; paul.robin...@sony.com
> Subject: [PATCH] D87528: Enable '#pragma STDC FENV_ACCESS' in frontend
> 
> dmajor added a comment.
> 
> After this commit our bots have a failure on the wasm target, could you please
> take a look?
> 
> test.c:
> 
>   double a, b;
>   c() {
>   #pragma STDC FENV_ACCESS ON
> b == a;
>   }
> 
> Run `clang -cc1 -triple wasm32-unknown-wasi -emit-obj test.c` (clang needs to
> be build with `-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly`)
> 
> Result:
> 
>   clang: /home/vm/src/llvm-
> project/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3764: bool
> (anonymous namespace)::SelectionDAGLegalize::ExpandNode(llvm::SDNode *):
> Assertion `!IsStrict && "Don't know how to expand for strict nodes."' failed.
> 
> 
> Repository:
>   rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D87528/new/
> 
> https://reviews.llvm.org/D87528

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] abd0905 - Revert "Revert "Change clang option -ffp-model=precise to select ffp-contract=on""

[Blower, Melanie I via cfe-commits]

Rumeet, Thanks for the additional info.  At some point we'd like to re-commit 
this patch.  LNT testing showed execution time regressions on arch including 
x86 and aarch.  I didn't capture the test names each time but it appeared to be 
approximately the same tests regressing everywhere.  Andy Kaylor took a quick 
look at the x86 regressions and he said it looked like the loop unroller was 
making a bad decision.  We are working out what to do now.  FYI these are the 
x86 tests that failed on the LNT bot:
/home/ssglocal/clang-cmake-x86_64-sde-avx512-linux/clang-cmake-x86_64-sde-avx512-linux/test/sandbox/build/report.simple.csv
Importing 'report.json'
Import succeeded.

--- Tested: 2560 tests --
FAIL: MultiSource/Applications/oggenc/oggenc.execution_time (513 of 2560)
FAIL: MultiSource/Benchmarks/DOE-ProxyApps-C++/CLAMR/CLAMR.execution_time (514 
of 2560)
FAIL: MultiSource/Benchmarks/DOE-ProxyApps-C++/HPCCG/HPCCG.execution_time (515 
of 2560)
FAIL: MultiSource/Benchmarks/DOE-ProxyApps-C++/miniFE/miniFE.execution_time 
(516 of 2560)
FAIL: SingleSource/Benchmarks/Linpack/linpack-pc.execution_time (517 of 2560)
FAIL: SingleSource/Benchmarks/Misc-C++/Large/sphereflake.execution_time (518 of 
2560)
FAIL: 
SingleSource/Benchmarks/Polybench/datamining/correlation/correlation.execution_time
 (519 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/datamining/covariance/covariance.execution_time
 (520 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/kernels/2mm/2mm.execution_time 
(521 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/kernels/3mm/3mm.execution_time 
(522 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/kernels/atax/atax.execution_time
 (523 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/kernels/bicg/bicg.execution_time
 (524 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/kernels/gemver/gemver.execution_time
 (525 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/kernels/gesummv/gesummv.execution_time
 (526 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/kernels/symm/symm.execution_time
 (527 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/kernels/trisolv/trisolv.execution_time
 (528 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/kernels/trmm/trmm.execution_time
 (529 of 2560)
FAIL: 
SingleSource/Benchmarks/Polybench/linear-algebra/solvers/gramschmidt/gramschmidt.execution_time
 (530 of 2560)
FAIL: SingleSource/Benchmarks/Polybench/stencils/adi/adi.execution_time (531 of 
2560)
FAIL: SingleSource/UnitTests/Vector/SSE/sse_expandfft.execution_time (532 of 
2560)
FAIL: SingleSource/UnitTests/Vector/SSE/sse_stepfft.execution_time (533 of 2560)


> -Original Message-
> From: cfe-commits  On Behalf Of via cfe-
> commits
> Sent: Tuesday, February 25, 2020 6:24 PM
> To: cfe-commits@lists.llvm.org
> Subject: cfe-commits Digest, Vol 152, Issue 938
> 
> Send cfe-commits mailing list submissions to
>   cfe-commits@lists.llvm.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> or, via email, send a message with subject or body 'help' to
>   cfe-commits-requ...@lists.llvm.org
> 
> You can reach the person managing the list at
>   cfe-commits-ow...@lists.llvm.org
> 
> When replying, please edit your Subject line so it is more specific than "Re:
> Contents of cfe-commits digest..."
> 
> 
> Today's Topics:
> 
>1. [PATCH] D74912: [AArch64][SVE] Add SVE2 intrinsics for bit
>   permutation & table lookup
>   (Eli Friedman via Phabricator via cfe-commits)
>2. Re: [clang] abd0905 - Revert "Revert "Change clang option
>   -ffp-model=precise to select ffp-contract=on""
>   (Rumeet Dhindsa via cfe-commits)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 25 Feb 2020 23:14:47 + (UTC)
> From: Eli Friedman via Phabricator via cfe-commits
>   
> To: kerry.mclaugh...@arm.com, sander.desma...@arm.com,
>   andrzej.warzyn...@arm.com, dan...@gmail.com,
> cameron.mcina...@nyu.edu,
>   efrie...@quicinc.com, rengo...@gmail.com
> Cc: hanna.kru...@gmail.com, schu...@gmail.com, ju...@samsung.com,
>   llvm-comm...@lists.llvm.org, kanh...@a-bix.com,
>   cfe-commits@lists.llvm.org, sn...@codasip.com,
> simon.m...@emea.nec.com
> Subject: [PATCH] D74912: [AArch64][SVE] Add SVE2 intrinsics for bit
>   permutation & table lookup
> Message-ID: <8ad204f6f5d906623adfa37862e78ee3@localhost.localdomain>
> Content-Type: text/plain; charset=us-ascii
> 
> efriedma accepted this revision.
> efriedma added a comment.
> This revision is now accepted and ready to land.
> 
> LGTM
> 
> 
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D74912/new/
> 
> https://reviews.llvm.org/D74912
> 
> 
> 
> 
> 
> --
> 
> Message: 2
> Date: Tue, 25 Feb 2020 15:21:39 -0800
> From: R

RE: [PATCH] D72841: [RFC] Add support for pragma float_control, to control precision and exception behavior at the source level

[Blower, Melanie I via cfe-commits]

Sorry I don't understand. I have to add "final" onto BinaryOperator in order to 
use Trailing storage. But when I do that I can't derive 
CompoundAssignmentOperator from BinaryOperator.  So I think I must fold these 2 
classes together. Is there another way?

> -Original Message-
> From: John McCall via Phabricator 
> Sent: Wednesday, March 11, 2020 2:19 PM
> To: Blower, Melanie I ; Kaylor, Andrew
> ; kevin.n...@sas.com; rjmcc...@gmail.com;
> sepavl...@gmail.com; ane...@apple.com; matthew.arsena...@amd.com;
> syaghm...@apple.com
> Cc: rekanikol...@gmail.com; wei.di...@amd.com; wuz...@cn.ibm.com;
> lebedev...@gmail.com; nemanja.i@gmail.com;
> jv...@scarletmail.rutgers.edu; kit.bar...@gmail.com; Wang, Pengfei
> ; cfe-commits@lists.llvm.org; llvm-
> comm...@lists.llvm.org; mlek...@skidmore.edu; blitzrak...@gmail.com;
> shen...@google.com; t.p.northo...@gmail.com; paul.robin...@sony.com;
> david.gr...@arm.com; t...@google.com; 1.in...@gmail.com
> Subject: [PATCH] D72841: [RFC] Add support for pragma float_control, to
> control precision and exception behavior at the source level
> 
> rjmccall added a comment.
> 
> In D72841#1917340 , @mibintc
> wrote:
> 
> > @rjmccall Since CompoundAssignmentOperator derives from
> BinaryOperator, it's not simple to add Trailing storage here.  I think I will 
> have to
> fold CompoundAssignmentOperator into BinaryOperator and then add the 2
> extra fields needed by CompoundAssignmentOperator into Trailing storage.  Can
> you think of a better way?  I worked on Trailing storage for UnaryOperator 
> first
> and that wasn't too bad, but Binary is a different story.
> 
> 
> It's something we deal with occasionally, but it's definitely annoying.  You
> basically have to test for which concrete class you have and then ask that 
> class
> for its trailing storage.
> 
> Collapsing the types might be okay but could get involved.
> 
> 
> Repository:
>   rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D72841/new/
> 
> https://reviews.llvm.org/D72841
> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

[Blower, Melanie I via cfe-commits]

I reverted MaskRay's "reland" since the original patch is causing trouble on 
PowerPC, check-all is passing on my box.  Sorry for the trouble. 

> -Original Message-
> From: Andy Kaylor via Phabricator 
> Sent: Thursday, February 13, 2020 9:20 PM
> To: Blower, Melanie I ; lebedev...@gmail.com;
> rjmcc...@gmail.com; sepavl...@gmail.com
> Cc: mask...@google.com; j...@us.ibm.com; david.bolvan...@gmail.com;
> mar...@martin.st; Wang, Pengfei ;
> wuz...@cn.ibm.com; nemanja.i@gmail.com; kit.bar...@gmail.com; cfe-
> comm...@lists.llvm.org; mlek...@skidmore.edu; blitzrak...@gmail.com;
> shen...@google.com; peter.wal...@arm.com
> Subject: [PATCH] D74436: Change clang option -ffp-model=precise to select ffp-
> contract=on
> 
> andrew.w.kaylor added a subscriber: MaskRay.
> andrew.w.kaylor added a comment.
> 
> In D74436#1875386 , @thakis
> wrote:
> 
> > The revert of this breaks tests everywhere, as far as I can tell.
> 
> 
> It looks like something strange happened with the revert:
> 
> > clang-11: warning: overriding '-ffp-model=strict' option with '-ffp-
> model=strict' [-Woverriding-t-option]
> 
> I believe the problem is that the original change that was being reverted
> contained this:
> 
>   clang/lib/Driver/ToolChains/Clang.cpp
>   @@ -2768,7 +2766,7 @@ static void RenderFloatingPointOptions(const
> ToolChain &TC, const Driver &D,
>   !AssociativeMath && !ReciprocalMath &&
>   SignedZeros && TrappingMath && RoundingFPMath &&
>   DenormalFPMath != llvm::DenormalMode::getIEEE() &&
>   +FPContract.empty())
>   -(FPContract.equals("off") || FPContract.empty()))
> 
> But sometime in the land-revert-land-revert cycle the line above that changed,
> causing the merge to miss this change in the most recent revert. I see that
> @MaskRay has since re-landed this change set, but it's going to cause problems
> for PowerPC. If someone needs to revert this yet again, I think it can be 
> safely
> done by recovering the change above.
> 
> Apologies for the mess!
> 
> 
> Repository:
>   rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D74436/new/
> 
> https://reviews.llvm.org/D74436
> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits