> 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 plugi
> 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.
On 11 February 2014 12:28, Renato Golin 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 wrote:
>> Hi Jan,
>>
>> I think this is a very good example where we could all collaborate
>> (including binutils).
I
> 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 p
> 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 undef
> 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"
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 tran
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 t
> 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
> 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 a
y and uses it unconditionally if it does, is that
correct?
On 17 June 2012 23:15, Rafael Espíndola 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 cont
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 the
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 (overv
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 har
Compiling with --disable-bootstrap and using the resulting compiler to
bootstrap gcc solved the problem.
Rafael
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 * uc
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 --disable-threads
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,
R
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 inf
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 a
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:
ht
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
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
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 compi
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 s
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?
http://gcc.gnu.
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 bu
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
2006-04-0
> 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 i
> 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
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";
-
The gcc documentation says:
Use `-fmudflapth' instead of `-fmudflap' to compile and to link if
your program is multi-threaded.
but the mudflap gate is
static bool
gate_mudflap (void)
{
return flag_mudflap != 0;
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 orga
> 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
http://zenii.linux.org.uk/~ajh/gcc/gccsu
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
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
sizes-gim
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 :)
> GENERI
> 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 inv
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 <[EMA
> 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
> ...
> $(SHE
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_p
I have seen both in gcc. I have found that "type* variable" is
preferred in C++ code but I haven't found any guidelines for C code.
Thanks,
Rafael
> 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/
I am not very familiar with the global structure of g
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
52 matches
Mail list logo
