What version linker? In particular, do you have the fix for PR12975?
It seems to work with gold and the LLVM plugin. I have added a test to
make sure it stays that way:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140804/229493.html
Cheers,
Rafael
What about instead of our current odd way of identifying LTO objects
simply add a special ELF note telling the linker the plugin to use?
.note._linker_plugin '/./libltoplugin.so'
that way the linker should try 1) loading that plugin, 2) register the
specific object with that plugin.
On 11 February 2014 12:28, Renato Golin renato.go...@linaro.org wrote:
Now copying Rafael, which can give us some more insight on the LLVM LTO side.
Thanks.
On 11 February 2014 09:55, Renato Golin renato.go...@linaro.org wrote:
Hi Jan,
I think this is a very good example where we could all
My reading of bfd/plugin.c is that it basically walks the directory and looks
for first plugin that returns OK for onload. (that is always the case for
GCC/LLVM plugins). So if I instlal GCC and llvm plugin there it will
depend who will end up being first and only that plugin will be used.
not well-formed C++, for it violates the one-definition rule in that it
*lacks* a definition for the virtual member function foo::~foo(). Does
it make any difference if you add a definition?
Unfortunately no. Replacing the declaration with an inline definition
produces a copy of it in
Yes, this indeed looks like (most probably my) bug in the constant folding
code that now uses extern vtables. I will fix it. So we can not take
comdat linkage decl from external vtable when we no longer have its body
around, right?
Sounds about the fix John was describing, yes. You can
Richi asked me to also report a gcc bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
But that's pervasively true in C++ — the linker has to eliminate duplicates
all the time. Idiomatic C++ code ends up plunking down hundreds, if
not thousands, of inline functions in every single
There's no for a long time here. The ABI does not allow us to emit these
symbols with non-coalescing linkage. We're not going to break ABI
just because people didn't consider a particular code pattern when they
hacked in devirtualization through external v-tables.
If we take the ABI to mean
Note1: I am not subscribed to the gcc list, please use reply-all.
Note2: I think the clang list is moderated for the first post, but it
is usually really fast. Sorry about that.
I recently implemented an optimization in LLVM to hide symbols that
the we know are available in every DSO that uses
it unconditionally if it does, is that
correct?
On 17 June 2012 23:15, Rafael Espíndola rafael.espind...@gmail.com wrote:
I recently upgraded to fedora 17 and now found out that libstdc++ 4.7
requires c++ constructors to be handled with .init_array instead of
.ctors. I have not produced a self
The GNU linker has support to merge .ctor's into init_array. Does the
gold linker have the same feature? This seems more like the real fix
rather than just hacking around the issue.
Recent version have it. I found the bug when using gold 2.21 which
doesn't. What seems to happen is:
* In an
This has a long and complicated history. I tried to explain some of that here:
http://gcc.gnu.org/ml/gcc-bugs/2010-12/msg01493.html
I wasn't part of the GCC community at the time, but I think that
.ctors was originally used instead of .init or .init_array precisely
because the order of
Did I miss anything? What are the relative advantages of each
solutions? Do you think that I overlooked other options? Would using
an exiting virtual machine be a good option? Except for Nice, this
option doesn't seem to be popular; there must be a catch.
You might want to have a look at
Also, I referred to some tutorials and articles in the net about
writing gcc front-end. And here are they:
1. http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/Print_version
2. http://www.faqs.org/docs/Linux-HOWTO/GCC-Frontend-HOWTO.html (old)
3. http://www.linuxjournal.com/article/7884
I thought Chris was working on updating LLVM to gcc head.
It will be done, but it is not a priority and I need the ARM bits
sooner. Anyway, he will have 5 or 6 patches less to port :-)
Paul
Best Regards,
Rafael
I am working on a ARM backend for LLVM. The problemis that llvm-gcc is
currently based on gcc 4.0 and I would like to use the new EABI.
I have started to back port the ABI from 4.1 to 4.0. The first attempt
was to just copy the gcc/config/arm directory and try to fix build
errors. This proved
Compiling with --disable-bootstrap and using the resulting compiler to
bootstrap gcc solved the problem.
Rafael
Do we support bootstraping on ARM? I am trying to bootstrap inside a
scratchbox and currently I am having the following error on trunk and
the 4.2 branch:
../branch-4.2/configure --enable-checking
reduced test case:
--
typedef void (*personality_routine) (
void *);
typedef struct
{
unsigned vfp[63];
} phase1_vrs;
void
__gnu_Unwind_RaiseException (unsigned * ucbp);
void
__gnu_Unwind_RaiseException (unsigned *
I have an approved patch that factors code that is common to all
builtin_function implementations
(http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00195.html,
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01499.html).
I have just updated and tested it. Is this a good time to commit?
Best Regards,
I wish to know if there exists any plugin that translate
these intermediate format into C sources. I intent to modify these
intermediate formats and retranslate then into C source to anylise the
trasnsformations.
For reading a C like representation you can use -fdump-tree-*. It
might have the
On 8/21/06, Cosmin Rentea [EMAIL PROTECTED] wrote:
Hi,
I would like to ask whose approval is needed to start developing a GCC
front-end for the abstract test language TTCN-3.
You don't need an approval for that. See the COPYING file distributed
with GCC for the details.
More information
On 8/8/06, Petr Machata [EMAIL PROTECTED] wrote:
Hi list!
I picked a diploma thesis assignment to implement a gcc frontend, and
document the process thoroughly. I chose Algol 60 as the language to
implement. There has already been one attempt to do Algol 60 frontend,
but it probably died:
because that is what the language standard says.
In general, the difference between two global pointers is something
known only to the linker -- too late to evaluate as constant
expression.
In the particular case of two static functions or two static global
pointers, it is possible for the
This isn't possible with global symbols in a DSO because some other
DSO (or indeed the exe) might also define one of the symbols.
Not with hidden symbols. Sorry, I forgot to mention that.
Andrew.
Rafael
Use prelinking. That works for all relocation types, and doesn't
require additional coding.
It helps, but I still have 10639 relocations during a import gtk in
python. The relative table also has the advantage that it is constant
and can be shared.
Ian
Rafael
I am trying to build a table with offsets of global pointers from a
given pointer:
void *fs[] = {f1 - f1, f2 - f1};
where f1 and f2 are functions.
GCC is able to figure out that (f1 - f1) is 0, but says initializer
element is not constant when trying to compute (f2 - f1).
It is possible to
What about Ada ? Will things still work after your change ?
It would seem cleaner (if not mandatory) to take all languages into account
in your change.
Only now I realize that I answered in private :-(
The install-common target works as before, so the ada front end is not
affected. The proposed
Some people call this uninlining. I've also heard the term
procedural abstraction. The generalization is to identify common code
fragments that can be turned into functions. Then, replace the users of
the common code with function calls.
Is this the same as Code Factoring?
I have a patch that factors code common to all builtin_function
implementations. It is approved for trunk when we get to stage1.
Are the developers involved in the lto branch interested in this
patch? If so, I can port it.
Best Regards,
Rafael
The attached patch moves the basic installation of the compiler
drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in
has only to inform the driver's name.
Additional setup like setting the c++ - g++ links remains in the Make-lang.in
Ok for trunk when stage1 starts?
:ADDPATCH
The attached patch duplicates convert_and_check into the c++ front
end. I would like to include it to be able to remove the convert
callback latter on. Duplicating convert_and_check makes it is easy to
use cxx_convert in the c++ front end and c_convert in the c front end.
Thanks,
Rafael
You know, I've always wondered why there wasn't a lisp-family front end
for GCC, the roots of GNU and RMS being where they are (and didn't RMS
promise way back when to make lisp suitable for unix systems
programming?). I'm just not connected enough to the lisp world to know
the answer I
On 3/29/06, Dustin Laurence [EMAIL PROTECTED] wrote:
I'm fiddling around with a GCC 4 front-end tutorial that would be more
detailed and hands-on than anything I've found so far on the web. It's
a bit like the blind leading the blind, but it makes me learn better and
while I'm learning it I
Using libmudflap to test a program that uses libxml2, I found that if
a program access a constant pointer in a non-instrumented library,
mudflap thinks that a read violation has occurred.
A simple test that illustrates this is:
a.c:
-
char *p = abc;
Did the compiler give you a warning about inability to track the
lifetime of p? It should have.
No. Not even with -Wall -O2.
gcc -v:
gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
- FChE
Thanks,
Rafael
There is a lot of duplicated code in the hooks implementation in the
various front ends. I am trying to factor it a little bit.
I started with the builtin_function hook. Doing a mostly mechanical
work I came up with the attached patch. The patch doesn't touches the
C++ front end because it is
Hey Paolo thanx a lot.I got the info I required.
Can u mention any links that i can use as a reference to understand the dump
output of -fdump-tree-original-raw as AST?
read
GENERIC and GIMPLE: A new tree representation for entire functions
at
The new apple branch appers to work in gnu/linux/x86. An update of
Chirs' patch to the new version of the branch is available at
gcc-llvm-apple-local-200502-branch-107672.patch.bz2.
It compiles xgcc but this in turn fails to compile crtbegin.o:
plus_expr 0xb7b89aa0
type pointer_type
I found that the patch 99839:99840 introduces some function lowering
and in doing so breaks the LLVM patch. A patch for trunk version 99839
is in http://www.las.ic.unicamp.br/~espindola/gcc-llvm-trunk-99839.patch.bz2.
Chris, are you working on this or should I give it a try?
Rafael
On 11/22/05, Scott Robert Ladd [EMAIL PROTECTED] wrote:
I've been quietly watching the conversation, largely as an interested
user as opposed to a GCC developer. One of my concerns lies with:
I have worked on some toy front ends, so I think that I am a kind of a
user also :)
GENERIC -
I am currently bootstraping the trunk with the patch applied.
bootstraped and tested...
Thanks,
Rafael
On 11/22/05, Chris Lattner [EMAIL PROTECTED] wrote:
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.
apple-local-200502-branch rev 104970 I think.
Rafael
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 architecture.
I don't think that it
Why does treelang defines signedness of char with flag_signed_char?
IMHO it would be better if it had a fixed definition of it. I have
tried to use
build_common_tree_nodes (true, false);
It bootstraped and tested (make check-treelang).
Thanks,
Rafael
2005-10-25 Rafael Ávila de Espíndola
The cases you have to look at are the ones with move-if-change. You
have to make sure that if the file does not change, none of the
dependencies are considered to have changed.
For example in
multilib.h: s-mlib; @true
s-mlib: $(srcdir)/genmultilib Makefile
...
$(SHELL)
On 9/13/05, Mike Stump [EMAIL PROTECTED] wrote:
If you ask gcc, you find:
mrs $ grep 'int\* ' *.c | wc -l
4
mrs $ grep 'int \*' *.c | wc -l
369
pretty clear to me.
In treelang/parse.y all variables named tok (and some others) are
declared with
struct prod_token_parm_item*
It should be part of the middle end. A kind of dump-option.
much better :)
take a look at
tree-dump.c:dump_function
Nico
Rafael
On 6/22/05, nico [EMAIL PROTECTED] wrote:
Hi,
if I want to add some source to the gcc, what do I have to do?
It depends where do you want to link the file. If is going into a
front end for a language other the c then it must go in
gcc/lang
I am not very familiar with the global structure of
On 6/16/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello~ every one :)
I'm a new guy in gcc mailing list
I've been studying gcc for 2 months.
I read GNU compiler collection internals (for GCC 3.5.0?),
and I also trace the source code for target-mips.
My problem is there are so
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES
[What is the name of the program or package you're contributing to?]
GCC, the GNU Compiler Collection
[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]
No
I am doing some work on a frontend for gcc. In the process I expect to
clean up treelang a little bit. Could you send me the relevant forms?
Thanks.
Rafael Ávila de Espíndola
52 matches
Mail list logo
