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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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
Is there any plan to put the GCC 2009 proceedings on the wiki page?
-Chris
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 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 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 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 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
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 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
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 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 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 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 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 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 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 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
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 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
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
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 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:
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
Consider this C++ example (I've annotated each class decl with the
unit size of each structure):
struct A { virtual ~A(); }; // 4
struct B { virtual ~B(); }; // 4
struct X : virtual public A,
virtual public B { // 8
};
struct Y : virtual public B { // 4
virtual ~Y()
On Mar 23, 2006, at 3:53 PM, Mark Mitchell wrote:
As I just sent in my Gelato abstract
Oh right, I have to do that too! :)
(at which you and I will be
presenting talks about different approaches to link-time
optimization in
GCC), I was wondering what the status of the LLVM copyright assign
On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote:
Let's accept that both the bit-preserving and value-preserving
conversions would be useful. How do we differentiate the two?
For vectors, these operators would apply to each element, and then
return a vector with the same number of elements
LLVM 1.7 was just released! If you're interested, get it here:
http://llvm.org/releases/
Or read about it here:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2006-April/18.html
and/or here:
http://llvm.org/releases/1.7/docs/ReleaseNotes.html
-Chris
--
http://nondot.org/sabre/
http://l
On May 22, 2006, at 4:18 PM, Mark Mitchell wrote:
We have had some very useful discussions with Chris Lattner and other
folks at Apple. Our conclusion is that LLVM does indeed have a very
clean design and is very promising technology, but that there is
still a
lot of technical work to do
On Jun 26, 2006, at 8:56 AM, Zdenek Dvorak wrote:
Hello,
predcom branch is now ready for testing.
Very cool.
We basically implemented
second-order predictive commoning (quick overview can be found
e.g. in
http://www.cs.ualberta.ca/~amaral/cascon/CDP04/slides/tal.pdf, or
at the
beginning
On Jun 29, 2006, at 6:51 AM, Dave Korn wrote:
That's cheating! You casted away const, it's a blatant aliasing
violation,
you deserve everything you get. The compiler is specifically
*allowed* to
assume you don't pull stunts like this *in order to* make const-
optimisation
possible and
On Jun 29, 2006, at 9:20 AM, Paolo Bonzini wrote:
Well, G is known to escape anyway here. Even worse is this:
...
where there is not even the possibility to optimize *P1 in foo.
While compiling f1.c, the compiler does not even know that G
escapes and must assume the worse.
It's a diffe
For those who are interested:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2006-August/19.html
http://llvm.org/releases/1.8/docs/ReleaseNotes.html
Download here:
http://llvm.org/releases/
-Chris
On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
Interesting email. One question: how big are the fil
On Aug 28, 2006, at 10:36 AM, Kenneth Zadeck wrote:
I actually do not think that it is productive to spend that much time
measuring this until we first assure ourselves that we are getting all
of the information output correctly. That 60mb number will change
a lot
(both up and down) as we get
On Sep 16, 2006, at 10:23 PM, Andrew Pinski wrote:
I just got crazy idea, since we really don't like CONSTRUCTOR that
much
and we already know the lengths of Vectors, we can have a VECTOR_EXPR
which we could then use instead of CONSTRUCTORs.
What don't you like about CONSTRUCTOR's? Taking
On Sep 17, 2006, at 11:56 AM, Andrew Pinski wrote:
On Sun, 2006-09-17 at 10:33 -0700, Chris Lattner wrote:
On Sep 16, 2006, at 10:23 PM, Andrew Pinski wrote:
I just got crazy idea, since we really don't like CONSTRUCTOR that
much
and we already know the lengths of Vectors, we can h
On Sep 28, 2006, at 1:43 PM, Mark Mitchell wrote:
Sandra Loosemore wrote:
I've been having a heck of a time figuring out how to translate
the offsets for struct fields from the DWARF encoding back to
GCC's internal encoding for the LTO project.
Yes, that's a nasty bit.
I think the DECL_FI
On Sep 28, 2006, at 1:58 PM, Mark Mitchell wrote:
Chris Lattner wrote:
An alternative design, which would save a field, is just to keep
the offset of a field, in bits, from the start of the structure.
Yes, that would also work. But, in many cases, you need the byte
offset, so there
On Oct 1, 2006, at 7:57 PM, Richard Kenner wrote:
It can't be normalized to BITS_PER_UNIT, but to DECL_OFFSET_ALIGN
since
we are asserting that DECL_FIELD_OFFSET is aligned to
DECL_OFFSET_ALIGN.
That doesn't make sense to me. It seems to me that we can
normalize it
however we please; ul
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 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 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 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 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 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 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 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 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 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
Hi all,
For anyone who is interested, we just released LLVM 2.2 with numerous
enhancements:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2008-February/25.html
http://llvm.org/releases/2.2/docs/ReleaseNotes.html#whatsnew
One of the big changes is that we now recommend the GCC 4.2-based
On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3 since
more than
three month.
Well, how often do you take a trap inside an overlapping memmove()?
How hard is it to change the kernel signal entry path f
Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3
since more
than
three month.
Well, how often do you take a trap inside an overlapping memmove()?
How hard is it to change the kernel signal entry path from "pushf" to
"pushf;cld"? Problem solved, no?
Th
On Mar 5, 2008, at 4:47 PM, H. Peter Anvin wrote:
Chris Lattner wrote:
Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3
since more
than
three month.
Well, how often do you take a trap inside an overlapping
memmove()?
How hard is it to chang
On Mar 6, 2008, at 2:06 PM, Andi Kleen wrote:
On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote:
Richard Guenther wrote:
A patched GCC IMHO makes only sense if it is always-on, yet
another option
won't help in corner cases. And corner cases is exactly what
people seem
to ca
On Mar 7, 2008, at 6:06 PM, Ian Lance Taylor wrote:
Tom Tromey <[EMAIL PROTECTED]> writes:
Ian suggested that we delete this information after the FE is
finished. This makes sense, I think, from a memory-saving
perspective. But, that means we will get different kinds of error
output dependi
On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
clang points into the original input buffer that was lexed from.
This
requires keeping the original files mapped into the address space of
the compiler. However, clan
On Mar 12, 2008, at 9:49 PM, Manuel López-Ibáñez wrote:
The clang front-end generates these warnings. This means that the
set
of warnings produced by the compiler doesn't change as the optimizer
evolves, are generally less mystifying to the user, and have perfect
location info as a side effect
On Mar 12, 2008, at 11:21 PM, Manuel López-Ibáñez wrote:
On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
There is no right answer, and this topic has been the subject of much
debate on the GCC list in the past. I really don't care to debate
the
merits of one approach v
On Mar 13, 2008, at 11:37 AM, Ian Lance Taylor wrote:
As you know the optimizers can pull together information
from all over the place. The actual warning can be issued for code
which looks very different from anything the user actually wrote.
Translating back to the problem in the user code ca
On Mar 13, 2008, at 4:58 PM, Manuel López-Ibáñez wrote:
On 13/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
How about -fshow-caret instead of -fdiagnostics-show-caret?
(By analogy with -fshow-column.)
Manuel> Well, we have -fdiagnostics-show-option and
Manuel> -fdiagnostics-show-location.
On Apr 4, 2008, at 10:13 AM, H.J. Lu wrote:
Hi,
For each new set of x86 intrinsics, we introduce a new header file. It
will be desirable for users just to include one header file for all
intrinsics, current and future. Icc has , which includes
proper individual intrinsic header files and users
I prefer , as these are presumably usable in x86-64
mode.
One random request: would it be possible to keep mm_malloc.h out of
the
umbrella header? Inclusion of mm_malloc.h make use of SSE
difficult in
kernel contexts, as mm_malloc.h pulls in stdlib.h and errno.h.
The idea is one header
On Apr 28, 2008, at 12:04 PM, Diego Novillo wrote:
[ Apologies if this comes out twice. I posted this message last week,
but I think it was rejected because of a .pdf attachment. ]
We have been bouncing ideas for a new mechanism to describe the
behavior
of function calls so that optimize
On Jun 3, 2008, at 9:45 AM, Diego Novillo wrote:
We've started working on the driver and WPA components for whopr.
These are some of our initial thoughts and implementation strategy. I
have linked these to the WHOPR page as well. I'm hoping we can
discuss these at the Summit BoF, so I'm posting
On Jun 4, 2008, at 8:27 AM, Kenneth Zadeck wrote:
It is certainly not going to be possible to do this for all ipa
passes, in particular any pass that requires the function body to be
reanalyzed as part of the analysis pass will not be done, or will be
degraded so that it does not use this
On Jun 4, 2008, at 7:22 AM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
Is there a specific reason you don't use the LLVM LTO interface? It
seems to be roughly the same as your proposed interface:
a) it has a simple C interface like your proposed one
b) it
On Jun 4, 2008, at 12:27 AM, Rafael Espindola wrote:
Is there a specific reason you don't use the LLVM LTO interface?
It seems
to be roughly the same as your proposed interface:
a) it has a simple C interface like your proposed one
b) it is already implemented in one system linker (Apple's)
On Jun 4, 2008, at 9:29 AM, Chris Lattner wrote:
Suppose the linker is invoked on a
sequence of object files, some with with LTO information, some
without, all interspersed. Suppose some symbols are defined in
multiple .o files, through the use of common symbols, weak symbols,
and/or section
On Jun 4, 2008, at 10:39 PM, Ian Lance Taylor wrote:
Devang Patel <[EMAIL PROTECTED]> writes:
If the optimizer can handle the symbol versioning case when one
definition with version is defined in the same source file as the
reference then you don't need new API.
For example,
a.o : refers to S
On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
I don't know how closely your plans follow this model. If you think
this approach is reasonable, you really do need to reflect things
like
symbol versions in your IR somehow. This co
On Jun 5, 2008, at 6:59 AM, Ian Lance Taylor wrote:
"Rafael Espindola" <[EMAIL PROTECTED]> writes:
Interesting. The use of lto_codegen_add_must_preserve_symbol is kind
of the opposite of what I had understood. What do you do in this
case:
a.o: IL file that contains a reference to "f"
b.o:
On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote:
Nick Kledzik <[EMAIL PROTECTED]> writes:
How does the linker tell LTO that a symbol may be inlined, but must
also be externally visible?
The linker just tells LTO which symbols must remain. The LTO engine
is free to inline anything that wo
On Jun 5, 2008, at 10:38 AM, Ian Lance Taylor wrote:
Sure. But here's the thing: the gcc LTO approach involves having a
regular object with a regular symbol table, and the IR is embedded
in
the object. In other words, we do know the symbol version
information: it's in the symbol table of the
On Jun 5, 2008, at 6:18 PM, Ian Lance Taylor wrote:
How does the linker tell LTO that a symbol may be inlined, but
must
also be externally visible?
The linker just tells LTO which symbols must remain. The LTO
engine
is free to inline anything that would improve codegen, with the
exception
t
Hi all,
For anyone who is interested, we just released LLVM 2.3:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2008-June/27.html
http://llvm.org/releases/2.3/docs/ReleaseNotes.html
It has many improvements over the 2.2 release from February, including
better support for gfortran and Ad
do it. I guess this is the classic "patches welcome" answer :). In
the meantime, llvm-gcc 4.2 is being well supported and is under active
development.
-Chris
Jack
On Mon, Jun 09, 2008 at 09:09:29AM -0700, Chris Lattner wrote:
Hi all,
Fo
On Jun 22, 2008, at 4:24 PM, Bruno Haible wrote:
Dear Ian,
A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer
"C++ is too complicated!"
with
"Maintainers will ensure that gcc continues to be maintainable."
C++ has, for example, 12 different ways to represent or invoke
On Jul 3, 2008, at 9:01 AM, Jim Wilson wrote:
x z wrote:
If we want to fix this, gcc must change. And this may
also require GNU libc changes and linux kernel changes, etc.
Maybe you can enlighten us a bit on why GNU libc and linux kernel
need changes so that we can realize better how complic
On Jul 3, 2008, at 10:01 AM, Andrew Haley wrote:
Chris Lattner wrote:
IMO, the whole notion of a compiler-specific macro has pretty limited
usefulness. Why not add macros for specific *features* offered by
the
compiler. For example:
#ifdef __SUPPORTS_NESTED_FUNCTIONS__
is much better
On Jul 3, 2008, at 10:50 AM, Ralf Wildenhues wrote:
Hello,
Chris Lattner wrote:
IMO, the whole notion of a compiler-specific macro has pretty
limited
usefulness. Why not add macros for specific *features* offered by
the compiler. For example:
#ifdef __SUPPORTS_NESTED_FUNCTIONS__
On Jul 3, 2008, at 2:12 PM, Josh Triplett wrote:
I'd suggest defining exactly one new preprocessor symbol, to advertise
the support for the feature-testing mechanism. For instance,
__HAVE_EXTENSION_SUPPORTED__, or __FEATURE_SUPPORTED_SUPPORTED__. :)
The rest could use syntax like you suggest abo
On Jul 3, 2008, at 3:01 PM, Joseph S. Myers wrote:
Taking an approach reduces startup time of the preprocessor,
because it
doesn't have to populate the identifier table with tons of
predefines.
I'd hope this is not a significant cost (certainly not compared to the
thousands of built-in funct
On Jul 24, 2008, at 9:26 AM, Kenneth Zadeck wrote:
3) Generate the debugging for the types late. The problem here is
that we want the gimple type system to be stripped of the front end
specific information, so any front end specific info that is only
necessary for the debugging, will both b
On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
I thought the whole idea of the LTO project was to keep as much
language specific type information as late as possible. If you
start stripping out useful information about types, it becomes
harder to do high level optimizations like devirt
101 - 200 of 240 matches
Mail list logo
