search for: unit64_t

Hello Adrian, sorry for the delay with the response. Somehow I missed your message.. On 09/13/2016 12:43 AM, Adrian Prantl wrote: >> On Sep 10, 2016, at 12:50 PM, Victor Leschuk via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello all, >> >> I am currently implementing support for DWARFv5 DW_AT_alignment attr and I got a question about align field in

...about how verbose the output is, since this representation is > primarily used for debugging. > > From how you phrased your reply it is also possible that you were instead > thinking about the in-memory representation? Currently every DIType > (include/IR/DebugInfoMetadata.h) uses a unit64_t field to store the > alignment. > > IIUC, your goal is to avoid emitting a DW_AT_alignment attribute to types > that use the default alignment. Would it make sense to store the target's > default alignment in the DIType::AlignInBits field, so the DWARF backend > can then decid...

...t I hope looking at the diff -u of the .i files gives someone an good impression of how the data types are being swapped about. For one example - I had a very old program that had a typedef for "typedef unsigned long long ulonglong_t;" that would not parse well. When I changed that to unit64_t (as defined in /usr/include/sys/stdint.h) #ifndef _STD_UINT64_T #ifdef __64BIT__ typedef unsigned long uint64_t; #else /* _ILP32 */ #if defined(_LONG_LONG) typedef unsigned long long uint64_t; #endif #endif #endif /* _STD_UINT64_T */ All my compilers and os mix (gcc, xlc, AIX a...

On 2015-12-17 19:30, peter dalgaard wrote: > Presumably the file in question is one of > > Peter-Dalgaards-MacBook-Air:BUILD pd$ grep -r "^Package: tools" * > library/tools/DESCRIPTION:Package: tools > src/library/tools/DESCRIPTION:Package: tools > > so the first thing I'd do is to have a good look at those files and see if they got somehow corrupted. > >