Hi!
In DataTypes.h (generated from DataTypes.cmake) there is an extra
code path for Visual C.
This can produce macro redefinitions for INT8_MAX, INT8_MIN etc.
since other headers may also define them. Therefore please
protect the macros like INT8_C etc.
Also it would be nice if the auto-generated HAVE_STDINT_H
and HAVE_INTTYPES_H would be used also for Visual C since it
is possible to add them to the global header directory
(e.g. http://msinttypes.googlecode.com/svn/trunk)
-Jochen
Jochen Wilhelmy <j.wilhelmy@arcor.de> writes:
In DataTypes.h (generated from DataTypes.cmake) there is an extra
code path for Visual C.
What's that extra code path?
This can produce macro redefinitions for INT8_MAX, INT8_MIN etc.
since other headers may also define them. Therefore please
protect the macros like INT8_C etc.Also it would be nice if the auto-generated HAVE_STDINT_H
and HAVE_INTTYPES_H would be used also for Visual C since it
is possible to add them to the global header directory
(e.g. http://msinttypes.googlecode.com/svn/trunk)
This can be done, but I have some reservations about it.
My experience with those files which are provided by third parties for
acting as system headers are left forgotten somewhere on the system, or
installed by some piece of code without notice, and then some package
such as LLVM tests for their presence and uses them, much grief and pain
may follow.
[please CC the llvm mailing list]
Jochen Wilhelmy <j.wilhelmy@arcor.de> writes:
What's that extra code path?
#ifndef _MSC_VER
...
#else /* _MSC_VER */
/* Visual C++ doesn't provide standard integer headers, but it does provide
built-in data types. */... extra code path ...
#endif
Sorry, that doesn't show an extra code path. DataTypes.h contains stuff
specific for MSVC and stuff for the rest of compilers. The
#ifndef...#else does just that. Maybe you are reading #ifndef as #ifdef?
This can produce macro redefinitions for INT8_MAX, INT8_MIN etc.
since other headers may also define them. Therefore please
protect the macros like INT8_C etc.Also it would be nice if the auto-generated HAVE_STDINT_H
and HAVE_INTTYPES_H would be used also for Visual C since it
is possible to add them to the global header directory
(e.g. http://msinttypes.googlecode.com/svn/trunk)
This can be done, but I have some reservations about it.
My experience with those files which are provided by third parties for
acting as system headers are left forgotten somewhere on the system, or
installed by some piece of code without notice, and then some package
such as LLVM tests for their presence and uses them, much grief and pain
may follow.
OK I understand this but then please at least protect the #defines
since other libs also may define
them when they assume the absence of stdint.h.Perhaps you could provide a variable that forces the use of stdint.h
and inttypes.h and then I can
define this on the command line. With this solution the user is
responsible for having working
3rd party headers.
Adding just another config option (and one that is speficic of one
compiler) seems overkill to me and would constitute a precedent for
similar cases on the future. I try to keep the config option list as
short as possible.
Protecting the defines, OTOH, is okay.
What's that extra code path?
#ifndef _MSC_VER
...
#else /* _MSC_VER */
/* Visual C++ doesn't provide standard integer headers, but it does provide
built-in data types. */... extra code path ...
#endif
Sorry, that doesn't show an extra code path. DataTypes.h contains stuff
specific for MSVC and stuff for the rest of compilers. The
#ifndef...#else does just that. Maybe you are reading #ifndef as #ifdef?
I just wanted to show you what I mean by the extra code path (the compiler takes
one part of code or another dependent on a define), but obviously you don't call it code path.
How do you call it?
Adding just another config option (and one that is speficic of one
compiler) seems overkill to me and would constitute a precedent for
similar cases on the future. I try to keep the config option list as
short as possible.Protecting the defines, OTOH, is okay.
Yes, protecting the defines will be enough.
- Jochen
Jochen Wilhelmy <j.wilhelmy@arcor.de> writes:
What's that extra code path?
#ifndef _MSC_VER
...
#else /* _MSC_VER */
/* Visual C++ doesn't provide standard integer headers, but it does provide
built-in data types. */... extra code path ...
#endif
Sorry, that doesn't show an extra code path. DataTypes.h contains stuff
specific for MSVC and stuff for the rest of compilers. The
#ifndef...#else does just that. Maybe you are reading #ifndef as #ifdef?
I just wanted to show you what I mean by the extra code path (the
compiler takes
one part of code or another dependent on a define), but obviously you
don't call it code path.
You are talking about an *extra* code path, which to me means something
that we can get rid of because it is unnecessary. I see nothing
unnecessary on DataTypes.h.cmake because, as said before, cmake works
for all build platforms, not only for MSVC.
[snip]
Adding just another config option (and one that is speficic of one
compiler) seems overkill to me and would constitute a precedent for
similar cases on the future. I try to keep the config option list as
short as possible.Protecting the defines, OTOH, is okay.
Yes, protecting the defines will be enough.
Done.
Hi!
what about
#if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS)
in front of the constant macros for visual c to emulate
the behaviour of stdint.h more precisely?
-Jochen
Jochen Wilhelmy <j.wilhelmy@arcor.de> writes:
what about
#if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS)
in front of the constant macros for visual c to emulate
the behaviour of stdint.h more precisely?
What is this good for?
The purpose of DataTypes.h is to provide the pieces LLVM needs and the
platform lacks. Reimplementing some missing header file is overkill,
IMHO.
Hi,
I have been working towards developing compiler optimization tools
targeting multi core processors while using LLVM IR as the starting
point and building on top of the analysis and optimization passes
available in the llvm source.
Recently, I looked into Open64 and its intermediate representation
WHIRL. Documentation for developers to use Open64 seems to be inadequate
(when compared to LLVM documentation). I am planning to download the
source and look into it.
I was wondering if anyone has worked with both LLVM and Open64 and has
some qualitative comparisons between the two. Maybe, in terms of (a)
Ease of developing new passes (2) Ease of debugging (3) Quality of
results (4) Support for developers (5) Documentation (6) Ability to
retarget towards multi core processors.
Thanks in advance
Sincerely
Arvind
CPU Technology
Software Engineer
Hi, Arvind Sudarsanam:
I know some of Open64. Above all, Open64 is designed for a high
performance compiler. It is now supported by AMD, HP, ICT Chinese
Academy of Science, etc. and has been ported to X86, Itanium, Loongson
CPU etc.
And to your questions
1, Open64 already have some main optimization phases, Inline for
aggressive inline opt. LNO for loop opt, WOPT for machine independent
opt( transform WHIRL to SSA , do opt, and transform back to WHIRL),
CG for basic block control flow and target specific opt. You can add
your passes depend on what your opt is.
2, Open64 has dump_* function and traces to get plenty of debugging
information. It is very helpful for developers, According to my
experience, WOPT phases is a little difficult to debug, because of
SSA , alias computation,etc, however, nothing is difficult if you
understand it 
3,What do you mean by quality? According to SPEC CPU official websit,
Open64(or pathscale) get better performance on some X86 and Itanium
processors, you can find more at http://www.pathscale.com/node/18 .
4,Open64 has a maillist, you can get more help there.
http://www.open64.net/mailing-list.html
5. Compare to LLVM and GCC, Open64's document is less. But code is
the best way, and the comment gives many information. : )
6, while for retarget, Open64 use a targ_info directory for machine
description, such as instruction, register, and scheduling
information. While for multi core processors, Open64 already have
openmp support.
While for LLVM, I think other guys in this maillist can give you much
more information : )
yours,
Ling kun
Testing for __STDC_CONSTANT_MACROS
has the advantage that you are forced to define __STDC_CONSTANT_MACROS
on win32. If you then switch to another platform the project still compiles.
-Jochen
By using undefined behavior. No thanks.
The C99/C1X standards, and the C++0X standard, are a direct contradiction regarding whether C++ mode should require __STDC_CONSTANT_MACROS for these macros to work. (C99/C1X requires, C++0X doesn't).
Just because GCC's maintainers made the decision to follow C99/C1X regarding behavior of a header in C++, does not mean a workaround such as DataTypes.h should repeat this choice to force programs to use C++ undefined behavior (use of a macro reserved to the implementation, __STDC_CONSTANT_MACROS) to compile correctly.
(I'm not *positive* that using -D__STD_CONSTANT_MACROS on the command line is compliant [but it seems likely as otherwise the POSIX and C90/C99 standards are in direct contradiction and this hasn't been noticed for ~15 years], but I know that #define __STD_CONSTANT_MACROS 1 in the source is undefined behavior.)
Kenneth
Hi, Arvind & Kun
“Generates crap code, has tons of bugs, the community is disorganized selfish and driven by corporate bullshit”
is Open64.
2010/7/2 Ling Kun <erlv5241@gmail.com>