On Oct 15, 2006, at 3:12 PM, Mark Mitchell wrote:
A typedef declaration which adds semantic attributes to a POD class
type with no function members is valid, but creates an entirely new
type, different from all other types except others formed by adding
the same combination of semantic attr
On Nov 10, 2006, at 9:08 PM, Geert Bosch wrote:
The common case is that people just don't use the -j feature
of make because
1) they don't know about it
2) their IDE doesn't know about it
3) they got burned by bad Makefiles
4) it's just too much typing
Don't forget:
5) running 4 GCC
On Dec 17, 2006, at 12:40 PM, Rask Ingemann Lambertsen wrote:
Hi.
I seem unable to get a QImode shift instruction from this code:
unsigned char x;
void qishifttest2 (unsigned int c)
{
x <<= c;
}
should have been generated. Also, notice the redundant zero extension.
Why are we
No. You're confusing some language you just invented with C.
The operand of the shift operator is of type unsigned int.
"x <<= c" is exactly the same as "((int)x) << c"
It doesn't matter whether the promotion is explicit or implicit,
the semantics
are the same.
((char)x) = ((char)( ((int)((c
On Dec 18, 2006, at 9:24 AM, Robert Dewar wrote:
Chris Lattner wrote:
Sorry, but you're incorrect. While it may be "logical" that
shifting a value left more bits than its size will give you zero,
this is not what C specifies.
I am puzzled, what exactly *does* C speci
On Dec 18, 2006, at 9:53 AM, Robert Dewar wrote:
Chris Lattner wrote:
C99 says:
The integer promotions are performed on each of the operands. The
type of the result is
that of the promoted left operand. If the value of the right
operand is negative or is
greater than or equal to the
On Dec 18, 2006, at 10:19 AM, Rask Ingemann Lambertsen wrote:
On Mon, Dec 18, 2006 at 03:19:19AM +, Paul Brook wrote:
Shifting >= the size of the value being shifted can and do give
nonzero
results on common hardware. Typically hardware will truncate the
shift count.
eg. x << 8 implem
On Feb 6, 2007, at 5:06 PM, Joe Buck wrote:
On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
I also think it would be good to have one option affecting it: turn
__builtin_unreachable() into an abort(), or turn it into a "cannot be
reached" marker. I think the former should be
On Mar 2, 2007, at 7:57 AM, Ian Lance Taylor wrote:
[ Moving from gcc-patches to gcc ]
Chris Lattner <[EMAIL PROTECTED]> writes:
The LLVM dev policy does not to try to define common sense. It is a
rough guideline which can be deviated from when it makes sense.
"Trust but verify&q
On Apr 1, 2007, at 10:42 PM, Joe Buck wrote:
On Sun, Apr 01, 2007 at 02:20:10PM +0200, Marcin Dalecki wrote:
Wiadomość napisana w dniu 2007-04-01, o godz13:58, przez Paul
Brook:
If you're already switching compilers, moving to an already
obsolete release
(3.3) seems a strange choice. At
On May 1, 2007, at 9:42 AM, Ian Lance Taylor wrote:
"Sjodin, Jan" <[EMAIL PROTECTED]> writes:
Hi I am new to GCC development and I have a few questions about LTO.
What has been done since the last status report in January? I would
also like to know what is most important to work on right now
Karel Gardas wrote:
Yes, that's undefined, but I just define this class to be able to do:
Foo* f = dynamic_cast(x);
l = f->iiop_version();
there is nothing like delete involved. Anyway, I agree with you that
emit warning about this is probably the right thing to do and so I will
fix my code.
I've
On Fri, 4 Mar 2005, Mark Mitchell wrote:
I've run into this warning with C++ code as well, and it is quite annoying.
There are lots of possible reasons to want to do this sort of thing, and
adding a virtual dtor increases the size of the vtable for the class.
Yeah, there goes one whole pointer pe
On Fri, 4 Mar 2005, Mark Mitchell wrote:
Chris Lattner wrote:
Age-old debate: better to warn early about possibly broken interfaces, or
late about definitely broken usage? I think that warning early, together
with what DJ is calling fine-grained warning control is the best solution.
I don&#
On Fri, 4 Mar 2005, Mark Mitchell wrote:
Chris Lattner wrote:
I'm not sure I understand your point here. The library developer writes a
class, and does not *want* it to be destroyed through the base class. As a
library designer, I can intentionally make the dtor protected, making it
p
Hi All,
This is just some quick spam to announce the LLVM 1.5 release:
http://mail.cs.uiuc.edu/pipermail/llvm-announce/2005-May/16.html
http://llvm.cs.uiuc.edu/releases/1.5/docs/ReleaseNotes.html#whatsnew
Among other things, this release adds beta IA64 and Alpha backends,
support for general p
Hi All,
I'm trying to determine (in target-independent code) what the
*minimum* target alignment of a type is. For example, on darwin,
double's are normally 4-byte aligned, but are 8-byte aligned in some
cases (e.g. when they are the first element of a struct). TYPE_ALIGN
on a double r
On Jul 22, 2005, at 11:27 AM, Dale Johannesen wrote:
On Jul 22, 2005, at 11:07 AM, Chris Lattner wrote:
I'm trying to determine (in target-independent code) what the
*minimum* target alignment of a type is. For example, on darwin,
double's are normally 4-byte aligned, but
On Jul 22, 2005, at 12:33 PM, Mike Stump wrote:
On Friday, July 22, 2005, at 11:07 AM, Chris Lattner wrote:
I'm trying to determine (in target-independent code) what the
*minimum* target alignment of a type is. For example, on darwin,
double's are normally 4-byte aligned, but
On Jul 22, 2005, at 12:42 PM, Andrew Pinski wrote:
struct X { int A; double B; };
This is modified by things like ADJUST_FIELD_ALIGN and
ROUND_TYPE_ALIGN. As such, I don't think there is a way to get this
alignment in a target-independent way. Does that sound right?
You want the alignment
On Jul 22, 2005, at 1:14 PM, Richard Henderson wrote:
On Fri, Jul 22, 2005 at 11:30:40AM -0700, Chris Lattner wrote:
Understood. I'm just looking for the minimum type alignment without
user alignment. It appears that this is impossible to get from the
targets, due to the way the ta
On Mon, 25 Jul 2005, Daniel Berlin wrote:
On Mon, 2005-07-25 at 14:01 +0400, Vladimir A. Merzliakov wrote:
Hi all,
Are there any open-source(or free) front-end which translates C++ to C?
I could find some commercial things - Comeau, AT&T Cfront, etc., but
these have many limitations(especially,
Jeff Law wrote:
> I prefer consistency in warnings, regardless of optimization level.
I disagree and I think we have a significant contingency of
users that would disagree -- if optimizations allow us to avoid
false-positive warnings, then we should use that information to
avoid those false posi
On Wed, 2 Nov 2005, Jeffrey A Law wrote:
On Wed, 2005-11-02 at 12:01 -0600, Chris Lattner wrote:
[ ... big snip ... ]
For users like myself, I would really like to have an option to switch the
unused var warning to be emitted from the *front-end* where it works when
compiling with optimization
On Wed, 2 Nov 2005, Jeffrey A Law wrote:
Sure, running it as the first stage of the optimizers has the effect of
making it have the properties I desire, without requiring the front-ends
to duplicate the code. Such a feature would be great to have!
I think we've all agreed it's a good feature to
Bernhard R. Link wrote:
* Chris Lattner <[EMAIL PROTECTED]> [051102 19:28]:
Jeff Law wrote:
>> I prefer consistency in warnings, regardless of optimization level.
>I disagree and I think we have a significant contingency of
>users that would disagree
Jeff, I completely
Daniel Berlin Wrote:
> > It [LLVM] is proven to be stable, high-level enough to
> > perform any kind of needed optimization,
> This is not true, unfortunately. That's why it is called "low
level virtual machine".
> It doesn't have things we'd like to do high level optimizations
on, like
> d
Hi Everyone,
At the request of several members of the GCC community, I'm writing
this email to describe some of my short-term plans with GCC and
describe an alternative to the recent link-time optimization [1] and
code generator rewrite [2] proposals.
For those who are not familiar with m
Daniel Jacobowitz writes:
As describe above, we won't support every target that GCC currently
does. Three options are possible:
Chris tells me that an LLVM->GIMPLE translator wouldn't have target
dependencies. I'm not 100% sure I buy that, but I'll take it as given
for now (if not they shou
Richard Guenther writes:
I would propose to even think of doing only IPO at LLVM and go back to
gimple for the rest of the tree-ssa pipeline. At least that should be
possible. Would we get link-time optimization this way, or is the LLVM
link-time optimization architected differently?
Sure,
On Sat, 19 Nov 2005, Joseph S. Myers wrote:
On Fri, 18 Nov 2005, Chris Lattner wrote:
1. The build system is taught about C++ code.
With toplevel bootstrap this will bootstrap libstdc++ so that the compiler
ends up linked with the new libstdc++ not the (in general
ABI-incompatible) old one
Kenneth Zadeck writes:
This quickly becomes
difficult and messy, which is presumably why the link-time proposal
allows the linker to "give up" linking two translation units.
The reason for the complexity of the type system handling in our
proposal was motivated primarily by two concerns:
1)
On Sun, 20 Nov 2005, Steven Bosscher wrote:
On Saturday 19 November 2005 18:56, Chris Lattner wrote:
Only the Ada frontend seems to be in a state to maybe support direct
frontend IR to LLVM translation.
Sure, also maybe Fortran?
I wouldn't count on it...
Can you explain what you
On Sun, 20 Nov 2005, Steven Bosscher wrote:
Can you explain what you mean?
I mean it would take a complete re-write of the translation phase from
gfortran's native program representation to GENERIC trees. Even if it
is "quite possible" to make it write out LLVM directly, it would be a
huge job
On Tue, 22 Nov 2005, Joseph S. Myers wrote:
On Sat, 19 Nov 2005, Chris Lattner wrote:
This is a direct result of the representation that you are proposing to use
for IPA. LLVM is *always* capable of merging two translation units correctly,
So compilation options which change the semantics
On Tue, 22 Nov 2005, Daniel Jacobowitz wrote:
The initial impression I get is that LLVM involves starting from scratch.
I don't quite agree that this is necessary. One of the engineering
challenges we need to tackle is the requirement of keeping a fully
functional compiler *while* we improve its
On Tue, 22 Nov 2005, Steven Bosscher wrote:
On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
The initial impression I get is that LLVM involves starting from scratch.
I thought it would basically "only" replace the GIMPLE parts of the
compiler. That is,
FE --> GENERIC --> LLVM
On Tue, 22 Nov 2005, Benjamin Kosnik wrote:
Another minor nit is performance. Judging by SPEC, LLVM has some
performance problems. It's very good for floating point (a 9%
advantage over GCC), but GCC has a 24% advantage over LLVM 1.2 in
integer code. I'm sure that is fixable and I only have da
On Tue, 22 Nov 2005, Richard Henderson wrote:
On Tue, Nov 22, 2005 at 05:58:14PM +0100, Steven Bosscher wrote:
I thought it would basically "only" replace the GIMPLE parts of the
compiler. That is,
FE --> GENERIC --> LLVM--> RTL --> asm
(trees) (trees)
This is certain
On Tue, 22 Nov 2005, Benjamin Kosnik wrote:
Which is why i said "It's fine to say compile time performance of the
middle end portions ew may replace should be same or better".
And if you were to look right now, it's actually significantly better in
some cases :(
http://people.redhat.com/dnovill
I threw the current version of the patch up here:
http://nondot.org/sabre/llvm-gcc-4.0-patch.tar.gz
This is a patch vs the Apple branch as of a few weeks ago. The diff is in
gcc.patch.txt, the new files are included in the tarball.
Note, there are not enough caveats in the world to include w
On Tue, 23 Nov 2005, Gabriel Dos Reis wrote:
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
| > I will work with the GCC SC and FSF on that issue once the licensing
| > issue is addressed and we know LLVM is a viable option.
| >
| What purpose
On Tue, 22 Nov 2005, Diego Novillo wrote:
You will need to address two, potentially bigger, issues: license and
implementation language.
Over the last couple of years, there have been some half hearted attempts
at suggesting C++ as a new implementation language for GCC. I would
personally lov
On Wed, 23 Nov 2005, Diego Novillo wrote:
On Tuesday 22 November 2005 13:17, Benjamin Kosnik wrote:
What about compile-time performance?
Well, it's hard to say, I have not really used LLVM extensively. The only
real data I have is compile times for SPECint:
SPECint build times (sec
On Sun, 27 Nov 2005, Daniel Berlin wrote:
On Sun, 2005-11-27 at 11:58 -0800, Devang Patel wrote:
What makes you think implementing LTO from scratch is different here?
Here are the questions for LLVM as well as LTO folks. (To be fair,
1) Documentation
How well is the documentation so that _ne
On Wed, 23 Nov 2005, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
You will need to get University of Illinois and
past/present LLVM developers to assign the copyright over to the FSF.
Yes, you've claimed it's easy, but it needs to be done. Otherwise, we a
On Tue, 29 Nov 2005, Andrew Pinski wrote:
I threw the current version of the patch up here:
http://nondot.org/sabre/llvm-gcc-4.0-patch.tar.gz
A couple of comments.
getIntegerType is really badly. It seems better to use
the mode to detect the type.
Also maping 128bit fp type to {double, dou
On Dec 5, 2005, at 11:48 AM, Steven Bosscher wrote:
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
There is one advantage I see in the LTO design over LLVM's
design. In
particular, the LTO proposal envisions a file format that is
roughly at
the level of GIMPLE. Such a file format
On Dec 5, 2005, at 5:27 PM, Mark Mitchell wrote:
Steven Bosscher wrote:
IMVHO dumping for "export" and front-end tools and for the optimizers
should not be coupled like this. Iff we decide to dump trees, then I
would hope the dumper would dump GIMPLE only, not the full front end
and middle-end
On Dec 5, 2005, at 5:43 PM, Mark Mitchell wrote:
Chris Lattner wrote:
I totally agree with Steven on this one. It is *good* for the
representation hosting optimization to be different from the
representation you use to represent a program at source level.
The two
have very different goals
On Dec 6, 2005, at 4:35 PM, Rafael Ávila de Espíndola wrote:
On Tuesday 06 December 2005 19:19, Chris Lattner wrote:
This version of the patch has many bugs fixed and several rough
corners rounded off (for example, there are no more hard coded paths
in the makefiles anymore, and the llvm
On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote:
Additionally to the obstacles to adopt LLVM mentioned by Diego, I
named usage of C++ (although it has advantages too) and patents. LLVM
should be checked for usage of compiler patents. Gcc people avoided
many patents especially from Microsoft. We
On Dec 16, 2005, at 11:47 AM, Daniel Berlin wrote:
On Fri, 2005-12-16 at 11:27 -0800, Chris Lattner wrote:
On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote:
Additionally to the obstacles to adopt LLVM mentioned by Diego, I
named usage of C++ (although it has advantages too) and patents
> 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 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 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 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 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 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 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: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.
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 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'
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 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 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 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 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
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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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: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 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 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 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 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 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.
1 - 100 of 240 matches
Mail list logo
