search for: stdc

Author: cth Repository: /hg/zfs-crypto/gate Revision: e20f560984a502dbdb00d562c0d053cf86afabe1 Log message: 1183369 scsi_types.h: remove non-STDC typedef of opaque_t as a char * Files: update: usr/src/uts/common/sys/scsi/conf/autoconf.h update: usr/src/uts/common/sys/scsi/conf/device.h update: usr/src/uts/common/sys/scsi/impl/services.h update: usr/src/uts/common/sys/scsi/scsi_ctl.h update: usr/src/uts/common/sys/scsi/scsi_params.h up...

...vide a way to control the FP environment. There are already some target-specific mechanisms for doing that, but I'd like to have something that's target independent. I'll say more about this in a minute. I mentioned in my review comments that my work on this has been motivated by the STDC pragmas, and I think if I explain that it might make the semantics of the intrinsics seem a little more natural. The primary pragma I have in mind here is the "STDC FENV_ACCESS" pragma. I believe this is part of the C99 standard, but compiler support for it is still mostly (if not entir...

...at sas.com>, "bumblebritches57 at gmail.com" <bumblebritches57 at gmail.com>, "cfe-dev at lists.llvm.org" <cfe-dev at lists.llvm.org>, llvm-dev <llvm-dev at lists.llvm.org> Date: 09.01.2018 19:55 Subject: RE: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported? I think we’re going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the re...

...(0.8*z)) b<-(z-0.2)/(0.8*z*R0) dat<-data.frame(years=seq(1983,2004),cobs=c(19032324,19032324,17531618,2 0533029,20298099,20793744,23519369,23131780,19922247,17274513,17034419,1 2448318,4551585,4226451,7183688,7407924,7538366,7336039,8869193,7902341, 6369089,6211886)) stdr<-runif(100,0,0.5) stdc<-runif(100,0,0.5) BC<-runif(1000,0,100) #model calibration calib<-function(x){ v<-sample(stdr,1) cr<-sample(stdc,1) N<-rnorm(1) Bq<-sample(BC,1) Rerr<-exp(N*v-(v^2/2)) Cerr<-exp(N*cr-(cr^2/2)) Bt<-vector();Bt[1]=B0;Bt[2]=B0 Rt<-vector() Ct<-vector()...

+cfe-dev as the discussion is now biased toward C standard. I'm not sure what problem you see here. In default mode, i.e. > when there is no "#pragma STDC FENV_ACCESS on" in effect, > then the compiler can always assume that the default rounding > mode is in effect. Well, if #pragma STDC FENV_ACCESS on is not in effect, that means > that the user has promised that at this point during execution, > we will *always* have the default...

...elson, Clark <clark.nelson at intel.com>; Marcus Johnson <bumblebritches57 at gmail.com>; wei.ding2 at amd.com; llvm-dev <llvm-dev at lists.llvm.org>; Hal Finkel <hfinkel at anl.gov>; Bob Huemmer <bob.huemmer at sas.com> Subject: Re: [cfe-dev] [llvm-dev] Why is #pragma STDC FENV_ACCESS not supported? > On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote: > > On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev > <[1]llvm-dev at lists.llvm.org> wrote: > > Hi Kevin, > Thanks for reaching out about this, and thanks...

Ulrich Weigand/Germany/IBM wrote on 06.03.2018 16:07:34: > So it appears to me that if we need a chain (or control register > dependencies etc.), it would be easier on the back-end anyway to > have a different ISD node, in which case it just might be the easiest > to pass the STRICT_ nodes through to the back-end if it wants ... > > I'll try and go ahead with the SystemZ

I'll give some data points from our OpenVMS Itanium (and Alpha) platforms where we support multiple IEEE modes and dynamic rounding in our C and Fortran compilers (we don't have actual FENV_ACCESS in our C product but you can come close). On the command line, you get to pick IEEE modes with:   /IEEE_MODE         /IEEE_MODE=option         /IEEE_MODE=DENORM_RESULTS (D)      Selects the

...(0.8*z)) b<-(z-0.2)/(0.8*z*R0) dat<-data.frame(years=seq(1983,2004),cobs=c(19032324,19032324,17531618,2 0533029,20298099,20793744,23519369,23131780,19922247,17274513,17034419,1 2448318,4551585,4226451,7183688,7407924,7538366,7336039,8869193,7902341, 6369089,6211886)) stdr<-runif(100,0,0.5) stdc<-runif(100,0,0.5) BC<-runif(1000,0,100) #model calibration calib<-function(x){ v<-sample(stdr,1) cr<-sample(stdc,1) N<-rnorm(1) Bq<-sample(BC,1) Rerr<-exp(N*v-(v^2/2)) Cerr<-exp(N*cr-(cr^2/2)) Bt<-vector();Bt[1]=B0;Bt[2]=B0 Rt<-vector() Ct<-vector()...

Hi all, This proposal is aimed at support of floating point environment, in which some properties like rounding mode or exception behavior differ from those used by default. This include in particular support of 'pragma STDC FENV_ACCESS', 'pragma STDC FENV_ROUND' as well as some other related facilities. Problem On many processors use of non-default floating mode requires modification of global state by writing into some register. It presents a difficulty for implementation as a floating point instruction...

> On Jan 9, 2018, at 11:04 AM, Kevin P. Neal via cfe-dev <cfe-dev at lists.llvm.org> wrote: > >> On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote: >> >> On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev >> <[1]llvm-dev at lists.llvm.org> wrote: >> >> Hi Kevin, >> Thanks for reaching out about this, and

...ment. There are already some > target-specific mechanisms for doing that, but I’d like to have > something that’s target independent. I’ll say more about this in a > minute. > > I mentioned in my review comments that my work on this has been > motivated by the STDC pragmas, and I think if I explain that it > might make the semantics of the intrinsics seem a little more > natural. The primary pragma I have in mind here is the “STDC > FENV_ACCESS” pragma. I believe this is part of the C99 standard, > but compiler support for it is...

Yes, you’re probably right about this. I was originally thinking of FENV_ACCESS as a fully strict mode of operation, but what you’re suggesting aligns with what Cameron suggested and even some of my own reasoning on other points. So, let me amend my previous proposal to say: STDC FENV_ACCESS {ON|OFF} Patch in progress. I think ON should force the following: except_behavior { strict } fenv_access { on } rounding_mode { dynamic } Other modes should be unchanged. Thanks, Andy From: Serge Pavlov <sepavloff at gmail.com> Sent: Wednesday, January 29, 2020...

...inkel <hfinkel at anl.gov>; Richard Smith > <richard at metafoo.co.uk>; bob.huemmer at sas.com; > bumblebritches57 at gmail.com; wei.ding2 at amd.com; cfe-dev at lists.llvm.org; > llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported? > > > Andrew Kaylor wrote: > >In general, the current "strict FP" handling stops at instruction > >selection. At the MachineIR level we don't currently have a mechanism > >to prevent inappropriate optimizations based...

...pecific problem here relates to the default settings for FP contraction, e.g. fused multiply-add. At -O2 and higher, GCC defaults FP contraction to "fast", i.e. always on. I`m not suggesting that Clang/LLVM/both need to do the same, since Clang+LLVM has good support for "#pragma STDC FP_CONTRACT". If we keep Clang`s default for FP contraction at "on" [which really means "according to the pragma"] but change the default value of the _pragma_ [currently off] to on at -O3, then Clang will be more competitive with GCC at high optimization settings withou...

...at sas.com>, "bumblebritches57 at gmail.com" <bumblebritches57 at gmail.com>, "cfe-dev at lists.llvm.org" <cfe-dev at lists.llvm.org>, llvm-dev <llvm-dev at lists.llvm.org> Date: 09.01.2018 19:55 Subject: RE: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported? I think we’re going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the re...

...om> Cc: Ulrich Weigand <Ulrich.Weigand at de.ibm.com>; kpn at neutralgood.org; bumblebritches57 at gmail.com; bob.huemmer at sas.com; llvm-dev <llvm-dev at lists.llvm.org>; Richard Smith <richard at metafoo.co.uk>; cfe-dev at lists.llvm.org Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported? On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote: I think we’re going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing a...

I'm working with Andrew on D43515 right now, and some of these unanswered questions are directly relevant to that patch. So.... On Fri, Feb 09, 2018 at 03:42:20PM +0100, Ulrich Weigand wrote: > C) Floating-point exceptions > If a mask bit in the floating-point status register is set, then all FP > instructions will *trap* whenever an IEEE exception condition is >

...behaviour Sebastian encountered is dealt with before this going live, or we'd be breaking too many test-suites and reverting and reapplying too often. But I'm certainly in favour of the plan to make it on/fast by default. > If you were to change your source file to: > > #pragma STDC FP_CONTRACT ON > int foo(float a, float b, float c) { return a*b+c; } I wasn't aware you needed the pragma for -ffp-contract=on. I assumed it would enable on all fp-math that the standard allowed (thus maybe needing some annotation on the operations). I thought that the pragma was to avoid...

...M, Hal Finkel wrote: On 10/1/19 12:35 AM, Serge Pavlov via llvm-dev wrote: Hi all, This proposal is aimed at support of floating point environment, in which some properties like rounding mode or exception behavior differ from those used by default. This include in particular support of 'pragma STDC FENV_ACCESS', 'pragma STDC FENV_ROUND' as well as some other related facilities. Problem On many processors use of non-default floating mode requires modification of global state by writing into some register. It presents a difficulty for implementation as a floating point instruction...