llvm dev - Jun 2012 - [LLVMdev] PRIx64 issue on SLES 11

Hey guys,

I'm having trouble with PRIx64 and buddies in the X86 target on SLES 11.
After searching, my issue seems like a generic problem with PRI support on
different OS's.

Here's a decent description of my problem:

http://gcc.gnu.org/ml/gcc-help/2006-10/msg00221.html


Any suggested methods to correct for <inttypes.h> not having the proper
macros defined (besides defining the macros myself)? Has anyone else had
trouble with these macros?


Ty,

Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120601/d9398ed9/attachment.html>

On Fri, Jun 01, 2012 at 02:46:13PM -0400, Cameron McInally
wrote:
> Hey guys,
> 
> I'm having trouble with PRIx64 and buddies in the X86 target on SLES
11.
> After searching, my issue seems like a generic problem with PRI support on
> different OS's.
> 
> Here's a decent description of my problem:
> 
> http://gcc.gnu.org/ml/gcc-help/2006-10/msg00221.html
> 
> 
> Any suggested methods to correct for <inttypes.h> not having the
proper
> macros defined (besides defining the macros myself)? Has anyone else had
> trouble with these macros?
Well, Ian is correct. If you build with a C++ compiler, you need to
define __STDC_FORMAT_MACROS.

Joerg

Someone suggested that I explicitly define the macro __STDC_FORMAT_MACROS,
which seems safe enough.

If anyone has experience with this macro, I would appreciate any more
information.

Thanks again,
Cameron

On Fri, Jun 1, 2012 at 2:46 PM, Cameron McInally
<cameron.mcinally at nyu.edu>wrote:
> Hey guys,
>
> I'm having trouble with PRIx64 and buddies in the X86 target on SLES
11.
> After searching, my issue seems like a generic problem with PRI support on
> different OS's.
>
> Here's a decent description of my problem:
>
> http://gcc.gnu.org/ml/gcc-help/2006-10/msg00221.html
>
>
> Any suggested methods to correct for <inttypes.h> not having the
proper
> macros defined (besides defining the macros myself)? Has anyone else had
> trouble with these macros?
>
>
> Ty,
>
> Cameron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120601/3f944781/attachment.html>

This is a problem with C/C++. <inttypes.h> is a C99 feature, not included
in C++03. <cinttypes> (corresponding to <inttypes.h> in C) is
included in C++11.

If you want to use a C++ compiler (instead of C), you may use 'clang++
-D__STDC_FORMAT_MACROS=' as suggested by Joerg.

It is also possible to replace <inttypes.h> with <cinttypes>. Using
clang++ 3.1 (I assume you not use g++ version 3.4.6 as in the description ;-)
you get:

/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../include/c++/4.3/c++0x_warning.h:36:2:
error: This file requires compiler and library support for the upcoming ISO
      C++ standard, C++0x. This support is currently experimental, and must be
enabled with the -std=c++0x or -std=gnu++0x compiler options.
using 'clang++ -std=c++11', gives

xxx.c:8:35: error: invalid suffix on literal; C++11 requires a space between
literal and identifier [-Wreserved-user-defined-literal]
i.e. you need to insert spaces around PRIx64, but otherwise work as expected.

/Patrik Hägglund

________________________________
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Cameron McInally
Sent: den 1 juni 2012 20:46
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] PRIx64 issue on SLES 11

Hey guys,

I'm having trouble with PRIx64 and buddies in the X86 target on SLES 11.
After searching, my issue seems like a generic problem with PRI support on
different OS's.

Here's a decent description of my problem:


http://gcc.gnu.org/ml/gcc-help/2006-10/msg00221.html


Any suggested methods to correct for <inttypes.h> not having the proper
macros defined (besides defining the macros myself)? Has anyone else had trouble
with these macros?


Ty,

Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120601/17dd63af/attachment.html>