[clang] [OpenMP] Add diagnostic for 'factor' width mismatch in 'unroll partial' (PR #139986)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> Thanks for the review. I’ve implemented all the requested changes but still have a few questions:
> 
>     * Originally, using `IVTy` to query the iteration variable’s width always returned “32-bit int,” even if the loop was declared as `char` or `short`. As a result, errors only appeared when the factor exceeded 32 bits, and the diagnostic always said “int (32 bits).” However, when the loop variable was `long`, the code compiled successfully, so larger types were recognized. I’m not sure whether this was due to how I was reading the type or something else.
> 
>     * In the current implementation I switched to using `OrigVar->getType()` to get the variable’s `Type`. Now `getTypeSize()` correctly returns 8 bits for `char`, 16 for `short`, 64 for `long`, etc. That means code like
>       ```c++
>       #pragma omp unroll partial(0xFFFFF)
>       for (char i = 0; …) { }
>       ```
>       
>       
>           
>             
>           
>       
>             
>           
>       
>           
>         
>       now rejects, whereas it used to compile.
> 
>     * One remaining concern: the bit-width check treats all iteration variables as unsigned. It doesn’t account for signed types. Should I add a separate signed-range check, as suggested here in this [comment](https://github.com/llvm/llvm-project/issues/139268#issuecomment-2867068205)?

I think I need @alexey-bataev or @shiltian to weigh in on what the OpenMP specification expects in these cases. My naive take is that we should be rejecting that code which previously compiled and we should be accounting for signed types.

https://github.com/llvm/llvm-project/pull/139986