I dunno, this seems like a thing you could better figure out by
trying
it and seeing where the problems are than by trying to anticipate
every single possible problem
(not that there should be no design, but that it would be better to
start with a design and iterate it than try to figure out per
On Jul 25, 2008, at 1:54 AM, Richard Guenther wrote:
Sure, typedefs in C/C++ seem clearly useless. I'm just curious how
you plan
to go about deciding whether things are useless in a more general
context.
How fine of a granularity do you intend to inspect bits? Trees
have lots
of random stu
On Jul 25, 2008, at 9:20 AM, Michael Matz wrote:
That is one example of extremely important information which requires
pulling in almost the entire source type system.
But not all the trees implementing those types (and all the
cross-references between those, that are important for parsing but
On Aug 1, 2008, at 7:53 AM, Mark Mitchell wrote:
My concern is that the path we're heading towards is:
...
2. Middle-end builds call graphs, etc., and throws out 99.5% of the
functions and debug info, after deciding it's not needed. (Note,
for example, that mangled names are typically not
On Aug 12, 2008, at 10:55 AM, Tom Tromey wrote:
"Tom" == Tom Quarendon <[EMAIL PROTECTED]> writes:
Tom> I imagine that GCJ has do to this ind of thing?
FWIW, libgcj does not include a JIT compiler.
So, no solution there, sorry.
It's OT for this list, but the LLVM JIT can generate DWARF EH
On Aug 13, 2008, at 12:16 PM, Joseph S. Myers wrote:
On Wed, 13 Aug 2008, Aldy Hernandez wrote:
It seems to me that the only approach here would be to provide caret
diagnostics, because reconstructing the original sources from GENERIC
seems like a loosing proposition.
In some cases the only
On Aug 14, 2008, at 8:47 AM, Joseph S. Myers wrote:
On Thu, 14 Aug 2008, Robert Dewar wrote:
BTW, I am all in favor of caret output, it's not the default in
gnat, the default is more like the C default, but -gnatv gives
output like:
And I'd hope we could keep things that way for both C and
D) Printing Ranges. This requires:
*) Printing accurate column information. Similar to (B) above.
*) A location(s) -> source strings interface and machinery. Similar
to (A.3) above.
Ranges also require some way to get the end of a token (in addition to
its beginning). For example,
On Sep 19, 2008, at 3:25 PM, Ian Lance Taylor wrote:
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
I am much more worried about passes and plugins (and I am very
surprised to be almost the only one mentioning passes in plugin
discussions). I feel it is a major issue (not a matter of coding
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
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
iPho
On Sep 24, 2008, at 8:02 AM, Duncan Sands wrote:
However if GPLv3 is such a huge issue
at Apple, it does make one wonder if llvm will ever see a gcc
front-end newer
than the current 4.2 one.
The LLVM folks are writing a new frontend anyhow. In the future they
presumably plan to stop using
On Sep 24, 2008, at 10:01 AM, Chris Lattner wrote:
requirements on that code.
I'm not speaking for Apple here, and I am not a lawyer. However,
the last draft of the runtime library exception clause (which is
quite old by now)
I'm sorry, to be clear, I meant "the last dr
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
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 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 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 May 11, 2007, at 5:28 PM, Mark Mitchell wrote:
Bill Wendling wrote:
Andrew Pinski wasn't able to reproduce the link error on Linux,
and I've
only seen it on Darwin. However, as Chris Lattner pointed out, this
indicates a fairly serious problem (which shows up even on the Linux
Hi Everyone,
As an FYI, LLVM 2.0 was released on Wednesday. This is a critical
release for us, with many new features, optimizer improvements, and
compile-time speedups. Among other things, this release add support
for many missing GCC extensions, so we can now build things like
mozilla
On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote:
Bill Wendling wrote:
On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
Consider:
struct __attribute__((vsibility ("hidden"))) S {
void __declspec(dllimport) f();
};
At present, we give "f" hidden visibility. That seems odd since the
On Jun 15, 2007, at 8:08 PM, J.C. Pizarro wrote:
For performance and simplicity, i show this summary
JC, I appreciate your enthusiasm, but I don't think that this is the
right forum for discussions about LLVM vs GCC. If you'd like to
discuss LLVM, please take it to an LLVM-related mailin
On Jun 15, 2007, at 4:47 PM, Mark Mitchell wrote:
Chris Lattner wrote:
This construct seems like it should be rejected by the C++ front-end.
The source is making two contradictory claims: the struct is not
visible
outside this library, but part of it is implemented outside of it.
I don&#
On Jun 16, 2007, at 11:52 AM, Mark Mitchell wrote:
Daniel Jacobowitz wrote:
This doesn't make a lick of sense to me. If the type is hidden, how
on earth can it get a member function _of that type_ from another
library? That library would, by definition, have to have a type of
the same name.
On Jun 17, 2007, at 6:40 PM, Dave Korn wrote:
On 17 June 2007 18:17, Ross Ridge wrote:
Daniel Jacobowitz writes:
The minimum I'd want to accept this code would be a complete and
useful
example in the manual; since Mark and Danny say this happens a lot
on Windows
I don't understand how th
That is a limited view of things based on the current
implementation of
GCC. When future developments (e.g. LTO) occur, this will change:
types
certainly do live in object files.
I don't see how LTO changes this. Yes, type definitions will
appear in
one or more object files. But, the i
On Jun 19, 2007, at 7:49 AM, Richard Earnshaw wrote:
On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
I suspect that the realview compiler accepts
this as an oversight or a bug, not as an intentional feature.
Let's ask.
Richard E., is the fact that RealView 3.0SP1 accepts:
class _
On Jun 22, 2007, at 1:41 AM, Sergei Organov wrote:
Herman Geza <[EMAIL PROTECTED]> writes:
[...]
What is the correct way to do this:
void setNaN(float &v) {
reinterpret_cast(v) = 0x7f81;
}
without a type-prunning warning? I cannot use the union trick here
Why? Won't the foll
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour, and it
helps programmers and helps existing code. Who does it hurt to permit
this extension? Who does it help to forbid this extension?
Aren't builtins the designated way to ac
On Aug 24, 2007, at 8:37 AM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour,
and it
helps programmers and helps existing code. Who does it hurt to
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
Hi,
when trying to analyse dynamically allocated objects in C++, I came
across the need to identify results of the new operator (at least the
non-overridden standard one) as malloc-allocated. The cleanest
approach would probably be t
:53 PM, Martin Jambor wrote:
[ giving operator new the malloc property ]
On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
It is unclear whether this is safe. Nothing in the standard AFAIK
requires the operator new be implemented in terms of malloc, and
users are allowed to overr
Hi All,
If you're interested, LLVM 2.1 was recently released. You can read
about it here:
http://llvm.org/releases/2.1/docs/ReleaseNotes.html#whatsnew
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2007-September/
24.html
... and get it here:
http://llvm.org/releases/download.html#2
On Oct 20, 2007, at 4:48 AM, Steven Bosscher wrote:
I hope the list is useful for someone who wishes to improve GCC's
optimizations for code size.
Is there a meta bug for code size optimizations? If not, that would
be a good way to centralize the various ideas you have.
-Chris
On Nov 7, 2007, at 9:28 AM, Robert Dewar wrote:
Tom Tromey wrote:
First, aren't we already in this situation? There are at least 2
compilers out there that re-use parts of GCC by serializing trees and
then reading them into a different back end.
It's not obvious to me that this is consistent
On Nov 24, 2007, at 1:54 PM, Alexandre Oliva wrote:
On Nov 16, 2007, Basile STARYNKEVITCH <[EMAIL PROTECTED]>
wrote:
For example, the "simple" plugin mechanism many people have
implicitly
in mind is just: something give you the ability to call a dlsymed
function inside a dlopened plugin a
On Dec 12, 2007, at 3:41 PM, Harvey Harrison wrote:
In terms of implementation, we will likely use the LTO branch as a
basis. Many of the features we will need are already being
implemented
in the branch, so we will keep helping with that implementation.
I'm curious how this interacts/compl
On Dec 13, 2007, at 5:32 AM, Diego Novillo wrote:
On 12/12/07 6:41 PM, Harvey Harrison wrote:
Any pointers to where that discussion ended up?
There was some discussion about merging LLVM and GCC a couple of
years back but nothing concrete came out of it.
The concrete thing that came out of
On Dec 19, 2007, at 2:19 PM, Tim Josling wrote:
...
http://gcc.gnu.org/projects/lto/lto.pdf
...
Was there any more about this?
I have restarted work on my COBOL front end. Based on my previous
experiences writing a GCC front end I want to have as little code as
possible in the same process
On Dec 21, 2007, at 4:09 PM, Andrew Pinski wrote:
On 12/21/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 21 Dec 2007 16:02:38 -0800, Ian Lance Taylor <[EMAIL PROTECTED]>
wrote:
Like it or not, the large size of debug information is a serious
issue
for many people.
Link times are hurt b
On Dec 25, 2007, at 5:02 PM, Vladimir N. Makarov wrote:
Here is mine benchmarking of the current LTO branch on 2.66Ghz Core2
under RHEL 5 in 64- and 32-bits mode. The vortex violates type
aliasing rules, therefore it should be compiled with
-fno-strict-aliasing. Perlbmk crashed in tree.c::bui
201 - 240 of 240 matches
Mail list logo
