Re: [llvm-dev] DragonEgg for GCC v8.x and LLVM v6.x is just able to work

[Chris Lattner]

> On Sep 4, 2017, at 8:13 PM, Leslie Zhai via llvm-dev 
>  wrote:
> 
> Hi LLVM and GCC developers,
> 
> LLVM China  http://www.llvm.org.cn  forked DragonEgg 
> https://github.com/LLVM-China/dragonegg  because:
> 
> * Some subprojects are impractical or uninteresting to relicense (e.g. 
> llvm-gcc  and dragonegg). These will be split off from the LLVM project (e.g. 
> to separate Github projects), allowing interested people to continue their 
> development elsewhere. 
> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html
> 
> * There are a lot of issues https://github.com/xiangzhai/dragonegg/issues  so 
> I need smarter developers' help.

Hi Leslie,

Out of curiosity, what is motivating this work?  What is the usecase for 
dragonegg these days, now that Clang has great C++ support?  Are you interested 
in Ada + LLVM or some other frontend?

-Chris

Re: [LLVMdev] Zero-cost toolchain standardization process

[Chris Lattner]

On Feb 11, 2014, at 10:59 AM, Renato Golin renato.go...@linaro.org wrote:
 Hi Folks,
 
 First of all, I'd like to thank everyone for their great responses and
 heart warming encouragement for such an enterprise. This will be my
 last email about this subject on these lists, so I'd like to just let
 everyone know what (and where) I'll be heading next with this topic.
 Feel free to reply to me personally, I don't want to span an ugly
 two-list thread.

Renato, thank you for spearheading this, but please do not cross post to both 
lists like this.  Among other problems it is a severe pain for moderation.

I’m a fan of your goals, but I’d like to point out that we have already solved 
this problem in various ways.  For example, C++ ABI issues are dealt with quite 
well across GCC, LLVM, and many other compilers on the “itanium” ABI mailing 
list.  It’s a great example of a list hosted in a “neutral” place that many 
compiler vendors are on, including commercial ones.

Why don’t you just set up a few similar mailing lists to cover related topics 
(toolchain topics, language extensions, etc) and encourage the right people to 
join them?  I feel like you’re turning a simple problem into a complex one.

-Chris

Re: clang vs free software

[Chris Lattner]

On Jan 23, 2014, at 12:14 PM, Steven Bosscher stevenb@gmail.com wrote:
 (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a
 better-supported point of view.)

Unrelated to this thread, it would be great for this web page to get updated.  
You may find it to be a better-supported point of view, but it is also 
comparing against clang 3.2, which is from the end of 2012, and a lot has 
changed since then.

Modern clang versions have its autovectorizor on by default (like GCC's) and 
generate much better code in general.  http://www.phoronix.com/ has done some 
benchmarks across a wider range of code than just spec (which is notoriously 
hacked by compiler developers) and Clang generates better code (and faster) 
than GCC in many cases.

-Chris

Re: gcc : c++11 : full support : eta?

[Chris Lattner]

On Feb 8, 2013, at 8:24 AM, Jeff Law l...@redhat.com wrote:
 I'm not quite sure that this clean split is possible, even after making
 amends for template instantiation.  It's great for syntax-driven tools,
 but once you move beyond that, you tend to ignore stuff like destructors
 (or the cleanup attribute), life-times of temporaries etc., things which
 are just not visible in an AST.  You have to reimplement many program
 analysis algorithms typically part of compiler optimizers, after
 lowering the AST to a less elaborate intermediate representation (a step
 which requires a fair amount of knowledge about the language in question).
 There's always going to be some things that are best done with the raw ASTs 
 and others which are best done when we've got a lowered IL, CFG, SSA graph, 
 etc.
 
 The big question is how well can you go from the output of clang into a lower 
 level IR where you can do in depth analysis and how much you allow optimizers 
 to perturb the results of the analysis.  One could argue that clang - gimple 
 would be a useful translator to allow the nice things from the clang 
 front-end, but also still allow the more in-depth analysis done by our 
 tree-ssa code.

FWIW, the Clang static analyzer uses just such a representation: it is a CFG 
formed out of AST nodes.

-Chris

Re: RFC - Remove support for PCH post 4.8

[Chris Lattner]

On Nov 27, 2012, at 11:36 PM, Xinliang David Li davi...@google.com wrote:
 What you described is the 'transitional model' right? but I don't see

It's not immediately clear from the slides, but the transitional model is the 
only model that we're pursuing.  The other approach is set out in the slides 
for contrast.  The video of the talk should be available soon, hopefully this 
week, which will make it more clear.

 any of those in the C++ standard working paper:
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf

As far as I know, Daveed's proposal has not been implemented, and does not 
reflect the details of what we're implementing in Clang (Doug can give more 
details if you're interested).  Doug and Daveed are working closely on the 
modules WG, which will eventually bring forward an updated proposal.

-Chris

Re: RFC - Remove support for PCH post 4.8

[Chris Lattner]

On Nov 27, 2012, at 8:00 AM, Diego Novillo dnovi...@google.com wrote:
 I admit that I'm partly fishing here, but my proposal is based on the 
 following:
 
 * The implementation of PCH in GCC is atrocious and hard to maintain.
 * The next C++ standard is likely to define modules
 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf)
 * The user-base for PCH is negligibly small (here's where I'm mostly 
 guessing).
 * PCH is absolutely useless for C.

PCH is used extensively in Objective-C code and many C++ applications that also 
build for windows.  I'm not sure how important these communities are though...

-Chris

 
 Removing PCH will give us more implementation freedom for the memory
 management project
 (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives).
 
 With some effort, we could revive the streaming work done in the PPH
 branch and re-implement PCH with it (when we abandoned the branch, we
 were probably 80% complete as a PCH replacement). If we could at least
 remove support for C, then I can see a streaming-based PCH for the 4.9
 release.
 
 Thoughts?
 
 Are there any big PCH users out there?
 
 
 Thanks.  Diego.

Re: RFC - Remove support for PCH post 4.8

[Chris Lattner]

On Nov 27, 2012, at 3:32 PM, Eric Botcazou ebotca...@adacore.com wrote:

 I admit that I'm partly fishing here, but my proposal is based on the
 following:
 
 * The implementation of PCH in GCC is atrocious and hard to maintain.
 * The next C++ standard is likely to define modules
 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf)
 * The user-base for PCH is negligibly small (here's where I'm mostly
 guessing). * PCH is absolutely useless for C.
 
 Removing PCH will give us more implementation freedom for the memory
 management project
 (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives).
 
 One of the arguments put forward to advocate the transition to C++ was the 
 competition.  Where do the other compilers stand when it comes to PCHs?

Clang has fantastic support for PCH... and soon modules.  We don't plan to drop 
PCH support when modules is implemented.

-Chris

Re: RFC - Remove support for PCH post 4.8

[Chris Lattner]

On Nov 27, 2012, at 5:16 PM, Xinliang David Li davi...@google.com wrote:
 Removing PCH will give us more implementation freedom for the memory
 management project
 (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives).
 
 One of the arguments put forward to advocate the transition to C++ was the
 competition.  Where do the other compilers stand when it comes to PCHs?
 
 
 Clang has fantastic support for PCH... and soon modules.
 
 Are they sharing some implementations?

Yes, absolutely.  In the GCC terminology, both use a streaming approach for 
writing out code, and a lot of the mechanics of that streaming logic are 
similar.  Modules adds a bunch of additional logic on top of what PCH uses 
though.

-Chris

Re: RFC - Remove support for PCH post 4.8

[Chris Lattner]

On Nov 27, 2012, at 9:08 PM, Miles Bader mi...@gnu.org wrote:

 Chris Lattner clatt...@apple.com writes:
 Clang has fantastic support for PCH... and soon modules.  We don't
 plan to drop PCH support when modules is implemented.
 
 Do you have a pointer to the modules proposal clang will implement?

Most of it is implemented in mainline Clang already.  Here is a recent talk 
describing it:
http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

Doug is also the chair of the C++ working group on modules, leading the effort 
to standardize it (along with Lawrence and others).

-Chris

Re: RFC - Remove support for PCH post 4.8

[Chris Lattner]

On Nov 27, 2012, at 11:05 PM, Xinliang David Li davi...@google.com wrote:

 On Tue, Nov 27, 2012 at 10:40 PM, Chris Lattner clatt...@apple.com wrote:
 
 On Nov 27, 2012, at 9:08 PM, Miles Bader mi...@gnu.org wrote:
 
 Chris Lattner clatt...@apple.com writes:
 Clang has fantastic support for PCH... and soon modules.  We don't
 plan to drop PCH support when modules is implemented.
 
 Do you have a pointer to the modules proposal clang will implement?
 
 Most of it is implemented in mainline Clang already.
 
 For Object-C or C++?

C and Objective-C are nearly complete, C++ support is still in progress.

 
 Here is a recent talk describing it:
 http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf
 
 
 It is likely that the module file format will be standardized in the
 future, so it is better for different communities to start move in the
 same direction. Is the module format adopted by Clang documented
 anywhere?

No, the design does not require a binary compatible file format.  Header files 
and module maps remain the truth.  Any binary file format produced by a 
compiler as a side effect of building is an implementation detail of that 
compiler.

-Chris

Re: Backtrace library [1/3]

[Chris Lattner]

On Sep 11, 2012, at 3:53 PM, Ian Lance Taylor i...@google.com wrote:

 I have finished the initial implementation of the backtrace library I
 proposed at http://gcc.gnu.org/ml/gcc/2012-08/msg00317.html .  I've
 separated the work into three patches.  These patches only implement the
 backtrace library itself; actual use of the library will follow in
 separate patches.

Hi Ian,

I have no specific comment on the implementation of this library, but:
 
 +/* Get a full stack backtrace.  SKIP is the number of frames to skip;
 +   passing 0 will start the trace with the function calling backtrace.
 +   DATA is passed to the callback routine.  If any call to CALLBACK
 +   returns a non-zero value, the stack backtrace stops, and backtrace
 +   returns that value; this may be used to limit the number of stack
 +   frames desired.  If all calls to CALLBACK return 0, backtrace
 +   returns 0.  The backtrace function will make at least one call to
 +   either CALLBACK or ERROR_CALLBACK.  This function requires debug
 +   info for the executable.  */
 +
 +extern int backtrace (int skip, backtrace_callback callback,
 +   backtrace_error_callback error_callback, void *data);

FYI, backtrace is a well-known function provide by glibc (and other libc's).  
It might be best to pick another name.

-Chris

Re: Backtrace library [1/3]

[Chris Lattner]

On Sep 11, 2012, at 4:24 PM, Ian Lance Taylor i...@google.com wrote:

 On Tue, Sep 11, 2012 at 4:07 PM, Chris Lattner clatt...@apple.com wrote:
 
 FYI, backtrace is a well-known function provide by glibc (and other 
 libc's).  It might be best to pick another name.
 
 Good point.  Thanks.  I renamed it to backtrace_full.  I've included
 the updated backtrace.h here.  The other changes are mechanical.

What do you think of (poor man's) namespacification?  You could prefix symbols 
with libbacktrace_, which I think is much less likely to conflict, and be 
much more clear to clients.

-Chris

Re: RFC: -Wall by default

[Chris Lattner]

On Apr 13, 2012, at 5:09 PM, NightStrike wrote:
 Can the -Winf option really happen?  It should be easy to make that
 turn on every -W option without having the manually list them and keep
 it up to date.  Like, it should be easy, I would hope, to make that be
 automatic.  Even if just used as a toy, I think this is a neat idea
 that would not require much work.

Clang has -Weverything, which really does turn on every warning:
http://clang.llvm.org/docs/UsersManual.html#diagnostics_enable_everything

People who like warnings (and like to know when a new build of the compiler 
adds something) really like this.   OTOH, being able to support this well 
requires that all warnings have an associated -Wno-XX flag associated with them.

-Chris

Re: Dealing with compilers that pretend to be GCC

[Chris Lattner]

On Jan 31, 2012, at 4:58 AM, Marc Glisse wrote:
 The docs say that ‘__has_builtin’  co. are macros.  What do they expand 
 to?
 
 0 or 1.
 
 I understand.  To put it another way, how are they defined?
 
 Compiler magic, like __LINE__ for instance? I am still not sure what you are 
 asking...

Yes, they are compiler magic.  __has_attribute() __has_extension() etc all work 
the same way as well.

 Interestingly enough:
 $ cat q.c
 __has_builtin
 $ clang -E q.c
 segfault

Nice catch, fixed in r149397.  Thanks!

-Chris

Re: Dealing with compilers that pretend to be GCC

[Chris Lattner]

On Jan 31, 2012, at 5:15 AM, Ludovic Courtès wrote:

 
 Interestingly enough:
 $ cat q.c
 __has_builtin
 $ clang -E q.c
 segfault
 
 Yes, that’s what I was asking.
 
 It makes me think that the old CPP predicates (info (gcc) Obsolete
 Features) would be more appropriate than compiler magic, with the
 caveat that they’re presumably not widely supported.

They are similar in spirit.  The major difference between the two is that it is 
easy for __has_feature and friends gracefully degrade when a compiler doesn't 
support them, because you can do:

#ifndef __has_builtin
#define __has_builtin(x) 0
#endif

in your code, but you can't do anything like this for #assertion.  That and 
assertions don't have any coverage over the features that you're interested in, 
and the grammar doesn't have a good way to handle multiple cases like 
features/attributes/extensions/etc.

-Chris

Re: Dealing with compilers that pretend to be GCC

[Chris Lattner]

On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote:

 Hello,
 
 Chris Lattner clatt...@apple.com skribis:
 
 On Jan 20, 2012, at 5:24 PM, Jonathan Wakely jwakely@gmail.com wrote:
 
 On 21 January 2012 00:32, Vincent Lefevre wrote:
 On 2012-01-20 23:28:07 +, Jonathan Wakely wrote:
 May I politely suggest that this is the wrong place to complain about
 other compilers pretending to be GCC :)
 
 I think that's the fault of GCC, which should have defined a macro
 for each extension.
 
 And what about the fact other compilers haven't defined such a macro
 for each extension they implement, whether it comes from GCC or not,
 is that GCC's fault too?
 
 If fact, some do:
 http://clang.llvm.org/docs/LanguageExtensions.html#feature_check
 
 That seems like a very useful approach to solve the problem.
 
 The docs say that ‘__has_builtin’  co. are macros.  What do they expand to?  

0 or 1.

-Chris

Re: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'

[Chris Lattner]

On Jan 29, 2012, at 1:30 PM, Georg-Johann Lay wrote:

 Hi,
 
 may I propose to change this message to a more user-friendly one?
 
 In most cases, the message is triggered by a typo like here:
 
 Int foo (void)
 {
return 1;
 }
 
 A message like
 
 error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
 
 is just pain to the eyes, and apart from that it is not more helpful than a 
 simple syntax error before 'foo':

FWIW, Clang produces:

t.c:1:1: error: unknown type name 'Int'; did you mean 'int'?
Int foo (void)
^

http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
:)

-Chris

Re: Dealing with compilers that pretend to be GCC

[Chris Lattner]

Why not just implement the clang feature checking macros?
http://clang.llvm.org/docs/LanguageExtensions.html#feature_check

Besides fixing the whole problem that this thread identifies, it doesn't 
require cramming tons of macros into the initial preprocessor state, speeding 
up compiler startup time.

-Chris

On Jan 21, 2012, at 12:14 AM, Basile Starynkevitch bas...@starynkevitch.net 
wrote:

 On Sat, 21 Jan 2012 01:32:29 +0100
 Vincent Lefevre vincent+...@vinc17.org wrote:
 
 On 2012-01-20 23:28:07 +, Jonathan Wakely wrote:
 May I politely suggest that this is the wrong place to complain about
 other compilers pretending to be GCC :)
 
 I think that's the fault of GCC, which should have defined a macro
 for each extension.
 
 
 I agree with that. And I even hope that if GCC 4.7 defined several macros, 
 one for each
 extensions, like e.g.
   __GCC_HAVE_INDIRECT_GOTO__  for the goto *x; feature
   __GCC_HAVE_STATEMENT_EXPR__ for statement expressions
 etc then perhaps in several years other compilers would do likewise. We just 
 have to
 document our features and their corresponding macros...
 
 Regards. 
 
 
 -- 
 Basile STARYNKEVITCH http://starynkevitch.net/Basile/
 email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
 8, rue de la Faiencerie, 92340 Bourg La Reine, France
 *** opinions {are only mine, sont seulement les miennes} ***

Re: Dealing with compilers that pretend to be GCC

[Chris Lattner]

On Jan 20, 2012, at 5:24 PM, Jonathan Wakely jwakely@gmail.com wrote:

 On 21 January 2012 00:32, Vincent Lefevre wrote:
 On 2012-01-20 23:28:07 +, Jonathan Wakely wrote:
 May I politely suggest that this is the wrong place to complain about
 other compilers pretending to be GCC :)
 
 I think that's the fault of GCC, which should have defined a macro
 for each extension.
 
 And what about the fact other compilers haven't defined such a macro
 for each extension they implement, whether it comes from GCC or not,
 is that GCC's fault too?

If fact, some do:
http://clang.llvm.org/docs/LanguageExtensions.html#feature_check

-Chris

Re: Vector shuffling

[Chris Lattner]

On Aug 31, 2011, at 1:27 AM, Artem Shinkarov wrote:

 If you're going to add vector shuffling builtins, you might consider adding 
 the same builtin that clang has for compatibility:
 http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector
 
 It should be straight-forward to map it into the same IR.
 
 -Chris
 
 
 Chris
 
 I am trying to use OpenCL syntax here which says that the mask for
 shuffling is a vector. Also I didn't really get from the clang
 description if the indexes could be non-constnants? If not, then I
 have a problem here, because I want to support this.

Yes, constant elements are required for this builtin.  It is an implementation 
detail, but Clang doesn't implement the OpenCL shuffle operations with builtins.

-Chris

Re: Vector shuffling

[Chris Lattner]

On Aug 30, 2011, at 10:01 AM, Artem Shinkarov wrote:
 The patch at the moment lacks of some examples, but mainly it works
 fine for me. It would be nice if i386 gurus could look into the way I
 am doing the expansion.
 
 Middle-end parts seems to be more or less fine, they have not changed
 much from the previous time.
 
 +@code{__builtin_shuffle (vec, mask)} and
 +@code{__builtin_shuffle (vec0, vec1, mask)}. Both functions construct
 
 the latter would be __builtin_shuffle2.
 
 Why??
 That was the syntax we agreed on that elegantly handles both cases in one 
 place.

If you're going to add vector shuffling builtins, you might consider adding the 
same builtin that clang has for compatibility:
http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector

It should be straight-forward to map it into the same IR.

-Chris

Re: darwin LTO broken under Xcode 3.2.6/4.0

[Chris Lattner]

On Mar 13, 2011, at 8:38 AM, Jack Howarth wrote:

 On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote:
   With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made 
 to
 the darwin assembler which effectively breaks LTO support for darwin. The 
 design
 of LTO on darwin was based on the fact that mach-o object files tolerated 
 additional
 sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the 
 assembler
 appears to be strictly counting sections and objecting when these exceed 
 255. This
 breaks huge sections of the lto testsuite and prevents larger projects like 
 xplor-nih
 to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple 
 reverts this
 change, our only recourse would be to resort to an elf object container for 
 the lto
 sections within the mach-o files (introducing an undesired dependency on 
 libelf for
 FSF gcc on darwin). My understanding was that the lto design did not allow 
 the number
 of sections required in the lto files to be reduced.
 
 If the problem is not fixed, we could always pack all the LTO sections into 
 one section containing
 our own subsections.
 
 Honza
 
 Jan,
  If this could be done without resorting to other container types (like elf), 
 it might be
 the wisest approach for the long run. I've read through the mach-o 
 documentation and it
 seems rather vague on the section limits. Even if Apple fixes Xcode (which 
 likley won't
 happen for 6-9 months at best), we always we have to worry that they will 
 break this 
 'feature' somewhere else in their tool chain. Better to follow the strictest 
 possible reading
 of mach-o object format to protect ourselves from overzealous Apple interns.

Yes, I agree that this is a better solution.  This error was put into the 
linker to detect some overflow conditions for part of the code that expected 
the section number to only be a byte.  It is likely that things worked only 
out of luck before.

-Chris

Re: darwin LTO broken under Xcode 3.2.6/4.0

[Chris Lattner]

On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:

 Yes, I agree that this is a better solution.  This error was put into the 
 linker to detect some overflow conditions for part of the code that expected 
 the section number to only be a byte.  It is likely that things worked 
 only out of luck before.
 
 -Chris
 
 Chris,
   Is there any documentation or example code on how to properly use 
 subsections in mach-o?
 My fear is that we are moving from one poorly documented technique to another 
 which may well
 have it own slate of hidden bugs.

I'm not sure what you mean here Jack.  ld64 is open source on the darwin page, 
and if you have all the developer bits installed, the format is documented in 
/usr/include/mach-o/.  It's pretty clear all around that you can only have 256 
sections.

-Chris

Re: darwin LTO broken under Xcode 3.2.6/4.0

[Chris Lattner]

On Mar 13, 2011, at 11:55 AM, Chris Lattner wrote:
 On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
 
 Yes, I agree that this is a better solution.  This error was put into the 
 linker to detect some overflow conditions for part of the code that 
 expected the section number to only be a byte.  It is likely that things 
 worked only out of luck before.
 
 -Chris
 
 Chris,
  Is there any documentation or example code on how to properly use 
 subsections in mach-o?
 My fear is that we are moving from one poorly documented technique to 
 another which may well
 have it own slate of hidden bugs.
 
 I'm not sure what you mean here Jack.  ld64 is open source on the darwin 
 page, and if you have all the developer bits installed, the format is 
 documented in /usr/include/mach-o/.  It's pretty clear all around that you 
 can only have 256 sections.

Sorry, I actually mean 255 of course, because of the NO_SECT sentinel.  Here 
are the relevant bits from nlist.h.  I'm not sure how you expect the toolchain 
to store more than 256 sections in a uint8_t.

This is not the conspiracy you are looking for.

-Chris



/*
 * Format of a symbol table entry of a Mach-O file for 32-bit architectures.
 * Modified from the BSD format.  The modifications from the original format
 * were changing n_other (an unused field) to n_sect and the addition of the
 * N_SECT type.  These modifications are required to support symbols in a larger
 * number of sections not just the three sections (text, data and bss) in a BSD
 * file.
 */
struct nlist {
union {
#ifndef __LP64__
char *n_name;   /* for use when in-core */
#endif
int32_t n_strx; /* index into the string table */
} n_un;
uint8_t n_type; /* type flag, see below */
uint8_t n_sect; /* section number or NO_SECT */
int16_t n_desc; /* see mach-o/stab.h */
uint32_t n_value;   /* value of this symbol (or stab offset) */
};

/*
 * This is the symbol table entry structure for 64-bit architectures.
 */
struct nlist_64 {
union {
uint32_t  n_strx; /* index into the string table */
} n_un;
uint8_t n_type;/* type flag, see below */
uint8_t n_sect;/* section number or NO_SECT */
uint16_t n_desc;   /* see mach-o/stab.h */
uint64_t n_value;  /* value of this symbol (or stab offset) */
};

/*
 * If the type is N_SECT then the n_sect field contains an ordinal of the
 * section the symbol is defined in.  The sections are numbered from 1 and 
 * refer to sections in order they appear in the load commands for the file
 * they are in.  This means the same ordinal may very well refer to different
 * sections in different files.
 *
 * The n_value field for all symbol table entries (including N_STAB's) gets
 * updated by the link editor based on the value of it's n_sect field and where
 * the section n_sect references gets relocated.  If the value of the n_sect 
 * field is NO_SECT then it's n_value field is not changed by the link editor.
 */
#define NO_SECT 0   /* symbol is not in any section */
#define MAX_SECT255 /* 1 thru 255 inclusive */

Re: darwin LTO broken under Xcode 3.2.6/4.0

[Chris Lattner]

On Mar 13, 2011, at 12:07 PM, Jan Hubicka wrote:

 
 Yes, I agree that this is a better solution.  This error was put into the 
 linker to detect some overflow conditions for part of the code that expected 
 the section number to only be a byte.  It is likely that things worked 
 only out of luck before.
 
 Interesting, so there is no -ffunction-section type tricks at darwin?

Correct, darwin doesn't support that flag in a useful way.  Instead, macho has 
a (poorly defined and understood) concept of atoms that the linker uses to 
slice things up.

-Chris

 
 Pickling everything into single section seems indeed like easiest approach 
 here.
 The question is who will volunteer to implement it ;)
 
 Honza

Re: darwin LTO broken under Xcode 3.2.6/4.0

[Chris Lattner]

On Mar 13, 2011, at 12:05 PM, Jack Howarth wrote:

 On Sun, Mar 13, 2011 at 11:55:02AM -0700, Chris Lattner wrote:
 
 On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
 
 Yes, I agree that this is a better solution.  This error was put into the 
 linker to detect some overflow conditions for part of the code that 
 expected the section number to only be a byte.  It is likely that things 
 worked only out of luck before.
 
 -Chris
 
 Chris,
  Is there any documentation or example code on how to properly use 
 subsections in mach-o?
 My fear is that we are moving from one poorly documented technique to 
 another which may well
 have it own slate of hidden bugs.
 
 I'm not sure what you mean here Jack.  ld64 is open source on the darwin 
 page, and if you have all the developer bits installed, the format is 
 documented in /usr/include/mach-o/.  It's pretty clear all around that you 
 can only have 256 sections.
 
 -Chris
 
 Chris,
  The mach-o reference has a cryptic mention of MH_SUBSECTIONS_VIA_SYMBOLS in
 
 http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
 
 MH_SUBSECTIONS_VIA_SYMBOLS—The sections of the object file can be divided 
 into individual blocks. These blocks are dead-stripped if they are not used 
 by other code. See Linking for details.

Right, subsections via symbols is the concept of slicing up a section into 
atoms based on public labels.  The linker uses this to do dead code 
elimination etc.  I don't think this helps you at all though.

I don't understand why you can't put arbitrary data into a single section.  
This is what the -sectcreate flag to the linker does, so it is simple, already 
supported, and tested.

-Chris

 
 Although I don't think this helps us at all because none of the GNU_LTO 
 sections contain symbols. This is why I
 am still perplexed by this assembler change. We followed the rules Nick 
 suggested of placing all of these GNU_LTO
 sections at the end of the file and none contain symbols. In that case, it 
 would really seem that the assembler is
 now blindly counting sections without respect to whether any of them actually 
 contain symbols.
  Jack

Re: darwin LTO broken under Xcode 3.2.6/4.0

[Chris Lattner]

On Mar 13, 2011, at 12:42 PM, Steven Bosscher wrote:

 (sorry Chris, I forgot the list)
 
 On Mar 13, 2011, at 11:59 AM, Chris Lattner wrote:
 
 Sorry, I actually mean 255 of course, because of the NO_SECT
 sentinel.  Here are the relevant bits from nlist.h.  I'm not
 sure how you expect the toolchain to store more than 256
 sections in a uint8_t.
 
 How self-righteous, and misinformed.
 
 No-one is expecting to store 256 in a uint8_t. The structures you
 quote only apply to symbol tables, which are references into sections
 in Mach-O. But not all sections have symbols. None of the sections in
 the GNU_LTO segment have symbols.

That data structure only has to do with symbol tables.  However, various tools 
that work on MachO have the exact same limitation in their internal data 
structures, since there can't be more than 256 sections.

I'm sorry that the toolchain doesn't work the way you'd like it to, but the 
right answer is still to plop whatever metadata you guys want into a single 
section.

-Chris


 
 The documentation you should be quoting is the part about Mach-O
 loader commands, and there is no limit AFAICT on the number of
 LC_SEGMENT/LC_SEGMENT_64 loader commands. There is also nothing in the
 segment command structures that suggests a limit of 255 sections.
 
 Besides, it worked before, which suggests that, well, it worked.
 
 This is not the limitation of Mach-O you are looking for.
 
 Ciao!
 Steven

Re: operator new[] overflow (PR 19351)

[Chris Lattner]

On Dec 5, 2010, at 3:19 AM, Richard Guenther wrote:

 $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm 
 -show-mc-encoding
.section__TEXT,__text,regular,pure_instructions
.globl  __Z4testl
.align  4, 0x90
 __Z4testl:  ## @_Z4testl
 ## BB#0:## %entry
movl$4, %ecx## encoding: 
 [0xb9,0x04,0x00,0x00,0x00]
movq%rdi, %rax  ## encoding: [0x48,0x89,0xf8]
mulq%rcx## encoding: [0x48,0xf7,0xe1]
movq$-1, %rdi   ## encoding: 
 [0x48,0xc7,0xc7,0xff,0xff,0xff,0xff]
cmovnoq %rax, %rdi  ## encoding: [0x48,0x0f,0x41,0xf8]
jmp __Znam  ## TAILCALL
## encoding: [0xeb,A]
##   fixup A - offset: 1, value: 
 __Znam-1, kind: FK_PCRel_1
 .subsections_via_symbols
 
 This could be further improved by inverting the cmov condition to avoid the 
 first movq, which we'll tackle as a general regalloc improvement.
 
 I'm curious as on how you represent the overflow checking in your highlevel 
 IL.

The (optimized) generated IR is:

$ clang t.cc -emit-llvm -S -o - -O3
...
define noalias i8* @_Z4testl(i64 %count) ssp {
entry:
  %0 = tail call %0 @llvm.umul.with.overflow.i64(i64 %count, i64 4)
  %1 = extractvalue %0 %0, 1
  %2 = extractvalue %0 %0, 0
  %3 = select i1 %1, i64 -1, i64 %2
  %call = tail call noalias i8* @_Znam(i64 %3)
  ret i8* %call
}

More information on the overflow intrinsics is here:
http://llvm.org/docs/LangRef.html#int_overflow

-Chris

Re: operator new[] overflow (PR 19351)

[Chris Lattner]

On Dec 5, 2010, at 9:49 AM, Chris Lattner wrote:

 
 On Dec 5, 2010, at 3:19 AM, Richard Guenther wrote:
 
 $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm 
 -show-mc-encoding
   .section__TEXT,__text,regular,pure_instructions
   .globl  __Z4testl
   .align  4, 0x90
 __Z4testl:  ## @_Z4testl
 ## BB#0:## %entry
   movl$4, %ecx## encoding: 
 [0xb9,0x04,0x00,0x00,0x00]
   movq%rdi, %rax  ## encoding: [0x48,0x89,0xf8]
   mulq%rcx## encoding: [0x48,0xf7,0xe1]
   movq$-1, %rdi   ## encoding: 
 [0x48,0xc7,0xc7,0xff,0xff,0xff,0xff]
   cmovnoq %rax, %rdi  ## encoding: [0x48,0x0f,0x41,0xf8]
   jmp __Znam  ## TAILCALL
   ## encoding: [0xeb,A]
   ##   fixup A - offset: 1, value: 
 __Znam-1, kind: FK_PCRel_1
 .subsections_via_symbols
 
 This could be further improved by inverting the cmov condition to avoid the 
 first movq, which we'll tackle as a general regalloc improvement.
 
 I'm curious as on how you represent the overflow checking in your highlevel 
 IL.
 
 The (optimized) generated IR is:
 
 $ clang t.cc -emit-llvm -S -o - -O3
 ...
 define noalias i8* @_Z4testl(i64 %count) ssp {
 entry:
  %0 = tail call %0 @llvm.umul.with.overflow.i64(i64 %count, i64 4)
  %1 = extractvalue %0 %0, 1
  %2 = extractvalue %0 %0, 0
  %3 = select i1 %1, i64 -1, i64 %2
  %call = tail call noalias i8* @_Znam(i64 %3)
  ret i8* %call
 }

Sorry, it's a little easier to read with expanded names and types:

define noalias i8* @_Z4testl(i64 %count) ssp {
entry:
  %A = tail call { i64, i1 } @llvm.umul.with.overflow.i64(i64 %count, i64 4)
  %B = extractvalue { i64, i1 } %A, 1
  %C = extractvalue { i64, i1 } %A, 0
  %D = select i1 %B, i64 -1, i64 %C
  %call = tail call noalias i8* @_Znam(i64 %D)
  ret i8* %call
}

-Chris

Re: operator new[] overflow (PR 19351)

[Chris Lattner]

On Dec 4, 2010, at 5:22 AM, Florian Weimer wrote:

 * Joe Buck:
 
 It's wasted code if the multiply instruction detects the overflow.
 It's true that the cost is small (maybe just one extra instruction
 and the same number of tests, maybe one more on architectures where you
 have to load a large constant), but it is slightly worse code than what
 Chris Lattner showed.
 
 It's possible to improve slightly on the LLVM code by using the
 overflow flag (at least on i386/amd64), as explained in this blog
 post:
 
 http://blogs.msdn.com/b/michael_howard/archive/2005/12/06/500629.aspx

Ah, great point.  I improved the clang codegen to this:

$ cat t.cc 
void *test(long count) {
  return new int[count];
}
$ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm -show-mc-encoding
.section__TEXT,__text,regular,pure_instructions
.globl  __Z4testl
.align  4, 0x90
__Z4testl:  ## @_Z4testl
## BB#0:## %entry
movl$4, %ecx## encoding: [0xb9,0x04,0x00,0x00,0x00]
movq%rdi, %rax  ## encoding: [0x48,0x89,0xf8]
mulq%rcx## encoding: [0x48,0xf7,0xe1]
movq$-1, %rdi   ## encoding: 
[0x48,0xc7,0xc7,0xff,0xff,0xff,0xff]
cmovnoq %rax, %rdi  ## encoding: [0x48,0x0f,0x41,0xf8]
jmp __Znam  ## TAILCALL
## encoding: [0xeb,A]
##   fixup A - offset: 1, value: 
__Znam-1, kind: FK_PCRel_1
.subsections_via_symbols

This could be further improved by inverting the cmov condition to avoid the 
first movq, which we'll tackle as a general regalloc improvement.

Thanks for the pointer!

-Chris

Re: operator new[] overflow (PR 19351)

[Chris Lattner]

On Nov 30, 2010, at 3:12 PM, Joe Buck wrote:

 On Tue, Nov 30, 2010 at 01:49:23PM -0800, Gabriel Dos Reis wrote:
 The existing GCC behaviour is a bit more perverse than the
 C malloc() case as in
 
   new T[n]
 
 there is no multiplication that could be credited to careless programmer.
 The multiplication is introduced by GCC.
 
 ... which suggests strongly that GCC should fix it.  Too bad the ABI is
 frozen; if the internal ABI kept the two values (the size of the type, and
 the number of values) separate and passed two arguments to the allocation
 function, it would be easy to do the right thing (through bad_alloc if the
 multiplication overflows).

You don't need any ABI changes to support this.  For example, clang compiles:

int *foo(long X) {
  return new int[X];
}

into:

__Z3fool:   ## @_Z3fool
Leh_func_begin0:
## BB#0:## %entry
movl$4, %ecx
movq%rdi, %rax
mulq%rcx
testq   %rdx, %rdx
movq$-1, %rdi
cmoveq  %rax, %rdi
jmp __Znam

On overflow it just forces the size passed in to operator new to -1ULL, which 
throws bad_alloc.

-Chris

Re: Idea - big and little endian data areas using named address spaces

[Chris Lattner]

On Nov 10, 2010, at 4:00 AM, David Brown wrote:

 Would it be possible to use the named address space syntax to implement 
 reverse-endian data?  Conversion between little-endian and big-endian data 
 structures is something that turns up regularly in embedded systems, where 
 you might well be using two different architectures with different 
 endianness.  Some compilers offer direct support for endian swapping, but gcc 
 has no neat solution.  You can use the __builtin_bswap32 (but no 
 __builtin_bswap16?) function in recent versions of gcc, but you still need to 
 handle the swapping explicitly.
 
 Named address spaces would give a very neat syntax for using such 
 byte-swapped areas.  Ideally you'd be able to write something like:
 
 __swapendian stuct { int a; short b; } data;
 
 and every access to data.a and data.b would be endian-swapped.  You could 
 also have __bigendian and __litteendian defined to __swapendian or blank 
 depending on the native ordering of the target.
 
 
 I've started reading a little about how named address spaces work, but I 
 don't know enough to see whether this is feasible or not.
 
 
 Another addition in a similar vein would be __nonaligned, for targets which 
 cannot directly access non-aligned data.  The loads and stores would be done 
 byte-wise for slower but correct functionality.

Why not just handle this in the frontend during gimplification?

-Chris

LLVM 2.8 Release

[Chris Lattner]

Hi All,

For anyone interested, the LLVM project just released LLVM 2.8.  Among other 
things it includes major updates to the DragonEgg GCC plugin.  Other major 
improvements include a new debugger (LLDB), a new C++ standard library 
(libc++), and Clang C++ support being feature complete and very usable.  If 
you're interested in LLVM, please follow up on the llvmdev mailing list.

-Chris

2.8 Announcement:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2010-October/36.html

2.8 Release Notes:
http://llvm.org/releases/2.8/docs/ReleaseNotes.html

LLDB:   http://lldb.llvm.org/
libc++: http://libcxx.llvm.org/

llvmdev Mailing List:
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

On Sep 15, 2010, at 12:23 AM, Kevin André wrote:

 On Tue, Sep 14, 2010 at 17:55, Chris Lattner clatt...@apple.com wrote:
 
 On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote:
 
 On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor i...@google.com wrote:
 From the perspective of gcc, I think the goal of clang-gcc would be to
 replace the current frontends entirely.
 
 Yes, I think it would be interesting to consider how Clang could
 evolve into a portable C/C++(/ObjC/ObjC++) front-end that could be
 used by LLVM and GCC (and other FOSS compilers) -- an alternative to
 the EDG front-end.
 
 For what it is worth, this is something that the clang folk would certainly 
 like to see happen.  Clang is also already factored such that you don't need 
 to pull in LLVM IR (and thus the llvm backend and code generator) if you 
 don't want to.  Just convert from clang ASTs to generic or gimple.
 
 Doesn't clang depend on LLVM libraries like LLVMSystem and LLVMSupport?

Yes, but those are very small libraries that don't pull in the llvm backend, 
code generator or llvm IR either.

-Chris

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote:

 On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor i...@google.com wrote:
 Manuel López-Ibáñez lopeziba...@gmail.com writes:
 
 In the same sense that adding clang-gcc means that there is less
 motivation for developers to improve the current C/C++ FEs.
 
 From the perspective of gcc, I think the goal of clang-gcc would be to
 replace the current frontends entirely.
 
 Yes, I think it would be interesting to consider how Clang could
 evolve into a portable C/C++(/ObjC/ObjC++) front-end that could be
 used by LLVM and GCC (and other FOSS compilers) -- an alternative to
 the EDG front-end.

For what it is worth, this is something that the clang folk would certainly 
like to see happen.  Clang is also already factored such that you don't need to 
pull in LLVM IR (and thus the llvm backend and code generator) if you don't 
want to.  Just convert from clang ASTs to generic or gimple.

-Chris

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

On Sep 10, 2010, at 11:06 AM, Richard Kenner wrote:

 I thought the point is that Apple WON'T go to GPLv3.
 
 The Apple distributions are GPLv2 or later, meaning if someone wanted to 
 take that code and distribute it under then GPLv3, they could.
 
 The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL.
 FSF wants GPLv3 or later and it's not at all clear to me that we could
 change the license of code that's not copyright assigned to FSF to that
 license (we can for code that HAS been assigned).

The code in the apple branch on the fsf server *is* copyright assigned to the 
FSF.

-Chris

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

On Sep 9, 2010, at 3:11 AM, Nicola Pero wrote:

 Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to 
 GCC into FSF GCC trunk ?
 Any legal obstacles ?
 
 If we start producing patches to the current FSF GCC trunk that merge these 
 modifications, would they be accepted ?
 
 I think Apple would benefit from merging of their modifications in that we'd 
 merge the Apple/NeXT runtime support as well. :-)
 They don't have to do any work.

Be aware that none of the changes that haven't been committed to the FSF trees 
are copyright-assigned to the FSF.  In practice, since the FSF cares about 
copyright assignment, this probably means that you can probably merge whatever 
is in the apple branch on the FSF server, but you can't take things out of 
llvm-gcc or the apple gcc tarballs that get pushed out on opendarwin.

I'm not a lawyer, so this isn't legal advice, just my understanding of FSF 
policies and the mechanics of how the copyright transfer works.

-Chris

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

On Sep 9, 2010, at 12:27 PM, Dave Korn wrote:

  *Until and unless* Apple itself submits the code to the FSF, Apple retains
 the copyright; which means that nobody else has the right to submit it to the
 FSF.  (Unless Apple gives /them/ (the hypothetical third party) an assignment
 that allows them to sub-assign but that sounds even more complicated to 
 me.)

Right, that's why it is reasonable (to me) to assume that stuff in the apple 
branch on the fsf servers are fair game.

-Chris

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

On Sep 9, 2010, at 12:19 PM, Jack Howarth wrote:
   Perhaps a rational approach would be to contact whoever at Apple currently 
 is
 charged with maintaining their objc languages about the issue.

Apple does not have an internal process to assign code to the FSF anymore.  I 
would focus on the code that is already assigned to the FSF.

-Chris

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

On Sep 9, 2010, at 11:55 AM, Nicola Pero wrote:
 Why don't you upload one of the recent Apple GCC tarballs in a branch on the 
 FSF server ? 
 ...
 You don't have to do it, but contributing changes back to the original 
 project seems to be the right, honourable thing to do,  particularly when it 
 doesn't cost anything.

Hi Nicola,

I don't have the authority to do this, it is not my copyright to assign.

-Chris

Re: Edit-and-continue

[Chris Lattner]

On Jul 19, 2010, at 1:57 PM, Tom Tromey wrote:

 Dave   But yes, OP, it's a long-term project.
 
 Apple implemented fix-and-continue in their toolchain.  They spoke about
 it a little bit on the gdb list, it is in the archives.  My take-away
 was that the feature is a lot of work for not much benefit, but YMMV,
 and of course we'd be happy to review any gdb patches in this direction
 :-)

The use case for fix-and-continue is for long lived apps.  This has little to 
do with actual build times, it is useful when restarting the app and getting it 
back into the state to repro the problem takes a long time.

It is a useful feature and Apple did implement it in their toolchain, but it's 
worth noting that they've ripped it out since then.  Their specific 
implementation was too fragile to work consistently.

-Chris

Re: Scheduling x86 dispatch windows

[Chris Lattner]

On Jun 13, 2010, at 7:35 AM, Joern Rennecke wrote:
 An even if you have a suitable text for the assembler, to link the compiler
 with the assembler requires to merge to two complex build systems, and
 resolve symbol name clash issues.

Not trying to be inflammatory, but if you guys are really serious about doing 
this, you could consider using the LLVM integrated assembler.  It is built as a 
library and is easily separable from the code generator (codegen depends on the 
assembler, not the other way around).  It would be much much simpler to 
integrate than the binutils assembler.

Some information is here:
http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html

It currently supports darwin x86 quite well.  ELF/PECOFF and ARM support are in 
active development.  It sped up clang by ~10% at -O0 -g.

-Chris

LLVM 2.7 Released

[Chris Lattner]

Hi All,

For anyone interested, LLVM 2.7 was just released.  You can read the 
announcement here:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2010-April/34.html

and read much more detailed release notes here:
http://llvm.org/releases/2.7/docs/ReleaseNotes.html

In addition to a huge assortment of improvements and new features, this is the 
first release to officially include the DragonEgg GCC plugin.  See 
http://dragonegg.llvm.org/ for more details.

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 26, 2010, at 8:11 AM, Alfred M. Szmidt wrote:
   It's unclear whether the LLVM-style implicit copyright assignment
   is really enforceable, and this certainly isn't a forum to debate
   it.  In any case, it doesn't really matter, because the only reason
   copyright needs to be assigned (AFAIK) is to change the license.
 
 This is not the only reason (and in the GNU projects case, not a
 reason at all), the main reason is to be able to enforce the copyright
 of the work without having to call in everyone into court.  If only
 parts of GCC where copyrighted by the FSF, then the FSF could only sue
 only for those parts.

Someone else pointed this out elsewhere in the thread, so perhaps it is worth 
responding.  Being able to enforce copyright is specifically useful if your 
code is under a GPL-style license.  For code under a bsd-style do whatever you 
want, but don't sue us style license, this is much less important.  That is 
why I claimed that the license change aspect is most important: for me 
personally, enforcing copyright is not a particular exciting prospect.

w.r.t. hoarding, I'll point out that (in the context of GCC) being able to 
enforce copyright is pretty useless IMO.  While you can force someone to 
release their code, the GPL doesn't force them to assign the copyright to the 
FSF.  In practice this means that you can force someone to release their GCC 
changes, but you can't merge them back to mainline GCC.  In a warped way you 
could argue that the FSF using the GPL encourages their software to fork :-)


On Apr 25, 2010, at 10:23 PM, Richard Kenner wrote:
 This would be on topic if the thread were Why not contribute? (to LLVM),
 but it isn't.  If you're really concerned about LLVM developers, that's one
 thing, but this is certainly not the place to discuss it.
 
 OK, then I'll rephrase it:
 
 If the GCC project were to change their policy so that there is no longer
 any document signed between the submitter of the code and the FSF,

To be perfectly clear, I'm not suggesting that the FSF or GCC project change 
their policies.  I'm just disputing some claims about LLVM system, and pointing 
out that LLVM and GCC's policies differ because there are substantially 
different goals involved.  The LLVM project is much more focused on the 
technology and the community, the GCC project is more focused on ensuring 
software freedom (as defined by the FSF).  There isn't anything wrong with 
having different goals.

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 26, 2010, at 12:23 PM, Ian Lance Taylor wrote:

 Chris Lattner clatt...@apple.com writes:
 
 w.r.t. hoarding, I'll point out that (in the context of GCC) being
 able to enforce copyright is pretty useless IMO.  While you can
 force someone to release their code, the GPL doesn't force them to
 assign the copyright to the FSF.  In practice this means that you
 can force someone to release their GCC changes, but you can't merge
 them back to mainline GCC.  In a warped way you could argue that the
 FSF using the GPL encourages their software to fork :-)
 
 Again, just for the record.  History shows that this is not entirely
 useless.  People at NeXT wrote the Objective C frontend to GCC.  They
 did not intend to release the source code.  The FSF objected.  In the
 end, NeXT wound up contributing the code, and that is why GCC has an
 Objective C frontend.  In other words, the whole process worked as the
 GPL intended.

This is a often repeated example, but you're leaving out the big part of the 
story (at least as far as I know).  The license *did not* force the ObjC 
frontend to be merged back into GCC, there were other factors at work.  This 
'victory' has nothing to do with the license, but it did cause them to release 
the code.

Beyond that, the changes to support Objective C 2.0 (and later) have never been 
merged back in, despite being published and widely available under the GPL.  
Also, the GNU runtime and the NeXT runtimes are wildly incompatible, and the 
ObjC frontend in GCC is one of the most disliked (I'll leave out the 
pejoratives :) because its design has not kept up with the other front-ends.

Even in the shining example of the GPL succeeding, are you sure it was a good 
thing in retrospect? :)  

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 26, 2010, at 1:53 PM, Ian Lance Taylor wrote:

 Beyond that, the changes to support Objective C 2.0 (and later) have
 never been merged back in, despite being published and widely
 available under the GPL.  Also, the GNU runtime and the NeXT
 runtimes are wildly incompatible, and the ObjC frontend in GCC is
 one of the most disliked (I'll leave out the pejoratives :) because
 its design has not kept up with the other front-ends.
 
 Even in the shining example of the GPL succeeding, are you sure it
 was a good thing in retrospect? :)
 
 That is due to a different set of other factors.  Objective C is not a
 shining example of the GPL succeeding.  But it is an example of a case
 where the GPL forced release of code *and* it was contributed to gcc,
 which is exactly the case that you were skeptical of.
 
 In other words: theory says one thing will happen (GPL encourages
 [FSF] software to fork); history shows that a different thing
 happened.  I'm a pragmatist; given a reasonable choice, I prefer
 history over theory.

Heh, ok, but if you're looking for history, look at both sides of it. 

deleted

I wrote a long and detailed email about GCC forks, long term corporate 
branches, the impact of the GPL on all this, etc.  However, it is so off topic, 
I'm happy to just delete it and drop the issue :-)

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote:

 On 25 April 2010 06:20, Chris Lattner clatt...@apple.com wrote:
 
 On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
 
 On 24 April 2010 00:18, Alfred M. Szmidt a...@gnu.org wrote:
 
 The disclaimers are legally necessary though, the FSF needs a paper
 trail in the case your employer comes back and claims that they have
 copyright over a change.
 
 BTW, in this aspect there is no difference between GCC and LLVM. The
 latter also requires to assign copyright to the University of
 Illinois. If you don't have a copyright disclaimer before contributing
 to LLVM, you are exposing yourself to some future legal troubles.
 
 On what do you base these assertions?  Every point seems wrong to me.
 
 Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html

The key distinction is that contributing to LLVM does not require you to sign a 
form (which isn't even publicly available) and mail it in to a busy and 
high-latency organization before non-trivial patches will be accepted.

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
 
 On what do you base these assertions?  Every point seems wrong to me.
 
 Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
 
 The key distinction is that contributing to LLVM does not require you to 
 sign a form (which isn't even publicly available) and mail it in to a busy 
 and high-latency organization before non-trivial patches will be accepted.
 
 So, is the copyright disclaimer implicit in the patch submission? Who
 defines the conditions?

That web page is everything that there is.  I am aware that this is not as 
legally air-tight as the FSF disclaimer, but empirically many companies seem to 
have no problem with it.

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 9:33 AM, Richard Kenner wrote:

 That web page is everything that there is.  I am aware that this is not as 
 legally air-tight as the FSF disclaimer, but empirically many companies
 seem to have no problem with it.
 
 There's nothing to have a problem WITH!  No assignment has taken place.
 The statement on the web has no legal significance whatsoever.  Unless
 the company SIGNS something, they still own the copyright on the code
 and can, at any time, decide they don't want it distributed.

It's unclear whether the LLVM-style implicit copyright assignment is really 
enforceable, and this certainly isn't a forum to debate it.  In any case, it 
doesn't really matter, because the only reason copyright needs to be assigned 
(AFAIK) is to change the license.  The LLVM project does not aim to be able to 
change the license in the future, all that is really important is that 
contributors agree to license their code under the llvm bsd license.

For at least some contributors, not being able to change the license is 
actually a major feature.  They aren't comfortable with assigning code to an 
organization which can then change the license of the code to something they 
don't agree with.  This is exactly what happened when code written and 
contributed under GPL2 got relicensed as GPL3 for example.  I'm not saying that 
this is right or wrong, but perceptions are held by people.

In any case the aims of the FSF are quite clear, and IMO it seems that the 
explicit copyright assignment is a real and necessary part of achieving those 
aims.  Different projects just have different goals.

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 2:30 PM, Richard Kenner wrote:
 The LLVM project does not aim to be able to change the license in the
 future, 
 
 Nobody aims to change something in the future, but nobody has a crystal
 ball either and it can often be hard to predict what might have to be done
 in the future.

We'll see.  Fortunately the future comes sooner than anyone expects.

 If there's no such document, then what does the project do if, unknown to
 them, some employee of a large company contributed code without the
 permission of his employer, the project distributes that code, and then the
 large software company sues for infringment?

This would be on topic if the thread were Why not contribute? (to LLVM), but 
it isn't.  If you're really concerned about LLVM developers, that's one thing, 
but this is certainly not the place to discuss it.

I find it amusing the willingness of various developers to debate the veracity 
of the LLVM policies, but the simulataneous (apparent) unwillingness to address 
GCC's (perceived) problems.  Why not spend your time helping improve the 
documentation, increase modularity, or improve the copyright assignment 
process, rather than participate so much in this thread?


On Apr 25, 2010, at 7:12 PM, Manuel López-Ibáñez wrote:
 Are you 100% sure that the fact that LLVM does not ask for your
 employer disclaimer means that you do not need to ask your employer
 for some paper to legally contribute code? Are you sure you are not
 exposing yourself to a legal risk?

This is such an incredibly immense scoop of FUD that I couldn't help but 
respond to it :-)  Isn't this thread supposed to be about finding ways to 
improve GCC?

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 23, 2010, at 5:05 PM, Basile Starynkevitch wrote:

 Manuel López-Ibáñez wrote:
 On 24 April 2010 00:18, Alfred M. Szmidt a...@gnu.org wrote:
 The disclaimers are legally necessary though, the FSF needs a paper
 trail in the case your employer comes back and claims that they have
 copyright over a change.
 BTW, in this aspect there is no difference between GCC and LLVM. The
 latter also requires to assign copyright to the University of
 Illinois. If you don't have a copyright disclaimer before contributing
 to LLVM, you are exposing yourself to some future legal troubles.
 
 The real issue is not the copyright disclaimer, it is the legal terms inside. 
 Maybe U.Illinois don't use words like unlumited liaibility.
 
 But we cannot know for sure, these documents are not public.

I'm not sure why you think that.  Unlike the FSF, all of the LLVM projects' 
requirements are public:
http://llvm.org/docs/DeveloperPolicy.html

LLVM does not require a copyright assignment.  People can send in random 
patches and they get immediately applied.

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:

 On 24 April 2010 00:18, Alfred M. Szmidt a...@gnu.org wrote:
 
 The disclaimers are legally necessary though, the FSF needs a paper
 trail in the case your employer comes back and claims that they have
 copyright over a change.
 
 BTW, in this aspect there is no difference between GCC and LLVM. The
 latter also requires to assign copyright to the University of
 Illinois. If you don't have a copyright disclaimer before contributing
 to LLVM, you are exposing yourself to some future legal troubles.

On what do you base these assertions?  Every point seems wrong to me.

-Chris

Re: Code assistance with GCC

[Chris Lattner]

On Apr 22, 2010, at 4:29 AM, Jakub Jelinek wrote:

 
 I did this because the other responses made it seem that it wasn't
 something that would be accepted back into GCC proper.  Maintaining an
 
 Can you point at any response that said it would not be accepted back into
 GCC proper?  There were no such comments AFAIK.  All that has been said
 is that it is not possible to implement it AS A PLUGIN,

Nope, you are correct.  Again, the cc was a mistake and I apologize for it.

 at least not currently
 and would probably require way too many hook points unless it wants to do
 only code completion after . and - (and not e.g. after :: and many other
 tokens).  For C++ tentative parsing is probably the biggest problem that
 needs solving.

I predict it won't be accepted into GCC mainline either, but we'll see. :)

-Chris

Re: Code assistance with GCC

[Chris Lattner]

On Apr 21, 2010, at 3:32 AM, Tomohiro Matsuyama wrote:

 Hi, all
 
 I have been working on implementing a tool-set of code assistance called 
 GCCSense, which enables code-completion for C/C++ in editors or a terminal.
 
 http://cx4a.org/software/gccsense/

This approach seems highly, uh, inspired from the exact same functionality in 
Clang.  Any reason not to contribute to that effort?

-Chris

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

[Chris Lattner]

On Apr 21, 2010, at 9:53 AM, Vladimir Makarov wrote:

 Only SPECIn2000 for x86_64 has been compiled fully successfully by
 dragonegg.  There were a few compiler crashes including some in LLVM
 itself for SPECFP2000 and for SPECINT2000 for x86.
 
 So here is SPECInt2000 for x86_64 comparison:
 
 dragonegg: -O3 (with LLVM release build)
 gcc4.5: -O3 -flto (--enable-checking=release)
 
 Compilation Time  SPECINT2000
 Dragonegg 122.85user 2572
 gcc-4.5   283.49user 2841
 
 On integer benchmarks, dragonegg generates about 11% slower code.
 One interesting thing is that dragonegg is a really fast compiler.  It
 is 2.3 times faster than gcc.

This is definitely interesting, but you're also comparing apples and oranges 
here (for both compile time and performance).  Can you get numbers showing GCC 
-O3 and dragonegg with LTO to get a better comparison?

-Chris

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

[Chris Lattner]

On Apr 21, 2010, at 11:11 AM, Vladimir Makarov wrote:

 
 This is definitely interesting, but you're also comparing apples and oranges 
 here (for both compile time and performance). Can you get numbers showing 
 GCC -O3 and dragonegg with LTO to get a better comparison?
 
  
 Dragonegg does not work with -flto.  It generates assembler code on which gas 
 complaints (a lot of non-assembler code like target data-layout which are not 
 in comments).

Ok, I didn't know that didn't get wired up.  I'm not familiar with dragonegg, 
it might require gold with the llvm lto gold plugin or something.

 So I'll do gcc -O3 without -flto.  I don't think it will change average 
 SPECINT2000 rate significantly (although it can change separte benchmark 
 significantly)  but it will make gcc compiler much faster (may be 2 times 
 because I did not use -fwhole-program).  I'll post the results in an hour.

Sounds good, thanks!  I suspect the gcc build times will improve.

-Chris

Re: Code assistance with GCC

[Chris Lattner]

On Apr 21, 2010, at 1:51 PM, Manuel López-Ibáñez wrote:
 http://cx4a.org/software/gccsense/
 
 This approach seems highly, uh, inspired from the exact same
 functionality in Clang.  Any reason not to contribute to that
 effort?
 
 Surely trying to persuade people to contribute to some other project
 rather than gcc is off-topic here.  Even if not, it's pretty hostile.
 
 Would such a feature be accepted in GCC? Otherwise, this seems like a
 misunderstanding. Chris was not suggesting to contribute to Clang
 instead of GCC but instead to contribute to the Clang completion
 library rather than create your own 1-person project. Or at least this
 is how I understood it.

I actually meant to respond to him personally, I apologize for cc'ing the list.

I did this because the other responses made it seem that it wasn't something 
that would be accepted back into GCC proper.  Maintaining an invasive patch on 
the side for a long period of time didn't seem like a great idea.

-Chris

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Chris Lattner]

On Apr 11, 2010, at 5:54 AM, Dorit Nuzman wrote:
 
 * Get statistics on percentage of papers/projects that use compilers other
 than GCC, and ask them why...

Hi Dorit,

Here is a semi reasonably list of llvm-based publications: 
http://llvm.org/pubs/ which might be useful.

  (By the way, why was OpenCL implemented only on LLVM and not on GCC?)

There are many reasons, but one of the biggest is the GCC doesn't (practically 
speaking) support JIT compilation.  While it is possible to implement OpenCL on 
GCC, I suspect that the end result wouldn't be very compelling without some 
major architecture changes.

-Chris

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Chris Lattner]

On Apr 11, 2010, at 12:05 PM, Grigori Fursin wrote:
 By the way, I remember that when we had first discussions to include plugin 
 framework to GCC some
 years ago, 
 first feedback was extremely negative. Nevertheless, GCC 4.5 will feature 
 plugin framework (that
 will 
 also be very useful for research), so maybe GCC will support JIT compilation 
 too one day ;) ...

Sure, I'm not saying that GCC won't make amazing infrastructure improvements, 
just explaining why opencl implementors didn't want to block on waiting for it 
to happen.

 As for OpenCL and lack of JIT support in GCC, we have been effectively 
 overcoming this problem 
 for many years using static multi-versioning and run-time version selection 
 based on program
 and system behavior (even though there are obvious limitations), 
 so I guess we can temporally continue using similar techniques for OpenCL in 
 GCC...

I don't think that this is sufficient to implement OpenCL-the-spec well.  You 
can definitely add support for opencl-the-kernel-language, but that's only half 
of OpenCL: the runtime, GPU integration, and OpenGL integration aspects are 
just as important.  You can definitely implement all this by forking out to an 
assembler etc, the implementation will just not be great.

-Chris

Re: RFC: c++ diagnostics

[Chris Lattner]

On Apr 5, 2010, at 8:20 AM, Benjamin Kosnik wrote:

 
 Hello all! 
 
 I've put up a short diagnostics comparison between gcc, icc, and
 clang. It is my plan to update this with major revisions to individual
 compilers. 
 
 Included are most of the outstanding bugzilla requests with the
 diagnostic keyword. However, I am looking for help! Please send me
 code samples that frustrate, obfuscate, and annoy. 
 
 In particular, I am looking for template instantiation issues such as
 c++/41884, but hopefully something in a deliciously small snippet. No
 doubt other C++ hackers have particular annoyances.
 

Hi Benjamin,

I wrote a little blog post that shows off some of the things that Clang can do. 
 It would be great to improve some of GCC/G++'s diagnostics in a similar way:

http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

-Chris

Re: RFC: c++ diagnostics

[Chris Lattner]

On Apr 6, 2010, at 9:29 AM, Manuel López-Ibáñez wrote:
 Hi Benjamin,
 
 I wrote a little blog post that shows off some of the things that Clang can 
 do.  It would be great to improve some of GCC/G++'s diagnostics in a similar 
 way:
 
 http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
 
 Unfortunately, you mix C and C++ examples. I know it is because clang
 parses both with the same parser but this thread is only discussing
 improving C++ diagnostics in GCC, and there is no plan or project for
 C diagnostics. As it happens, some C++ diagnostics are better than the
 same diagnostic for C and viceversa.

I think all the C examples are also valid C++ code, they should apply equally 
well, but I admit that I didn't try those on g++ to see how it does.  I figured 
it also didn't matter much because there has surely been significant progress 
since gcc 4.2.

-Chris

Re: RFC: c++ diagnostics

[Chris Lattner]

On Apr 5, 2010, at 8:20 AM, Benjamin Kosnik wrote:

 
 Hello all! 
 
 I've put up a short diagnostics comparison between gcc, icc, and
 clang. It is my plan to update this with major revisions to individual
 compilers. 
 
 Included are most of the outstanding bugzilla requests with the
 diagnostic keyword. However, I am looking for help! Please send me
 code samples that frustrate, obfuscate, and annoy. 
 
 In particular, I am looking for template instantiation issues such as
 c++/41884, but hopefully something in a deliciously small snippet. No
 doubt other C++ hackers have particular annoyances.
 
 I'm also looking for guidance on how to rank the priority of these
 issues. Is there some way to tell what the biggest annoyance is?
 
 http://people.redhat.com/bkoz/diagnostics/diagnostics.html

This is a great resource Benjamin, thanks for putting it together!

Some random thoughts if you ever regenerate this:

1) the caret diagnostics would be easier to understand in the output if 
formatted with a pre or tt tag.  

2) The clang invocations don't need -fcaret-diagnostics -fshow-source-location 
-fdiagnostics-fixit-info because they are the default.

3) It's best to not pass -fdiagnostics-print-source-range-info unless you're 
looking for machine interpretable output.  This flag adds things like 
{3:29-3:32} which are useful to a machine, but otherwise just clutter the 
output up.

4) It looks like ICC defaults to a number of coding standards types of checks, 
e.g. access control not specified.  I don't know if it is possible to turn 
those off, but they seem to just be noise for the purposes of this comparison.

5) There are a couple cases of GCC rejecting valid code (e.g. 19377), or which 
there may be some debate about (19538) it might be worth pointing this out. 
*shrug*

6) My understanding was that GCC's complex extension in C++ mode is supposed to 
work like C99 _Complex. If so, 41895 looks like a GCC bug.  I don't know if 
C++'0x affects this though.

7) There are some clang bugs here.  Access control is not yet enabled by 
default (affects 20397, 39728), and a variety of other bugs (affects 14283, 
38612).  I file Clang PR#6782/6783 to track these.

Thanks again for putting this together,

-Chris

Re: RFC: c++ diagnostics

[Chris Lattner]

On Apr 5, 2010, at 12:51 PM, Benjamin Kosnik wrote:

 
 5) There are a couple cases of GCC rejecting valid code (e.g. 19377),
 or which there may be some debate about (19538) it might be worth
 pointing this out. *shrug*
 
 One of the goals was to measure the output when the input is
 truncated, or obviously flawed (no semicolons is very
 common!). Certainly if you can think of other (obvious) issues where
 refactoring or haste make general classes of errors I'm very interested
 in this particular type of pathology.

Absolutely, this is one of the reasons I'm particularly interested in common 
errors like missing semi colons, . vs -, use of things like ::foo, 
explaining overload set failures, etc.

 The valid code issues I can flag in the existing bug reports.

Ok, thanks again.

-Chris

Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc

[Chris Lattner]

On Mar 19, 2010, at 5:33 AM, b95705...@ntu.edu.tw wrote:

 Hello Tristan,
 
 I think the main issue is that EFI C dialect is not ANSI-C compliant: the 
 size of pointer is determined
 at the run-time and therefore the layout of the structure is not static.  
 Gcc doesn't support this model.
 
 As I read some related information, LLVM IR doesn't care the size of pointer
 and the front end of LLVM is derived from GCC.I am wondering to know should
 I do some work at this aspect??

FYI, the LLVM Clang front-end provides a C/ObjC and (real soon now) C++ 
compiler that is GCC-free.  Further questions should definitely go to the llvm 
or clang lists.  More information is at http://clang.llvm.org/

-Chris

Re: detailed comparison of generated code size for GCC and other compilers

[Chris Lattner]

On Dec 15, 2009, at 12:28 AM, Paolo Bonzini wrote:

 On 12/14/2009 09:31 PM, John Regehr wrote:
 Ok, thanks for the feedback Andi.  Incidentally, the LLVM folks seem to
 agree with both of your suggestions. I'll re-run everything w/o frame
 pointers and ignoring testcases where some compiler warns about use of
 uninitialized local. I hate the way these warnings are not totally
 reliable, but realistically if GCC catches most cases (which it almost
 certainly will) the ones that slip past won't be too much of a problem.
 
 I also wonder if you have something like LTO enabled.

No, he doesn't enable LLVM LTO.  Even if it did, LTO wouldn't touch the 
'CC1000SendReceiveP*' definitions because they are not static (unless he 
explicitly built with an export map).

I haven't analyzed what is going on in this example though.  The code is 
probably using some undefined behavior and getting zapped.

-Chris

  This function produces completely bogus code in LLVM, presumably because 
 some kind of LTO proves that CC1000SendReceiveP is never written.  Of course, 
 this assumption would be wrong at runtime in a real program.
 
 http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/015306.c
 
 Of course the answer is not to disable LTO, but rather to add an 
 initializer function that does
 
 volatile void *p;
 memcpy (CC1000SendReceiveP__f, p, sizeof (CC1000SendReceiveP__f));
 memcpy (CC1000SendReceiveP__count, p, sizeof (CC1000SendReceiveP__count));
 memcpy (CC1000SendReceiveP__rxBuf, p, sizeof (CC1000SendReceiveP__rxBuf));
 
 ... and to make all variables non-static (otherwise the initializer would 
 have to be in the same file, but that would perturb your results).
 
 I also agree with others that the frame pointer default is special enough to 
 warrant adding a special -f option to compilers that generate it, if some 
 other compilers do not generate it.
 
 Paolo
 

Re: gccgo: A gcc frontend for Go, a new programming language

[Chris Lattner]

On Nov 11, 2009, at 12:43 PM, Joe Buck wrote:



They weren't intended as a way of attaching complete new front ends
or complete new back ends.  That was the thing that RMS feared the  
most,
and he had at least some justification: would we have a C++ compiler  
or
an Objective-C compiler if the companies who employed the original  
authors
had the alternative of hooking into GCC without contributing their  
code?

There's some evidence that they would not have.


I thought it *was* a goal to allow attaching new (GPL3 compatible)  
backends?


-Chris

LLVM 2.6 Release

[Chris Lattner]

FYI, the LLVM project just pushed out its 2.6 release:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/33.html

There is a lot of goodness in this release, which spanned 6 months  
instead of the usual 3.  Of particular interest to the GCC community  
may be the 'DragonEgg' GCC plugin (http://dragonegg.llvm.org/), much  
better X86-64 code generation, and LTO support through the gold  
linker.  There is a high level description of some of the other  
features in the release announcement and more technical detail in the  
release notes: http://llvm.org/releases/2.6/docs/ReleaseNotes.html


Cheers,

-Chris

Re: apple blocks extension

[Chris Lattner]

On Sep 24, 2009, at 7:57 AM, Jason Merrill wrote:


On 09/15/2009 12:35 PM, Chris Lattner wrote:

The second major feature of Blocks vs c++ lambdas is that they can be
copied onto the heap. This allows things like Grand Central  
Dispatch

to work: you can write code that executes blocks asynchronously or on
other threads/work queues (after the function containing the block  
has

returned). A simple example is:

void print_on_different_thread(int X) {
 run_asynch(^{
   printf(Hi %d\n, X);
 });
}

With lambdas, the closure would be go out of scope when
print_on_different_thread returns, but blocks allows run_asynch to
extend the lifetime of the block.


The lambda equivalent would be

void print_on_different_thread(int X) {
 run_asynch([=]{
   printf(Hi %d\n, X);
 });
}

since X is captured by copy, run_asynch can do whatever it wants  
with the closure and not worry about the original X going away.


The only difference between blocks and lambdas here seems to be  
where you decide to copy the locals off the stack.


Can the lambda (containing X) be copied and put onto a queue?  What is  
its type?


-Chris

Re: apple blocks extension

[Chris Lattner]

On Sep 15, 2009, at 9:04 AM, Richard Henderson wrote:


On 09/15/2009 08:28 AM, Vincent R. wrote:
I just was curious to know if closures in apple gcc(called blocks  
from

what I read) is
also in mainline.
What is the status about this extension ?


It is unlikely that this will ever be brought into GCC, since
it appears to be largely identical to the C++0x Lambda feature.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf


There are major differences between lambdas and blocks, though they  
serve a superficially similar purpose.  If you are interested, there  
is a ton of discussion online.  Here are the two biggest differences:



The first difference is that every instance of a lambda gives you a  
value of a new (anonymous) type, which makes them mostly only useful  
with templates.  Blocks literals give values of a predictable type,  
which means that you can pass them around to non-templates.  This is  
also why they work in C.  Yes, I know that there are various adaptor  
classes that can be used with C++ lambdas to help work around this,  
but this is in inherent part of blocks.



The second major feature of Blocks vs c++ lambdas is that they can be  
copied onto the heap.  This allows things like Grand Central  
Dispatch to work: you can write code that executes blocks  
asynchronously or on other threads/work queues (after the function  
containing the block has returned).  A simple example is:


void print_on_different_thread(int X) {
  run_asynch(^{
  printf(Hi %d\n, X);
  });
}

With lambdas, the closure would be go out of scope when  
print_on_different_thread returns, but blocks allows run_asynch to  
extend the lifetime of the block.


Blocks and Lambdas have intentionally different syntax, allowing them  
to coexist peacefully in the same compiler / language.  They are also  
superficially similar to nested functions, but have other sets of  
benefits.  For example, blocks don't require executable stacks etc.


-Chris

Re: Incorporation of Objective-C 2.0 changes into GCC trunk

[Chris Lattner]

On Jul 22, 2009, at 2:58 AM, Paolo Bonzini wrote:

On 07/22/2009 10:57 AM, Richard Guenther wrote:
On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzinibonz...@gnu.org   
wrote:

Gregory Casamento wrote:
As far as I'm aware apple has an assignment for changes to gcc,  
so it

should be possible to pull them in.

You're not forced to assign changes that you do not want to assign.


I don't understand.  Yes you are forced to assign copyright to the  
FSF

for changes you contribute to FSF GCC.  You are of course not forced
to do this for your own forks of GCC.


Yeah, if Apple didn't send the code to FSF GCC, the fact that Apple  
has an assignment does not count.  They're not forced to assign  
changes that they do not want to assign -- as long as they keep the  
changes local, which they did for Objective C 2.0.  The only way to  
know, would be to ask someone at Apple.


If someone is seriously interested in merging pieces of the Apple GCC  
tree into the main FSF tree, and if there is a process in place to  
make the assignment happy, I would be happy to try to make it happen.


The major caveats are that the Apple GCC tree isn't in great shape (it  
will take some work to make the objc2 changes submission quality  
because they may break the gnu runtime, be overly darwin specific,  
etc), Apple engineers will not be able to help with this work, and it  
may take some time to get the approval to assign copyright of the code.


What is the process for getting a blob of code assigned to the FSF  
that is not just being committed into the tree?


-Chris 

Re: LLVM as a gcc plugin?

[Chris Lattner]

On Jun 5, 2009, at 3:43 AM, Steven Bosscher wrote:

On Fri, Jun 5, 2009 at 12:40 PM, Andrew  Nisbeta.nis...@mmu.ac.uk  
wrote:

Hello,
I am interested in developing LLVM functionality to support the  
interfaces in GCC ICI.


*sigh*

GCC != LLVM.  And this is a GCC list. Can LLVM topics please be
discussed on an LLVM mailing list?


How is LLVM any different than another external imported library (like  
GMP or MPFR) in this context?


-Chris

Re: LLVM as a gcc plugin?

[Chris Lattner]

On Jun 3, 2009, at 11:30 PM, Uros Bizjak wrote:


Hello!

Some time ago, there was a discussion about integrating LLVM and GCC
[1]. However, with plugin infrastructure in place, could LLVM be
plugged into GCC as an additional optimization plugin?

[1] http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html


Hi Uros,

I'd love to see this, but I can't contribute to it directly.  I think  
the plugin interfaces would need small extensions, but there are no  
specific technical issues preventing it from happening.  LLVM has  
certainly progressed a lot since that (really old) email went out :)


-Chris

Re: LLVM as a gcc plugin?

[Chris Lattner]

On Jun 3, 2009, at 11:59 PM, Miles Bader wrote:


Chris Lattner clatt...@apple.com writes:

Some time ago, there was a discussion about integrating LLVM and GCC
[1]. However, with plugin infrastructure in place, could LLVM be
plugged into GCC as an additional optimization plugin?


I'd love to see this, but I can't contribute to it directly.  I think
the plugin interfaces would need small extensions, but there are no
specific technical issues preventing it from happening.  LLVM has
certainly progressed a lot since that (really old) email went out :)


Is there a description somewhere of areas where llvm is thought to do
well compared to gcc, and maybe future plans for improvement?

In the (limited) tests I've done, gcc [4.4, but 4.2 yields similar
results] seems to do a lot better than llvm [2.5], but those were C++
code and I wonder if llvm is currently concentrating on C?


LLVM has many capabilities and advantages that GCC doesn't (and is  
also missing some features and capabilities that GCC has), but it is  
also common to misconfigure it so that it isn't optimizing like it  
should.  It is pretty off topic for this list though, please ask on  
the llvmdev mailing list for more information.  Please send  
information about how you built llvm and what your machine  
configuration is,


Thanks,

-Chris

Re: LLVM as a gcc plugin?

[Chris Lattner]

On Jun 4, 2009, at 3:20 AM, Steven Bosscher wrote:

On Thu, Jun 4, 2009 at 12:14 PM, Rafael Espindola espind...@google.com 
 wrote:
I'd love to see this, but I can't contribute to it directly.  I  
think the
plugin interfaces would need small extensions, but there are no  
specific

technical issues preventing it from happening.  LLVM has certainly
progressed a lot since that (really old) email went out :)


I can help a bit.



Aren't LLVM and GCC doing just fine as
competing compilers?


I'm not sure what you mean, LLVM and GCC are two completely different  
things.  LLVM is an infrastructure for building compilers, GCC is an  
instance of a compiler.  Combining LLVM with GCC gives LLVM-GCC  
(another instance of a compiler), which adds new capabilities to GCC  
that many users find useful.  These include things such as cross- 
language LTO support (for C, c++, fortran, etc), JIT compilation,  
better performance in some scenarios, etc.



Excuse me if this is a stupid question, but eh -- why would you want
to make an LLVM plugin?


There are multiple answers to this question.  The most obvious one is  
that the current version of llvm-gcc is stuck on GCC 4.2, and 4.2  
lacks a number of improvements the fortran and ada front-ends and  
runtimes.  It would be straight-forward to forward port the patches to  
gcc mainline, but presumably implementing llvm-gcc in terms of plugins  
would result in something that has easier maintenance (this remains to  
be seen of course).


-Chris

Re: New GCC releases comparison and comparison of GCC4.4 and LLVM2.5 on SPEC2000

[Chris Lattner]

On May 13, 2009, at 5:26 AM, Duncan Sands wrote:


Hi Richard,

-mpc64 sets the x87 floating point control register to not use the  
80bit

extended precision.  This causes some x87 floating point operations
to operate faster and there are no issues with the extra roundings  
you
get when storing an 80bit precision register to a 64bit memory  
location.


However, this does break long double, right?


Does LLVM support x87 arithmetic at all or does it default to SSE
arithmetic in 32bits?  I guess using SSE math for both would be a  
more

fair comparison?


LLVM does support the x86 floating point stack, though it doesn't  
support
all asm expressions for it (which is why llvm-gcc disables math  
inlines).
My understanding is that no effort has been made to produce optimal  
code

when using the x86 fp stack, and all the effort when into SSE instead.


As long as you configure llvm-gcc with --with-arch=pentium-4 or later,  
you should be fine.  I personally use --with-arch=nocona.


-Chris

Re: New GCC releases comparison and comparison of GCC4.4 and LLVM2.5 on SPEC2000

[Chris Lattner]

On May 12, 2009, at 6:56 AM, Vladimir Makarov wrote:

A few people asked me to do a new comparison of GCC releases and  
LLVM as the new GCC release and LLVM were out recently.


You can find the comparison on http://vmakarov.fedorapeople.org/spec/

The comparison for x86 (32-bit mode) was done on Pentium4 and  for  
x86_64 (64-bit mode) on Core I7.


Some changes in the performance were big since GCC 3.2 and it is  
sometimes hard to see small changes on the posted graphs.
Therefore I put original tables used to generate the graphs.


Looking at the llvm 2.5 vs gcc 4.4 comparison is very interesting,  
thank you for putting this together Vladimir!  I find these numbers  
particularly interesting because you're comparing simple options like - 
O2 and -O3 instead of the crazy spec tuning mix :).  This is much more  
likely to be representative of what real users will get on their apps.


Some random thoughts:

1. I have a hard time understanding the code size numbers.  Does 10%  
mean that GCC is generating 10% bigger or 10% smaller code than llvm?


2. You change two variables in your configurations: micro architecture  
and pointer size.  Would you be willing to run x86-32 Core i7 numbers  
as well?  LLVM in particular is completely untuned for the (really old  
and quirky) netburst architecture, but I'm interested to see how it  
runs for you on more modern Core i7 or Core2 processors in 32-bit mode.


3. Your SPEC FP benchmarks tell me two things: GCC 4.4's fortran  
support is dramatically better than 4.2's (which llvm 2.5 uses), and  
your art/mgrid hacks apparently do great stuff :).


4. Your SPEC INT numbers are more interesting to me.  It looks like  
you guys have some significant wins in 175.vpr, 197.crafty, and other  
benchmarks.  At some point, I'll have to see what you guys are doing :)


Thanks for the info, great stuff!

-Chris

Re: New GCC releases comparison and comparison of GCC4.4 and LLVM2.5 on SPEC2000

[Chris Lattner]

On May 12, 2009, at 11:05 AM, Vladimir Makarov wrote:

Chris Lattner wrote:

On May 12, 2009, at 6:56 AM, Vladimir Makarov wrote:

A few people asked me to do a new comparison of GCC releases and  
LLVM as the new GCC release and LLVM were out recently.


You can find the comparison on http://vmakarov.fedorapeople.org/ 
spec/


The comparison for x86 (32-bit mode) was done on Pentium4 and  for  
x86_64 (64-bit mode) on Core I7.


Some changes in the performance were big since GCC 3.2 and it is  
sometimes hard to see small changes on the posted graphs.
Therefore I put original tables used to generate the graphs.


Looking at the llvm 2.5 vs gcc 4.4 comparison is very interesting,  
thank you for putting this together Vladimir!  I find these numbers  
particularly interesting because you're comparing simple options  
like -O2 and -O3 instead of the crazy spec tuning mix :).  This is  
much more likely to be representative of what real users will get  
on their apps.


Some random thoughts:

1. I have a hard time understanding the code size numbers.  Does  
10% mean that GCC is generating 10% bigger or 10% smaller code than  
llvm?


The change is reported relative to LLVM.  So 10% means that GCC  
generates 10% bigger code than LLVM and -10% means that GCC  
generates 10% less code.


Ok!  It is interesting that GCC seems to generate consistently larger  
code at both -O2 and -O3 in x86-64 mode (over 20% larger in -O3).   
Perhaps that also is impacting the compile time numbers as well.


2. You change two variables in your configurations: micro  
architecture and pointer size.  Would you be willing to run x86-32  
Core i7 numbers as well?  LLVM in particular is completely untuned  
for the (really old and quirky) netburst architecture, but I'm  
interested to see how it runs for you on more modern Core i7 or  
Core2 processors in 32-bit mode.


I used the same processor (P4) and options for x86 as for the GCC  
release comparison.  I did not know that LLVM is badly tuned for P4,  
sorry.  I could do the same comparison for x86 on Core i7 without  
specific tuning (there is no tuning for i7 yet) but it takes a lot  
of time.  May be it will be ready on next week.


No problem at all, I appreciate you running the numbers!

It would also be very interesting to include LLVM's LTO support, which  
gives a pretty dramatic win on SPEC.  However, I don't know how  
difficult it is to use on linux (on the mac, you just pass -O4 at  
compile time, and everything works).  I've heard that Gold has a new  
plugin to make LTO transparent on linux as well, but I have no  
experience with it, and it is probably more trouble than you want to  
take.  Does gcc 4.4 include the LTO branch yet?


-Chris



3. Your SPEC FP benchmarks tell me two things: GCC 4.4's fortran  
support is dramatically better than 4.2's (which llvm 2.5 uses),  
and your art/mgrid hacks apparently do great stuff :).


4. Your SPEC INT numbers are more interesting to me.  It looks like  
you guys have some significant wins in 175.vpr, 197.crafty, and  
other benchmarks.  At some point, I'll have to see what you guys  
are doing :)


Thanks for the info, great stuff!

-Chris

Re: format argument does not have string type

[Chris Lattner]

On Apr 29, 2009, at 9:58 PM, Jack Howarth wrote:


  Does anyone understand why Apple's gcc-4.2 compiler in
Xcode 3.1.2 accepts the following code...

typedef const struct __CFString * CFStringRef;
typedef struct __CFBundle *CFBundleRef;

extern
CFStringRef CFBundleCopyLocalizedString(CFBundleRef bundle,  
CFStringRef key, CFStringRef value, CFStringRef tableName)  
__attribute__((format_arg(2)));


and FSF gcc 4.3 and 4.4 produces the error message...

gcc-4 testcase.c -F. -S -o test.s
testcase.c:5: error: format string argument not a string type

...instead? Is this a language violation that Apple ignores or
do they have more capabilities in their attributes than FSF gcc?
Thanks in advance for any clarification on whether this merits
an enhancement request for gcc 4.5.


Apple GCC understands Core Foundation strings, which is what  
__CFString is.  I don't know all the details, but the code is open  
source through open darwin.


-Chris

Re: Diagnostic Messaging Suggestion

[Chris Lattner]

On Apr 16, 2009, at 8:44 PM, Joe Buck wrote:


On Thu, Apr 16, 2009 at 03:40:47PM -0700, Arthur Schwarz wrote:

The rock has dropped. The answer is quoted below:

My best guess is that a header file is included twice, and lacks  
guards, hence the message is correct: the function is being defined  
twice, from the same source location.


Yes, I've had to diagnose this one before; it doesn't happen with my
own code because I use include guards, but I've had to help others.

It would be cool if there were a way of distinguishing the case where
the same header is being processed twice.

We might see

foo.h:11 error: redefinition of `a'
foo.h:11 error: `a' previously defined here

but the first foo.h:11 might represent the 2300'th line read by the
compiler, while the second foo.h:11 might represent the 2194'th  
line.

If, for definitions, the compiler keeps track of this detail, it
would be possible to reliably print

foo.h:11 error: redefinition of `a' (file was included more than once)


Clang just prints the include stack information when anything in the  
include stack differs between two consecutive diagnostics.


$ cat t.h
int x = 4;
$ cat t.c

#include t.h
#include t.h
$ clang t.c
In file included from t.c:3:
./t.h:1:5: error: redefinition of 'x'
int x = 4;
^
In file included from t.c:2:
./t.h:1:5: note: previous definition is here
int x = 4;
^

This clearly says that the first definition was coming from t.c:2 and  
the second from t.c:3.  Of course, if you get multiple diagnostics  
from the same header, you only show the include stack for the first.


-Chris

Re: GCC RES: Restrictive Exception Specification: 0.1 - Alpha. Feedback Request.

[Chris Lattner]

On Apr 10, 2009, at 1:55 PM, Jason Merrill wrote:
My impression is that the C++ committee generally feel that  
exception specifications are a failed feature, and nobody is  
particularly interested in fixing them.


Hi Jason,

Have you seen this?
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html

-Chris

Re: GCC + libJIT instead of LLVM

[Chris Lattner]

On Apr 1, 2009, at 5:09 AM, Dave Korn wrote:

It seems to
me that LLVM solves many goals that are already complete and solved  
in
GCC. So I think libJIT potentially is more useful for GCC and  
software

developers.


but you don't say what libjit would be more useful than, or how this  
overlap
between solved goals between gcc and llvm implies that.  Do you  
simply mean
that, because llvm and gcc both cover similar areas, and because  
libjit is
useful for llvm, it must also be useful for gcc?  Could you list  
some of these

goals and explain how they relate to JIT?


Hi Dave,

I don't mean to invade into a pretty amusing thread, but I wanted to  
clarify one important thing: litjit and LLVM have nothing to do with  
each other.


libjit and LLVM have very different design points.  libjit is a bit  
more than a glorified macro assembler with some late optimizations,  
whereas LLVM is a real compiler that happens to have the ability to  
emit machine code to memory.


To be perfectly clear, LLVM does not use libjit.

-Chris

Re: GCC 4.4.0 Status Report (2009-03-13)

[Chris Lattner]

On Mar 23, 2009, at 8:02 PM, Jeff Law wrote:


Chris Lattner wrote:


These companies really don't care about FOSS in the same way GCC  
developers do.   I'd be highly confident that this would still be  
a serious issue for the majority of the companies I've interacted  
with through the years.


Hi Jeff,

Can you please explain the differences you see between how GCC  
developers and other people think about FOSS?  I'm curious about  
your perception here, and what basis it is grounded on.


I'd divide customers into two broad camps.  Both camps are extremely  
pragmatic, but they're focused on two totally different goals.


Thanks Jeff, I completely agree with you.  Those camps are very common  
in my experience as well.  Do you consider GCC developers to fall into  
one of these two categories, or do you see them as having a third  
perspective?  I know that many people have their own motivations and  
personal agenda (and it is hard to generalize) but I'm curious what  
you meant above.


Thanks!

-Chris




The first camp sees FOSS toolkits as a means to help them sell more  
widgets, typically processors  embedded development kits.  Their  
belief is that a FOSS toolkit helps build a developer eco-system  
around their widget, which in turn spurs development of consumable  
devices which drive processor  embedded kit sales.   The key for  
these guys is free, as in beer, widely available tools.  The fact  
that the compiler  assorted utilities are open-source is largely  
irrelevant.


The second broad camp I run into regularly are software developers  
themselves building applications, most often for internal use, but  
occasionally they're building software that is then licensed to  
their customers.  They'd probably describe the compiler  associated  
utilities as a set of hammers, screwdrivers and the like -- they're  
just as happy using GCC as any other compiler so long as it works.   
The fact that the GNU tools are open source is completely irrelevant  
to these guys.  They want to see standards compliance, abi  
interoperability, and interoperability with other tools (such as  
debuggers, profilers, guis, etc).  They're more than willing to swap  
out one set of tools for another if it gives them some advantage.   
Note that an advantage isn't necessarily compile-time or runtime  
performance -- it might be ease of use, which they believe allows  
their junior level engineers to be more effective (this has come up  
consistently over the last few years).


Note that in neither case do they really care about the open-source  
aspects of their toolchain (or for the most part the OS either).
They may (and often do) like the commoditization of software that  
FOSS tends to drive, but don't mistake that for caring about the  
open source ideals -- it's merely cost-cutting.


While I often encounter individual engineers or managers within  
these organizations who care about the FOSS ideals and have helped  
drive FOSS into those organizations; it's usually not pervasive in  
those organizations, even those who have had good success with FOSS  
platforms.


I don't know if that answers your question or not.

Jeff

Re: Inline Assembly Error: suffix or operands invalid for 'shr'

[Chris Lattner]

On Mar 24, 2009, at 11:02 AM, Rodrigo Dominguez wrote:
When assembling this program, 'cc1' emits a 'shrl %ecx, %eax'  
instruction.
The 'shr' instruction can only take an 8-bit register as the first  
operand.
The emitted instruction should have been 'shrl %cl, %eax'.  
Therefore, the

compilation fails with a 'suffix or operands invalid for shr' message.

I have 2 questions:

1. AFAIK, by default, __asm__ chooses a register according to the  
size of

the operand (int8_t in this case). Is this correct? Where can I find
documentation of this?


Though several people responded with useful information, no one has  
answered the question.  The issue here is that -s has int type, not  
int8_t because of C promotion rules.  Try using (int8_t)(-s).



-Chris

Re: GCC 4.4.0 Status Report (2009-03-13)

[Chris Lattner]

On Mar 22, 2009, at 3:38 PM, Jeff Law wrote:

Steven Bosscher wrote:

On Sun, Mar 22, 2009 at 4:05 PM, Jeff Law l...@redhat.com wrote:

I think you're wrong.  Many of these players are large companies  
(such
as IBM and now, RedHat).  Putting them in the position of having  
to

reject the official FSF contribution is awkward for them.



I'm sorry, but I don't see it that way.


Having been on the front lines on this issue in the past, I can  
say our
customers certainly cared about it and therefore we (Cygnus, now  
Red Hat)

care about it.



Perhaps it was true more 12 years ago than today.  The whole idea of
FOSS is probably better understood than 12 years ago.  At least,
projects like Linux and LLVM attract contributions from large
companies without involvement of the FSF.


These companies really don't care about FOSS in the same way GCC  
developers do.   I'd be highly confident that this would still be a  
serious issue for the majority of the companies I've interacted with  
through the years.


Hi Jeff,

Can you please explain the differences you see between how GCC  
developers and other people think about FOSS?  I'm curious about your  
perception here, and what basis it is grounded on.


Thanks,

-Chris

LLVM 2.5 Release

[Chris Lattner]

Hi All,

FYI, LLVM 2.5 was released today:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-March/31.html
http://llvm.org/releases/2.5/docs/ReleaseNotes.html

If you are interested in LLVM, please follow up on the LLVM mailing  
lists, thanks!


-Chris 

Re: GCC OpenCL ?

[Chris Lattner]

On Feb 3, 2009, at 8:48 AM, Mark Mitchell wrote:


Andrey Belevantsev wrote:


Obviously, a library is not enough for a heterogeneous system, or
am I missing anything from your description?  As I know, e.g. there  
is

no device-independent bytecode in the OpenCL standard which such a
backend could generate.


That's correct.  I was envisioning a proper compiler that would take
OpenCL input and generate binary output, for a particular target, just
as with all other GCC input languages.  That target might be a GPU, or
it might be a multi-core CPU, or it might be a single-core CPU.

Of course, OpenCL also specifies some library functionality; that  
could

be provided in a library that included hand-written assembly code, or
was generated by some non-GCC tool.


That's an interesting and very reasonable approach to start with.   
However, realize that while this will give you ability to run programs  
that use some of the OpenCL language extensions, you won't be able to  
run any real OpenCL apps.  The OpenCL programming model fundamentally  
requires runtime compilation and the kernel-manipulation library APIs  
are a key part of that.


-Chris

Re: GCC OpenCL ?

[Chris Lattner]

On Feb 1, 2009, at 5:41 AM, Toon Moene wrote:
I am just starting to think about adding OpenCL support into  
future versions of
GCC, as it looks like a useful way of programming highly parallel  
type systems,
particularly with hetrogeneous processors.  At this point, I am  
wondering what
kind of interest people have in working together on OpenCL in the  
GCC compiler?
I might be working on parallelization (though in LLVM) for the next  
one

or two years.  If I have some free time to put into GCC, I'd love to
port my work to it and to collaborate with people already working  
on OpenCL.


Although the OpenCL infrastructure doesn't confine itself to it,  
this compute-on-the-graphic-processor type of parallellism mostly  
concerns itself with let's do the FFT (or DGEMM) really fast on  
this processor and then return to the user.


This was true a year or two ago, but isn't really true any more.   
Current GPUs are (almost) completely programmable and the trend is  
obviously continuing towards greater generality.  If you have a data  
parallel problem, they can be an excellent solution.  GPUs are also  
fully IEEE compatible now as well.


OTOH, compiling for them is non-trivial ;-)

If it isn't (surely not for us meteorology types) this approach is  
of limited use.


If you are limited by flops and memory bandwidth and your problems can  
be tiled, GPUs can be extremely nice.


-Chris

Re: New GCC Runtime Library Exception

[Chris Lattner]

On Jan 29, 2009, at 7:38 AM, Joern Rennecke wrote:

 The difference is that the front end does not work on source  
code, but
 Java bytecode, which seems closer to intermediate representation  
than

 to a high-level, non-intermediate language.

I think it is clear that Java bytecode, which can even be executed
directly by some microprocessors, is not a compiler intermediate
representation.


That is beside the point.  It is not a high level language.  Hence,
when you use gcc to compile Java bytecode to Target Code, this is not
an eligible compilation process.

When you use a non-GPL-compatible java frontend to compile Java  
source to

bytecode and then use GCC to compile this to Target Code, it is not
an eligble compilation process either, because you used a non-GPL- 
compatible

frontend.


This issue is also somewhat confusing to me.  It is a moot point,  
because LLVM is GPL compatible, but is LLVM .ll language considered a  
target code, intermediate representation, or a high-level, non- 
intermediate language?  It is not clear to me how LLVM .ll files are  
different from .c files that are used as intermediates between bison  
and a C compiler.


LLVM .ll files are a fully documented language and people write them  
by hand all the time.  It is quite arguably much higher level that  
machine code (having concepts like call with arguments, a type  
system, etc), and is fully specified (http://llvm.org/docs/ 
LangRef.html).  It seems quite possible to argue that it is a high- 
level, non-intermediate language (at least at least as much as C is).


Is the wording intended to allow LLVM .ll files as high-level, non- 
intermediate language, or are they considered an IR?  What is the  
dividing line?  It seems that this is a very important issue for the  
entire license.


-Chris

Re: RFC: case insensitive for #include

[Chris Lattner]

On Jan 28, 2009, at 12:24 PM, H.J. Lu wrote:

On Wed, Jan 28, 2009 at 12:21 PM, Chris Lattner clatt...@apple.com  
wrote:


On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote:


Hi,

I got a request to try FOO.H if foo.h doesn't exist when dealing
with

#include foo.h

Any comments?


I strongly recommend against this, unless this is only a last  
chance fall

back.

From a performance standpoint, if you have -Idir1 -Idir2 -Idir3,  
you don't
want to stat all variants of foo.h in dir1 before moving on to  
dir2.  If
you do a full search for foo.h in all appropriate search paths, and  
then
redo it only on failure, then the performance issue goes away.   
However, in
that  case you get very difficult to explain behavior if you have  
multiple

files with spelling variants of foo.h in different search paths.



I won't stat all variants of foo.h. I think scandir will work here  
and

this feature will be supported only if scandir is available.


HJ, this is a very performance sensitive part of the preprocessor.   
Just doing a scandir would be a huge cost.


-Chris

Re: Request for testing/help for the LTO branch

[Chris Lattner]

On Jan 29, 2009, at 11:25 AM, Rafael Espindola wrote:

Is it IO bound because the LTO files are abnormally large?  What  
kinds of

file sizes are you seeing?


With the streamer debug enable we had over 40x the normal object size.
Without it, it looks to be 4 or 5 times if I remember correctly.


Thanks Rafael!

-Chris

Re: RFC: case insensitive for #include

[Chris Lattner]

On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote:


Hi,

I got a request to try FOO.H if foo.h doesn't exist when dealing
with

#include foo.h

Any comments?


I strongly recommend against this, unless this is only a last chance  
fall back.


From a performance standpoint, if you have -Idir1 -Idir2 -Idir3, you  
don't want to stat all variants of foo.h in dir1 before moving on to  
dir2.  If you do a full search for foo.h in all appropriate search  
paths, and then redo it only on failure, then the performance issue  
goes away.  However, in that  case you get very difficult to explain  
behavior if you have multiple files with spelling variants of foo.h in  
different search paths.


-Chris

Re: Serious code generation/optimisation bug (I think)

[Chris Lattner]

On Jan 27, 2009, at 5:10 PM, Ian Lance Taylor wrote:


Chris Lattner clatt...@apple.com writes:


On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:


Laurent GUERBY laur...@guerby.net writes:


Just curious: is there a portable way to read from memory
address zero in C code? portable here means likely to work
on most compilers without exotic compile flags in 2009.


char *my_null_pointer;
char fn() { return *my_null_pointer; }

It will be quite a while before whole program optimization is good
enough to prove that my_null_pointer is not referenced by anything
else.


Perhaps in GCC, but this is not a good solution if you care about
other compilers.


Is LLVM smart enough to optimize that away, even when using shared
libraries?


Yes absolutely.  Just build with -fvisibility-hidden or use an export  
map to say that my_null_pointer is not exported.  If it is static, it  
will also do it at -O2.  This is not even a particularly aggressive  
optimization.


-Chris

Re: Request for testing/help for the LTO branch

[Chris Lattner]

On Jan 27, 2009, at 1:11 PM, Diego Novillo wrote:


The LTO branch is starting to get some semblance of stability, though
is by no means in any kind of mergeable state.  I have updated the
wiki page to reflect the current status (Simon, Rafael, Doug, Cary,
please make sure I haven't missed anything substantial):

http://gcc.gnu.org/wiki/LinkTimeOptimization


Hi Diego,

Thanks for the summary, it's great to see the progress of the  
project.  Do you have any compile time numbers for LTO so far?  If you  
pick a mid-sided program from spec or even a bootstrap, how much  
slower is LTO than compiling at -O3?


-Chris

Re: Serious code generation/optimisation bug (I think)

[Chris Lattner]

On Jan 27, 2009, at 10:47 PM, Ian Lance Taylor wrote:

Is LLVM smart enough to optimize that away, even when using shared
libraries?


Yes absolutely.  Just build with -fvisibility-hidden or use an export
map to say that my_null_pointer is not exported.  If it is static, it
will also do it at -O2.  This is not even a particularly aggressive
optimization.


Sure, but the whole idea here is for the compiler to *not* know that
the pointer has a zero value.  What I was really asking was whether
LLVM would figure that out without taking any special action to
restrict the visibility of the pointer.


I don't think that there is any smartness in assuming that.  I would  
claim that would be outrageously unsafe and incorrect to do that,  
unless the optimization is done at runtime or the user provides a flag  
with -fwhole-program.  Regardless, many people build their libraries  
with -fvisibility-hidden, and build settings are often not controlled  
by engineers hacking code.  It would be fragile to assume these aren't  
being set.


Laurent originally asked for a safe idiom for doing this likely to  
work on most compilers without exotic compile flags in 2009.  The  
idiom won't work, because many compilers other than LLVM default to  
whole-program optimization at sufficiently high -O levels, and you  
presumably don't want to make fragile assumptions about what *other*  
flags are getting passed to your build.  He said nothing about  
libraries or where the code may end up.


I'm pretty sure that shared libraries are rare on systems without  
mmu's anyway.


-Chris

LLVM 2.4

[Chris Lattner]

For anyone interested, LLVM 2.4 was just released:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2008-November/30.html
http://llvm.org/releases/2.4/docs/ReleaseNotes.html

It has a number of new features, but the most user visible one is that  
it compiles about 30% faster than LLVM 2.3 at -O0 -g.  This is a  
common mode for the compile/debug/edit turn around cycle and for  
various JIT applications. llvm-gcc was already typically 30% faster  
than GCC at compiling code when optimizations are enabled.


Please see the release notes for more details, and follow up on the  
llvmdev mailing list if you have questions.


-Chris

Re: [lto][RFC] Do not emit hybrid object files

[Chris Lattner]

On Oct 17, 2008, at 1:01 PM, Jeff Law wrote:
Reality is there aren't too many non-ELF targets that matter anymore  
and, IMHO, it's reasonable to demand ELF support for LTO.  The only  
other format that has a reasonable chance of working would be the  
COFF variants anyway and the only COFF variant that is meaningful is  
used by AIX (and perhaps Darwin?!?).


Darwin already has a GCC-based compiler that fully supports LTO,

-Chris

Re: Apple, iPhone, and GPLv3 troubles

[Chris Lattner]

On Sep 25, 2008, at 3:11 AM, Paolo Bonzini wrote:


This means that you couldn't use *GCC* if you
did something the FSF found objectionable, closing an easy
work-around.


This doesn't work, because it breaks out of the basic framework of
copyright law.  Nobody signs anything or accepts any terms in order  
to

use gcc.  The FSF wants to stop people from distributing proprietary
binary plugins to gcc.  The copyright on gcc does not apply to those
plugins.


Also, even if you could develop a license similar to the GPL but  
with an

additional restriction to this end, this would not be the GPL anymore,
because GPLv3 limits the non-permissive additional terms to the ones
listed in Section 7:


The FSF could certainly define a new GPL4 or GPL3.1 or whatever,  
that contained any wording they want.  However, this whole discussion  
is off topic for this list, I'm sorry I've propagated it this far!


-Chris

Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)

[Chris Lattner]

On Sep 24, 2008, at 8:51 AM, Jack Howarth wrote:

The SC knows of the issue


Still, after six months it would be nice to have a clearer idea of  
what
will happen with respect to Darwin/ObjC, especially since the  
previous
statement (which I suppose was as clear as Mike could do) was  
buried

under an unrelated thread.

Paolo


Do we know if Apple still intends to update the ObjC in FSF gcc to  
v2.0?

   Jack


We don't have any short-term plans to do so.  However, all the code  
for ObjC 2.0 and even the new C Blocks feature is available in the  
llvm-gcc repository.  One potential issue is that while Apple has a  
blanket copyright assignment with the FSF, I don't know whether code  
in the llvm-gcc repo is auto-assigned to the FSF.


-Chris

Re: Apple, iPhone, and GPLv3 troubles

[Chris Lattner]

On Sep 24, 2008, at 7:06 AM, Ian Lance Taylor wrote:

fix the problem.  My understanding of Apple's current position is that
they won't take any action until they see the final version of the gcc
runtime license.


Basically, what happened is that Apple created a Tivoized device  
called the

iPhone,
and Apple uses GCC (which is now under GPLv3) and Mac OS X on it.
Unfortunately, the iPhone is incompatible with GPLv3, if you want  
more see

the link I mentioned.


Using gcc to compile your code does not impose any licensing
requirements on that code.


I'm not speaking for Apple here, and I am not a lawyer.  However, the  
last draft of the runtime library exception clause (which is quite old  
by now) imposed licensing restrictions on the executables generated by  
GCC (due to linked runtime libraries) if you did certain things to the  
compiler.  I'm personally very eager to see the final wording, because  
the draft I saw (again, which is old and has certainly changed) was  
extremely aggressive.


-Chris

Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)

[Chris Lattner]

On Sep 24, 2008, at 8:02 AM, Duncan Sands wrote:


However if GPLv3 is such a huge issue
at Apple, it does make one wonder if llvm will ever see a gcc  
front-end newer

than the current 4.2 one.


The LLVM folks are writing a new frontend anyhow.  In the future they
presumably plan to stop using the gcc frontend.  gcc's code is so
tangled anyhow, it's not like using the gcc frontend somehow makes
LLVM compile code the same way gcc does.


I'm quite interested in porting llvm-gcc to gcc head, in order to
get better Ada support.


As Duncan says here, Apple and the LLVM Project really are separable  
entities.  As a developer on the LLVM Project, I'd love to see a new  
version of llvm-gcc based on ToT GCC.  I'm not sure how technically  
feasible it is, but it would be even better for future versions of  
llvm-gcc to be based on the new GCC plugin model.


-Chris