On Fri, Dec 21, 2012 at 12:27 AM, David Tweed <[email protected]> wrote: > Hi, > > One of the corner cases for C family languages is shifts (<< and >>) where > the shift size is not with 0 to "word width". In C99 (and I think most other > C variants) these are undefined while OpenCL defines the meaning to be along > the lines of "integer promote shift variable as required, promote the shift > amount the same way and use the bottom promoted-type-width bits as the shift > amount" (this applies even if the shift amount is originally a negative > number). (Full technical description is in section 6.3j of OpenCL spec.) This > patch implements two parts to this; actually generating the IR in clang is > straightforward. The difficult bit is the front-end semantic diagnostics when > values are known statically. If in OpenCL I something expands to "1<<37" or > "1<<(-4)" it's definitely a well defined program fargment, but should any > judgement be made as to if it is likely to do what the programmer intended? > At the moment I've taken the view that, particularly since Sema shouldn't ac! tually change values by reducing the shift, it's not possible to generate meaningful warnings for this construct in OpenCL, so it returns before most of the bad shift checking in SemaExpr.cpp's DiagnoseBadShiftValues? > > Could this be reviewed and then I'll commit it please?
Please add a testcase like "int a[((int)1)<<33];". We generally don't put braces around single-line if statements. -Eli _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
