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

> 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

Re: [LLVMdev] Zero-cost toolchain standardization process

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

Re: clang vs free software

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

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

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

Re: RFC - Remove support for PCH post 4.8

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

Re: RFC - Remove support for PCH post 4.8

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

Re: RFC - Remove support for PCH post 4.8

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

Re: RFC - Remove support for PCH post 4.8

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

Re: RFC - Remove support for PCH post 4.8

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

Re: RFC - Remove support for PCH post 4.8

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

Re: Backtrace library [1/3]

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

Re: Backtrace library [1/3]

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

Re: RFC: -Wall by default

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

Re: Dealing with compilers that pretend to be GCC

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,

Re: Dealing with compilers that pretend to be GCC

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

Re: Dealing with compilers that pretend to be GCC

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

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

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

Re: Dealing with compilers that pretend to be GCC

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

Re: Dealing with compilers that pretend to be GCC

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

Re: Vector shuffling

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

Re: Vector shuffling

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

Re: darwin LTO broken under Xcode 3.2.6/4.0

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

Re: darwin LTO broken under Xcode 3.2.6/4.0

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

Re: darwin LTO broken under Xcode 3.2.6/4.0

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

Re: darwin LTO broken under Xcode 3.2.6/4.0

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

Re: darwin LTO broken under Xcode 3.2.6/4.0

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

Re: darwin LTO broken under Xcode 3.2.6/4.0

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

Re: operator new[] overflow (PR 19351)

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: ##

Re: operator new[] overflow (PR 19351)

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

Re: operator new[] overflow (PR 19351)

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

Re: operator new[] overflow (PR 19351)

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

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

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

LLVM 2.8 Release

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

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

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

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

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

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

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

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

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 ?

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

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

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

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

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

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

Re: Edit-and-continue

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

Re: Scheduling x86 dispatch windows

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

LLVM 2.7 Released

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

Re: Why not contribute? (to GCC)

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

Re: Why not contribute? (to GCC)

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

Re: Why not contribute? (to GCC)

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

Re: Why not contribute? (to GCC)

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

Re: Why not contribute? (to GCC)

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

Re: Why not contribute? (to GCC)

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

Re: Why not contribute? (to GCC)

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.

Re: Why not contribute? (to GCC)

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

Re: Why not contribute? (to GCC)

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

Re: Code assistance with GCC

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

Re: Code assistance with GCC

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,

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

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:

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

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

Re: Code assistance with GCC

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

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

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

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

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

Re: RFC: c++ diagnostics

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

Re: RFC: c++ diagnostics

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:

Re: RFC: c++ diagnostics

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

Re: RFC: c++ diagnostics

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,

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

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

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

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

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

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

LLVM 2.6 Release

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

Re: apple blocks extension

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

Re: apple blocks extension

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

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

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

Re: LLVM as a gcc plugin?

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

Re: LLVM as a gcc plugin?

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]

Re: LLVM as a gcc plugin?

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

Re: LLVM as a gcc plugin?

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

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

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

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

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

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

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

Re: format argument does not have string type

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

Re: Diagnostic Messaging Suggestion

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

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

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?

Re: GCC + libJIT instead of LLVM

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

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

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

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

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

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

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

LLVM 2.5 Release

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 ?

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

Re: GCC OpenCL ?

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

Re: New GCC Runtime Library Exception

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

Re: RFC: case insensitive for #include

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

Re: Request for testing/help for the LTO branch

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.

Re: RFC: case insensitive for #include

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

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

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

Re: Request for testing/help for the LTO branch

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

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

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

LLVM 2.4

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

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

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

Re: Apple, iPhone, and GPLv3 troubles

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

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

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

Re: Apple, iPhone, and GPLv3 troubles

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

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

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

  1   2   3   >