[llvm-commits] [llvm] r169218 - in /llvm/trunk: include/llvm/ lib/CodeGen/AsmPrinter/ lib/VMCore/ test/CodeGen/ARM/ test/CodeGen/Thumb/ test/CodeGen/X86/ test/DebugInfo/ test/DebugInfo/X86/ test/JitListener/

Bill Wendling isanbard at gmail.com
Tue Dec 4 15:32:06 PST 2012


On Dec 4, 2012, at 2:54 PM, "Robinson, Paul" <Paul.Robinson at am.sony.com> wrote:

>>> When L == 0 we don't emit the lower bound; this is permissible for
>>> languages that default to a lower bound of zero, but not for languages
>>> that have other defaults (or no default).  LLVM does support non-C-family
>>> languages via Dragonegg; FORTRAN and Ada are especially mentioned on the
>>> LLVM home page, and their default lower-bound is 1 not 0.
>>> 
>>> I think Ada supports subrange types directly, not just as array bounds,
>>> in which case omitting either bound is incorrect.  I don't know whether
>>> Dragonegg supports describing subrange types in DWARF though.
>>> 
>> We do support the lower bound being non-zero. :) Here's the code.
> 
> There's a crucial difference between "lower bound is zero" and "lower
> bound is the default."  The former is a language-independent statement,
> the latter is not.
> 
> Ada has a default lower-bound of 1.  But it allows specifying a non-default
> lower-bound, e.g. 0.  If my Ada program declares an array with bounds 0..1
> what does LLVM do?  It looks to me like it would omit DW_AT_lower_bound,
> and supply DW_AT_upper_bound = 1 (because the count is 2).  Knowing that
> it's an Ada program, my debugger will implicitly provide a default lower
> bound of 1, therefore it will think the array bounds are (1..1) not (0..1).
> 
> LLVM just lied to my debugger.  Bad compiler!
> 
> Omitting DW_AT_lower_bound is a language-dependent operation.  LLVM
> currently is not treating it that way; it is assuming the default
> lower bound is 0 for all languages.
> 
Ah, I see what you mean. Yeah, this is bad. Eric should be the one to determine if we should always output the lower bound attribute. :)

-bw





More information about the llvm-commits mailing list