> 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
On Feb 11, 2014, at 10:59 AM, Renato Golin 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 wh
On Jan 23, 2014, at 12:14 PM, Steven Bosscher 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",
On Feb 8, 2013, at 8:24 AM, Jeff Law 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
On Nov 27, 2012, at 11:36 PM, Xinliang David Li 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 contras
On Nov 27, 2012, at 11:05 PM, Xinliang David Li wrote:
> On Tue, Nov 27, 2012 at 10:40 PM, Chris Lattner wrote:
>>
>> On Nov 27, 2012, at 9:08 PM, Miles Bader wrote:
>>
>>> Chris Lattner writes:
>>>> Clang has fantastic support for PCH... and soo
On Nov 27, 2012, at 9:08 PM, Miles Bader wrote:
> Chris Lattner 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
On Nov 27, 2012, at 5:16 PM, Xinliang David Li 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
On Nov 27, 2012, at 3:32 PM, Eric Botcazou 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
On Nov 27, 2012, at 8:00 AM, Diego Novillo 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/s
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
On Jan 31, 2012, at 5:15 AM, Ludovic Courtès wrote:
>>
>> Interestingly enough:
>> $ cat q.c
>> __has_builtin
>> $ clang -E q.c
>>
>
> 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 ma
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 a
On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote:
> Hello,
>
> Chris Lattner skribis:
>
>> On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote:
>>
>>> On 21 January 2012 00:32, Vincent Lefevre wrote:
>>>> On 2012-01-20 23:28:07 +, Jonath
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 '=', ',', ';', 'a
On Jan 20, 2012, at 5:24 PM, Jonathan Wakely 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'
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 ti
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.
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
&g
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
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
>>> ex
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
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
On Mar 12, 2011, at 8:17 PM, Jack Howarth 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
> ad
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_inst
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:
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:
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 progra
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 b
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
On Sep 15, 2010, at 12:23 AM, Kevin André wrote:
> On Tue, Sep 14, 2010 at 17:55, Chris Lattner wrote:
>>
>> On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote:
>>
>>> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor wrote:
>>>> From the perspect
On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote:
> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor wrote:
>> Manuel López-Ibáñez 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
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 COMPA
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
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 c
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
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 accepte
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 muc
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 se
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 assor
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 th
On Apr 26, 2010, at 12:23 PM, Ian Lance Taylor wrote:
> Chris Lattner 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 th
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
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 th
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 assignm
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
On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote:
> On 25 April 2010 06:20, Chris Lattner wrote:
>>
>> On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
>>
>>> On 24 April 2010 00:18, Alfred M. Szmidt wrote:
>>>>
>>>> The dis
On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
> On 24 April 2010 00:18, Alfred M. Szmidt 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 th
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 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
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? Ther
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
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?
>>
>>
> Dragone
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:
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, "i
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 usefu
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
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-cl
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
> "
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
> t
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
> "
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 mod
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 compile
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
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 p
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
On Sep 16, 2009, at 11:12 AM, Vincent R. wrote:
True, though Apple's entry in the copyright file says "assigns past
and
future changes" (I checked before the above e-mail). Certainly
checking
with the FSF is a good idea.
Ian
While we are discussing apple extension, is there a list of appl
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 i
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 Bonzini
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'r
Is there any plan to put the GCC 2009 proceedings on the wiki page?
-Chris
On Jun 5, 2009, at 3:43 AM, Steven Bosscher wrote:
On Fri, Jun 5, 2009 at 12:40 PM, Andrew Nisbet
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 L
On Jun 4, 2009, at 3:20 AM, Steven Bosscher wrote:
On Thu, Jun 4, 2009 at 12:14 PM, Rafael Espindola > 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 fro
On Jun 3, 2009, at 11:59 PM, Miles Bader wrote:
Chris Lattner 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,
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.ht
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
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
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 o
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
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 define
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
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
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
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 th
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 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 contrib
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
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 cou
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
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.
On Jan 28, 2009, at 12:24 PM, H.J. Lu wrote:
On Wed, Jan 28, 2009 at 12:21 PM, Chris Lattner
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 s
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
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 -I
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.
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 anythi
On Jan 27, 2009, at 5:10 PM, Ian Lance Taylor wrote:
Chris Lattner writes:
On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
Laurent GUERBY writes:
Just curious: is there a "portable" way to read from memory
address zero in C code? "portable" here means li
On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
Laurent GUERBY 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() { re
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
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 varia
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
On Sep 24, 2008, at 12:57 PM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
My personal feeling on the matter is that it seems very strange to
talk about *compiler plugins* in the license for *runtime libraries*.
Considering that there are already widely ava
On Sep 24, 2008, at 11:22 AM, Joe Buck wrote:
On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote:
Right. However, the wording I saw was much broader than just the
plugin model. It was vague and poorly worded, and you could
interpret
it as saying that use of a non-GPL assembler
On Sep 24, 2008, at 10:50 AM, Ian Lance Taylor wrote:
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
1 - 100 of 240 matches
Mail list logo
