similar to: [LLVMdev] C99 restrict

On Sat, 24 Mar 2007, Christopher Lamb wrote: > Has there been any discussion of supporting the 'restrict' C99 keyword > and C++ extension to boost alias analysis? My impression is that this > would require modification of the LLVM IR. I couldn't find any > discussion hits using the usual suspects for searches... So far, there hasn't been a discussion. IMO, the most

On Mar 25, 2007, at 2:18 AM, Chris Lattner wrote: > On Sat, 24 Mar 2007, Christopher Lamb wrote: >> Has there been any discussion of supporting the 'restrict' C99 >> keyword >> and C++ extension to boost alias analysis? My impression is that this >> would require modification of the LLVM IR. I couldn't find any >> discussion hits using the usual

On Sun, 25 Mar 2007, Christopher Lamb wrote: >> So far, there hasn't been a discussion. IMO, the most important form is >> for formal arguments. That could easily be added thorough the use of an >> attribute on the parameter. > > I assume the idea here is to avoid actually attributing the type (as was > avoided with signed/unsigned integers by differentiating

On Mar 25, 2007, at 5:22 PM, Chris Lattner wrote: > On Sun, 25 Mar 2007, Christopher Lamb wrote: >>> So far, there hasn't been a discussion. IMO, the most important >>> form is >>> for formal arguments. That could easily be added thorough the >>> use of an >>> attribute on the parameter. >> >> I assume the idea here is to

On Mar 26, 2007, at 10:10 AM, Dan Gohman wrote: > On Mon, Mar 26, 2007 at 02:14:56AM -0500, Christopher Lamb wrote: >> >> >> On Mar 25, 2007, at 5:22 PM, Chris Lattner wrote: >> >>> On Sun, 25 Mar 2007, Christopher Lamb wrote: >>>> What about an approach not unlike how debugging information is >>>> handled? That >>>> is have

On Mon, Mar 26, 2007 at 02:14:56AM -0500, Christopher Lamb wrote: > > > On Mar 25, 2007, at 5:22 PM, Chris Lattner wrote: > > > On Sun, 25 Mar 2007, Christopher Lamb wrote: > >> What about an approach not unlike how debugging information is > >> handled? That > >> is have an llvm intrinsic that encodes the known alias free range > >> for

On Mon, 26 Mar 2007, Christopher Lamb wrote: >> For representing scoping information, a relatively non-invasive >> approach is to introduce a special "copy" operation, which in LLVM >> might look like >> %a = copy %b >> This operation has to be somewhat special in that can't be folded away >> in most cases, but it can otherwise be pretty

Christopher Lamb wrote:- > It may even be incorrect for the compiler to enforce the semantics of > restrict pointers (with an error), even when the compilers alias > analysis determines that there is a may-alias relationship between to > pointers. An error is an example of undefined behaviour. Neil.

Hi All, It seems to me that there is potential for doing some target independent loop invariant optimizations in the back end, but prior to instruction selection. For instance, I noticed that the loop invariant constant generated for a loop bounds check is still stuck inside the loop. Likewise constant address generated for globals accessed within a loop are generated on each iteration,

On Sat, 24 Mar 2007, Christopher Lamb wrote: > It seems to me that there is potential for doing some target independent loop > invariant optimizations in the back end, but prior to instruction selection. I assume you mean after instruction selection? > For instance, I noticed that the loop invariant constant generated for a loop > bounds check is still stuck inside the loop.

Dear developeRs, As of icc 10, the -c99 option is deprecated, and generates a lot of warnings when compiling R or R packages. If you use CC="icc -std=c99" instead of just CC="icc", R's configure will not add the -c99 option, and the code seems to compile and run just fine. (Please don't hesitate to let me know if this is a bad idea. :-) -- Regards, Bj?rn-Helge

Today I tried two build R-devel_2011-02-06.tar.gz from sources on FreeBSD 9.0-CURRENT (amd64) with gcc-4.5.2 and I got the following messages when configuring: ./configure [..SNIP..] checking whether C99 double complex is supported... checking complex.h usability... yes checking complex.h presence... yes checking for complex.h... yes checking for double complex... yes checking whether cexp

Reciban un cordial saludo. De manera muy comedida les pido ayuda con la función indicada abajo. La usan en un artículo de inventarios. No veo dónde estoy errado. Gracias de antemano. César Escalante C. > lamb<-50 > L<-1 > h.<-10 > p<-25 > K<-5 > integ<-function(y){integrate(function(x)ppois(x,lamb*L),0,y)$value} > G<-function(y){(h.+p)*integ(y) +

A widely used platform doesn't bother to have C99 integer types, so this allows building with it. Reported by sirlemonhead on IRC. Index: src/tools/oggz_tools.c =================================================================== --- src/tools/oggz_tools.c (revision 3827) +++ src/tools/oggz_tools.c (working copy) @@ -450,7 +450,7 @@ dg->pt = (iframe + pframe) >> 9;

On Mar 25, 2007, at 2:21 AM, Chris Lattner wrote: > On Sat, 24 Mar 2007, Christopher Lamb wrote: >> It seems to me that there is potential for doing some target >> independent loop >> invariant optimizations in the back end, but prior to instruction >> selection. > > I assume you mean after instruction selection? I assumed that to be target independent the

Hi, I would like to know if the command llc -march=c hello.bc generates a c99 file or not. Is the cbackend target meant to be c99 or normal C. -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100219/e67c7a73/attachment.html>

Hi All, I tried to build dovecot-1.1.rc9 on a HP-UX machine, but failed to configure with the following message: configure: error: You don't appear to have C99 compatible vsnprintf() call The environment is like the following: - command: ./configure - uname: HP-UX B.11.23 U ia64 - aCC version: HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003] Also, I tried to run `./configure CC=c99'

I wanted a sort of matrix product of an array and a matrix. As there does not seem to be any array multiplication apart from outer() I proceeded as follows: lambda <- array(0, c(n,m,d)) # stuff omitted # zed is an n by m matrix # # \lamb.star_{ik} lamb.star <- matrix(0, nrow=n, ncol=d) for (i in 1:n) { for (k in 1:d) { for (j in 1:m) { lamb.star[i,k] = lamb.star[i,k] +

Full_Name: Michael Hoffman Version: 2.0.0-beta-20041001 OS: OSF1 V5.1 Submission from: (NULL) (193.62.199.8) Hello. Building R 2.0.0-beta-20041001 on OSF1 V5.1 failed because the default configure sets R_XTRA_CFLAGS to "-std1 -ieee_with_inexact." The bzip2 directory includes C99 code that requires -std1 to not be set in order to compile. This halts the overall build process.

I don't want to drive this too off topic, but I should be clear that I wasn't suggesting that the LLVM project adopt XPJ as it's official config file format for Visual Studio. I have found it useful to use XPJ to generate the initial VS projects for a code base that doesn't already have VS projects. I also find it nice to be able to see all of the config options in a