On Thu, 13 Oct 2005, Misha Brukman wrote:>> How does this tentative plan sound: we have two more weeks of >> development, then start the release processing part on about Oct 31 >> (spooky!). > > In that case, it needs a cool "release name". :)Suggestions welcome! -Chris -- http://nondot.org/sabre/ http://llvm.org/
>> In that case, it needs a cool "release name". :) > > Suggestions welcome!Names of flowers are numerous but not exactly cool. I do not think any other software project has used flower names. Aaron
Well, the subject matter for names ought to pertain to the subject matter of the software. Since LLVM is a "Low Level" Virtual Machine, how about we use the names of subterranean ores: granite, quartz, marble, etc. Agan, not exactly cool, but a little better (IMO) than flowers :) Reid. Aaron Gray wrote:>>> In that case, it needs a cool "release name". :) >> >> >> Suggestions welcome! > > > Names of flowers are numerous but not exactly cool. I do not think any > other software project has used flower names. > > Aaron > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
I'm not sure how many people are using Visual Studio to build the llvm
tools, other than myself? When I compile the llvm tools on linux I do not
see any warnings (I believe -Wall is set?). However, under visual studio
there are a lot of warnings, mostly of this form:
warning C4244: 'initializing' : conversion from 'uint64_t' to
'unsigned
int', possible loss of data
These all seem to be valid warnings although I haven't looked at them
all in detail. The ones I have looked at seem to be OK and intentional.
I am relatively new to using llvm and was wondering, since a release is
planned, how aware anyone was of these warnings under VS and whether I
should spend some time to help clean them up? Or just leave them as is.
Here is a typical examples:
warning C4244: '+=' : conversion from 'uint64_t' to
'unsigned int'
if (ConstantSDNode *CN =
dyn_cast<ConstantSDNode>(N.Val->getOperand(1))) {
Wayne
On Fri, 21 Oct 2005, W Shumaker wrote:> I'm not sure how many people are using Visual Studio to build the llvm > tools, other than myself? When I compile the llvm tools on linux I do not > see any warnings (I believe -Wall is set?). However, under visual studio > there are a lot of warnings, mostly of this form: > > warning C4244: 'initializing' : conversion from 'uint64_t' to 'unsigned > int', possible loss of dataI'm aware of those warnings in a VC++ build, and JeffC (the VC++ maintainer) is too.> These all seem to be valid warnings although I haven't looked at them > all in detail. The ones I have looked at seem to be OK and intentional. > I am relatively new to using llvm and was wondering, since a release is > planned, how aware anyone was of these warnings under VS and whether I > should spend some time to help clean them up? Or just leave them as is. > Here is a typical examples:I've looked at them briefly, and most of them are not actually bugs. Some do indicate that we are missing a feature (e.g. arrays with more than 4G elements) though, so I would be happy if they were cleaned up. If you would like to submit patches to help with it, it would certainly be appreciated.> warning C4244: '+=' : conversion from 'uint64_t' to 'unsigned int' > if (ConstantSDNode *CN = dyn_cast<ConstantSDNode>(N.Val->getOperand(1))) {I'm not sure how this line would cause the warning (not having a +=), maybe it is one nearby? This is an example of the sort of thing where the warning is bogus and needs to be silenced by a cast. CN->getValue() returns a uint64_t, but on 32-bit targets, we know it will always fit into an unsigned. In target-specific code, therefore, casting to an unsigned is safe. In any case, I think it would be great to have a warning free VC++ build! :) -Chris -- http://nondot.org/sabre/ http://llvm.org/