shrink-wrap leads to ICE at dwarf2cfi.c
Hi,
I am enabling shrink-wrap for ARM. But get lots of ICE during make
check for THUMB2:
internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2227.
Shrink-wrap allows jumps in epilogues. It will generate a common
simple_return block as the destination for multi-branches. More
details at http://old.nabble.com/Shrink-wrapping%3A-Introduction-to31220423.html
With this optimization, it might generate code segment like:
...
bpl .L9
...
push{r4}
...
//NOTE_INSN_EPILOGUE_BEG
ldr r4, [sp], #4
.L9:
bx lr
In function maybe_record_trace_start, there is a check:
/* We ought to have the same state incoming to a given trace no
matter how we arrive at the trace. Anything else means we've
got some kind of optimization error. */
gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row));
The check will fail. Here are the results for cur_row and ti->beg_row
{cfa = {offset = 0, base_offset = 0, reg = 13, indirect = 0, in_use =
0}, cfa_cfi = 0x0, reg_save = 0x0}
{cfa = {offset = 4, base_offset = 0, reg = 13, indirect = 0, in_use =
0}, cfa_cfi = 0x0, reg_save = 0x7726ab70}
The fix mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50833
is just to skip the optimization for -O0. It does not help on -O2/-O3.
All the cases pass if I disable the gcc_checking_assert.
1) Is the code segment the expected result of shrink-wrap? If not,
what's the correct one look like?
2) If the code is expected, does the gcc_checking_assert make sense?
Thanks!
-Zhenqiang
Re: gcc-c-api
On Fri, Sep 7, 2012 at 6:31 PM, David Malcolm wrote: > After a hiatus, I've restarted work on an API for GCC plugins - > specifically, a C API (given that my plugin is written in C, I have more > interest in that than a C++ API). > > BTW, how many other GCC plugins are written in C? > > It's still a work-in-progress, but can be seen here: > > http://git.fedorahosted.org/cgit/gcc-python-plugin.git/tree/gcc-c-api?h=proposed-plugin-api > > i.e. within the "proposed-plugin-api" branch of the gcc-python-plugin, > within the "gcc-c-api" subdirectory. I've been gradually porting the > python plugin to use the proposed API, rather than poking at GCC's > insides itself. I've also tried to follow the GNU coding conventions > within that directory (the plugin itself follows the Python coding > conventions). I haven't done the copyright assignment paperwork yet. > > There are no explicit test cases yet, though the python plugin's test > suite passes, exercising the code indirectly. > > The API has a build-time dependency on Python (parts of it are > autogenerated, and Python is my natural choice for this work). There > isn't a runtime dep though. > > I started thinking about trying to create a patch to merge the API into > the GCC source tree, but I'm running into some high-level issues: how is > a plugin meant to actually use this API without requiring the use of an > in-development version of GCC? Similarly, as a plugin author, I want my > plugin to be usable against GCC 4.6 onwards, but GCC's internal APIs are > gradually changing. I see a lot of #ifs in my future, and it makes > sense to try to isolate the compatibility shims in one place, rather > than having every plugin author maintain them. > > Given that, it's most useful, I think, if the API code can somehow be > used independently of GCC: perhaps it's more of a compatibility shim > that hides the differences between GCC versions (e.g. C vs C++ name > mangling, C++ internals in 4.8 onwards etc) and provides a stable ABI > (that way you only have to recompile the API implementation when > recompilng GCC: all plugins built against the API should remain > compatible - that's the goal, after all). > > I'm not sure exactly how this is to be structured: external project vs > internal to gcc's source tree, but given that this is a non-trivial > amount of code and that I want it to support gcc 4.6, perhaps external > to the gcc source tree is the way to go. > > Thoughts? Micha was also working on the proposed introspection API, I blame him for not posting anything about this despite it's being "ready" since a few months... Richard. > Hope this is helpful > Dave >
Hello, What's the status of live range shrink in GCC
Hi, I digged into gcc mail archive and found there are several threads discussing about live range shrink, like: http://gcc.gnu.org/ml/gcc/2009-04/msg00248.html and http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00188.html In these messages many people showed interests in LRS, in or out of sched1 pass. I am curious about the status now and have following questions: 1. Does sched-pressure patch Vlad worked is the LRS we mentioned in the message? 2. If the answer is no, are there still someone want to do this in sched1? Or as Vlad once mentioned that we should implement LRS in another pass along with register re-materialization? 3. What's the status/expectation of LRS now? I didn't follow the message on this topic before, so please forgive if I have missed some important updates about this. Thanks very much. -- Best Regards.
Re: gcc-c-api
Hi, On Mon, 10 Sep 2012, Richard Guenther wrote: > > Thoughts? > > Micha was also working on the proposed introspection API, I blame him > for not posting anything about this despite it's being "ready" since a > few months... He. I didn't yet come to make the changes about operand inspectors since your last comments, so it's again unready :-) Ciao, Michael.
Re: error when building trunk rev. 190799
Hi, well, those failures are caused by -Werror switch. You should turn it off. Nevertheless there is already a bug report about this. See bug 53912 with title "[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32" Regards, Kai
C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
Hi, I have put in three patches on the 29th of August, but have not heard any real feedback on them :- [PATCH] Remove dependency of cp/cp-lang.c on cp/parser.h http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02010.html [PATCH] limited C++ parsing support for gengtype http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02016.html [PATCH] C++'ization of cp/parser.c/h http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02018.html This last patch possibly needs freshening, but all were tested and tested with the GCC testsuite. Thanks, Aaron
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
On Mon, Sep 10, 2012 at 8:23 AM, Aaron Gray wrote: > Hi, > > I have put in three patches on the 29th of August, but have not heard > any real feedback on them :- [...] > [PATCH] C++'ization of cp/parser.c/h > > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02018.html > > > This last patch possibly needs freshening, but all were tested and > tested with the GCC testsuite. You did receive a real feedback on the last patch. -- Gaby
Re: Request for Joining GCC Development Team
On 2012-09-08 15:44 , Kamran Amini wrote: Hello GCC guys I am really interested to be a part of GCC development team, specially G++ and C++11. In addition to what Basile recommended, I would suggest visiting http://gcc.gnu.org/wiki/GettingStarted. It contain several pointers to documents to help you get started. Diego.
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
On Mon, Sep 10, 2012 at 9:23 AM, Aaron Gray wrote: > Hi, > > I have put in three patches on the 29th of August, but have not heard > any real feedback on them :- > > > [PATCH] Remove dependency of cp/cp-lang.c on cp/parser.h > > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02010.html I will review this one, but I need to confirm that you have the proper FSF paperwork in order. I will defer to the C++ FE maintainers to handle the parser patches. Diego.
Re: gcc-c-api
On Mon, 2012-09-10 at 13:54 +0200, Michael Matz wrote: > Hi, > > On Mon, 10 Sep 2012, Richard Guenther wrote: > > > > Thoughts? > > > > Micha was also working on the proposed introspection API, I blame him > > for not posting anything about this despite it's being "ready" since a > > few months... > > He. I didn't yet come to make the changes about operand inspectors since > your last comments, so it's again unready :-) Micha: I'm very interested in seeing your code. Is it possible for you to post your work-in-progress code somewhere? I know that you don't feel it's ready for committing, but I would find it helpful - I'm interested in understanding the general approach, rather than seeing completeness or perfection. In particular, as the maintainer of the gcc-python-plugin I want something that will make my life easier. By that I mean: something that will make it easier to keep my plugin compatible against "as many gcc versions as possible" (which currently means 4.6 and 4.7, but I want to add 4.8 and so on), and minimize the amount of recompiling I have to do over ABI issues within a GCC release. My plugin is currently implemented in C (requiring C++ would be a pain for me, but would be doable, I think). Hope this makes sense - thanks! Dave
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
[ I am adding back GCC mailing list in the CC: as this would be useful for other contributors. ] On Mon, Sep 10, 2012 at 9:42 AM, Aaron Gray wrote: > On 10 September 2012 15:25, Gabriel Dos Reis > wrote: >> >> On Mon, Sep 10, 2012 at 8:59 AM, Aaron Gray >> wrote: >> > On 10 September 2012 14:35, Gabriel Dos Reis >> > >> > wrote: >> >> >> >> On Mon, Sep 10, 2012 at 8:23 AM, Aaron Gray >> >> >> >> wrote: >> >> > Hi, >> >> > >> >> > I have put in three patches on the 29th of August, but have not heard >> >> > any real feedback on them :- >> >> [...] >> >> > [PATCH] C++'ization of cp/parser.c/h >> >> > >> >> > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02018.html >> >> > >> >> > >> >> > This last patch possibly needs freshening, but all were tested and >> >> > tested with the GCC testsuite. >> >> >> >> You did receive a real feedback on the last patch. >> > >> > >> > Gaby, >> > >> > In reply, I was trying to do the first phase of a set of incremental >> > changes >> > towards normalizing the C++ frontend. >> > >> > Having looked at the complexity of parsing C++ and the complexity and >> > pragmatics of the semantics and the complexity of the GCC C++ >> > "middleend" >> > code and know it to a degree then to have something working keep it >> > working >> > seems the best bet to me. >> > >> > So the interfaces can be made distinct and normalized while keeping the >> > code >> > running and passing the testsuite. Once the interfaces are distinct more >> > radical changes can be made. >> > >> > Just my 2cents, >> > >> > Aaron >> > >> >> Aaron, >> >> I am not sure I understand what you are saying. >> The patch I commented on was *radical* change from the current state, and >> there >> is no answer to why you needed to make such a radical change, > > > As I understand things we are C++'izing the GCC C++ frontend ? > > And encapsulation and class'ization seems to be the first step in doing that > I would have thought ? It is not clear what the benefit is to move existing perfectly working internal non-member functions to being member functions a huge struct. Encapsulation does not necessarily mean that all functions have to be member functions or that all data type definitions have to reside in a .h file. In fact, I would argue that the patch you posted reduced encapsulation and abstraction, as opposed to increasing it. Datatypes and member functions that have no business of being exposed to the entire world are now made public. > My changes are orthogonal to the original code. No, they are not -- hence the comments. > All I have done is create > classes out of the cp_lexer_* and cp_parser_* functions and moved a few > statics into the classes where it was logical and where there were no weird > dependencies stopping that being done. You did not provide a rationale of why it was logical to move those functions as you did. The comments I made looked at the heart of the changes you made. -- Gaby
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
On 09/10/2012 04:53 PM, Gabriel Dos Reis wrote: It is not clear what the benefit is to move existing perfectly working internal non-member functions to being member functions a huge struct. I did this with cxx_eval_constant_expression and the functions it uses internally. The advantage is that you do not have to thread manually all the state arguments, and it is trivial to add additional state to pass around. You could also do this with an explicit pointer-to-context-struct parameter that's passed around (and that version of the patch I posted), but the class-based approached seems nicer to me. -- Florian Weimer / Red Hat Product Security Team
Re: error when building trunk rev. 190799
2012/9/10 Kai Tietz: > Hi, > > well, those failures are caused by -Werror switch. You should turn it > off. You mean '--disable-werror'? If so, then I use this option. > Nevertheless there is already a bug report about this. See bug > 53912 with title "[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap > fails using default c++ mode in stage 2 and 3 for native > x86_64-w64-mingw32" Thank you! -- Regards, niXman ___ Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows: http://sourceforge.net/projects/mingwbuilds/
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
On Mon, Sep 10, 2012 at 10:01 AM, Florian Weimer wrote: > On 09/10/2012 04:53 PM, Gabriel Dos Reis wrote: > >> It is not clear what the benefit is to move existing perfectly working >> internal non-member functions to being member functions a huge struct. > > > I did this with cxx_eval_constant_expression and the functions it uses > internally. The advantage is that you do not have to thread manually all > the state arguments, and it is trivial to add additional state to pass > around. Florian, I was not making a blanket statement in the abstract. Rather, I was commenting on the specific patch that Aaron posted. That cannot possibly be called "encapsulation." > You could also do this with an explicit pointer-to-context-struct parameter > that's passed around (and that version of the patch I posted), but the > class-based approached seems nicer to me. Are we talking about encapsulation or "looking nice"? In either case, I respectfully disagree -- talking specifically about the patch posted. Having a giant struct with a zillion of member functions defies any reasonable notion of "looking nice", and of "encapsulation." -- Gaby
Re: gcc-c-api
Hi David, On Mon, 10 Sep 2012, David Malcolm wrote: > Is it possible for you to post your work-in-progress code somewhere? Attached. > I know that you don't feel it's ready for committing, but I would find > it helpful - I'm interested in understanding the general approach, > rather than seeing completeness or perfection. Some sort of brain dump follows: The idea is as follows: as first cut an introspection API that is tied to compiler IR concepts rather than GCC specifics. As such it should be implementable also for other compilers, at least the trivial things that every traditional compiler will have. So, we have functions, basic blocks, instructions, operands and operators. Nothing of that should relate to tree or gimple or RTL. Take for instance the (included) dump-plugin. The goal would be, that depending on where you'd put that dumper in the pass pipeline it would work _unchanged_ on GENERIC, on GIMPLE and on RTL. That goal isn't reached yet, once because the internal iteration just isn't implemented for e.g. RTL instruction stream, and once because the operand iterator API isn't well suited to the tree-like nesting in GENERIC and RTL currently. [The intermediate goal was to redo the operand API to be tree-like at the base, and possibly write small wrappers to again expose the nicer interface that GIMPLE would provide (i.e. direct access to all read operands of an instruction).] Another thing I want is simplicity. E.g. only the bare minimum of types should be exposed. Note how the API itself for instance doesn't expose different types of collections, only a general Range which can enumerate all things, depending on how it's used (though the implementation has runtime checks for wrong usage). There are some questions to be solved, e.g. memory management for those objects that aren't directly tied to GCC objects, e.g. Ranges right now. I do have a strong feeling about the relation of e.g. plugin Instructions and GCC gimple/rtx, in the sense that plugin authors should _not_ be required to manage memory for those things (same for BBs, functions, operands). There are also other things missing: e.g. operators. The current thing doesn't have access to the TREE_CODE/gimple_expr_code/RTX_CODE, and hence can't differ between an add and a mul. Obviously that's less than optimal. But the codes exposed for the plugin should have no relation to GCC codes, but again be general concepts. So, externally the plugin would export codes like "GCC_ADD/SUB/MUL", whose enum values will remain stable forever, and internally they're mapped from the tree/rtx codes (that mapping can changes as we add/remove some enum values from those). Also types aren't included. Though some things would be obvious: a gcc_type (Operand op) function, and some accessors like "gcc_arithmetic_p (Type)", "gcc_width (Type)", "gcc_unsigned_p (Type)" and so on. Obviously most useful accessors to the individual objects are missing. Those accessors again should be fairly unrelated to GCC specific concepts, but I would envision things like "gcc_volatile_p (Instruction i)" or perhaps "gcc_reg_p (Operand)". > In particular, as the maintainer of the gcc-python-plugin I want > something that will make my life easier. Well, the current version 0.0 certainly will not make your life easier. It misses almost everything ;) But my goal was to set a ground interface that I would be pleased to work with as plugin author, _and_ that is easily maintainable by GCC authors (in a way this is actually more important), with the hope that actual plugin authors would extend it according to above principles as they need. > By that I mean: something that will make it easier to keep my plugin > compatible against "as many gcc versions as possible" (which currently > means 4.6 and 4.7, but I want to add 4.8 and so on), and minimize the > amount of recompiling I have to do over ABI issues within a GCC release. Yes, that's definitely the goal of my approach. Few opaque types, few high level accessors, never to be changed again (ABI wise) in the future, ... > My plugin is currently implemented in C (requiring C++ would be a pain > for me, but would be doable, I think). ... and the API C only, yes, definitely. I hope the above made some of the principles clear, even though the actual implementation is terribly lacking in features. Ciao, Michael.Index: Makefile.in === --- Makefile.in (revision 190803) +++ Makefile.in (working copy) @@ -1451,6 +1451,7 @@ ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OB ALL_HOST_OBJS = $(ALL_HOST_FRONTEND_OBJS) $(ALL_HOST_BACKEND_OBJS) BACKEND = libbackend.a main.o @TREEBROWSER@ libcommon-target.a libcommon.a \ + plugin/pluginapi.o \ $(CPPLIB) $(LIBDECNUMBER) MOSTLYCLEANFILES = insn-flags.h insn-config.h insn-codes.h \ @@ -2671,6 +2672,10 @@ passes.o : passes.c $(CONFIG_H) $(SYSTEM plugin.o : plugi
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
On 10 September 2012 15:53, Gabriel Dos Reis wrote: > [ I am adding back GCC mailing list in the CC: as this would be useful > for other contributors. ] > > On Mon, Sep 10, 2012 at 9:42 AM, Aaron Gray > wrote: >> On 10 September 2012 15:25, Gabriel Dos Reis >> wrote: >>> >>> On Mon, Sep 10, 2012 at 8:59 AM, Aaron Gray >>> wrote: >>> > On 10 September 2012 14:35, Gabriel Dos Reis >>> > >>> > wrote: >>> >> >>> >> On Mon, Sep 10, 2012 at 8:23 AM, Aaron Gray >>> >> >>> >> wrote: >>> >> > Hi, >>> >> > >>> >> > I have put in three patches on the 29th of August, but have not heard >>> >> > any real feedback on them :- >>> >> [...] >>> >> > [PATCH] C++'ization of cp/parser.c/h >>> >> > >>> >> > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02018.html >>> >> > >>> >> > >>> >> > This last patch possibly needs freshening, but all were tested and >>> >> > tested with the GCC testsuite. >>> >> >>> >> You did receive a real feedback on the last patch. >>> > >>> > >>> > Gaby, >>> > >>> > In reply, I was trying to do the first phase of a set of incremental >>> > changes >>> > towards normalizing the C++ frontend. >>> > >>> > Having looked at the complexity of parsing C++ and the complexity and >>> > pragmatics of the semantics and the complexity of the GCC C++ >>> > "middleend" >>> > code and know it to a degree then to have something working keep it >>> > working >>> > seems the best bet to me. >>> > >>> > So the interfaces can be made distinct and normalized while keeping the >>> > code >>> > running and passing the testsuite. Once the interfaces are distinct more >>> > radical changes can be made. >>> > >>> > Just my 2cents, >>> > >>> > Aaron >>> > >>> >>> Aaron, >>> >>> I am not sure I understand what you are saying. >>> The patch I commented on was *radical* change from the current state, and >>> there >>> is no answer to why you needed to make such a radical change, >> >> >> As I understand things we are C++'izing the GCC C++ frontend ? >> >> And encapsulation and class'ization seems to be the first step in doing that >> I would have thought ? > > It is not clear what the benefit is to move existing perfectly working > internal non-member functions to being member functions a huge struct. > > Encapsulation does not necessarily mean that all functions have to > be member functions or that all data type definitions have to reside > in a .h file. In fact, I would argue that the patch you posted reduced > encapsulation and abstraction, as opposed to increasing it. Datatypes > and member functions that have no business of being exposed to the > entire world are now made public. Next stage is to make the struct's classes and make most member function private. I was not worried at this stage about exposing the header as it is not used by ant other .c files except cp/cp-lang.c which is not actually dependant upon parser.h hence my very basic first patch. >> My changes are orthogonal to the original code. > > No, they are not -- hence the comments. please see above. > >> All I have done is create >> classes out of the cp_lexer_* and cp_parser_* functions and moved a few >> statics into the classes where it was logical and where there were no weird >> dependencies stopping that being done. > > You did not provide a rationale of why it was logical to move those functions > as you did. The comments I made looked at the heart of the changes you made. Sorry I should have explained the whole approach. What I am looking to obtain is isolating the C++ parser with no real semantic changes, just isolating the interfaces in order that the parser be reusable as a library component and allow migration to other solutions. Aaron
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
On Mon, Sep 10, 2012 at 10:41 AM, Aaron Gray wrote: > What I am looking to obtain is isolating the C++ parser with no real > semantic changes, just isolating the interfaces in order that the > parser be reusable as a library component and allow migration to other > solutions. Yes, for that, you need reduce the scope of your patch. Use Occam's razor. Do not move a declaration out of cp/parser.c unless you have a compelling reason for it. "Classization" is not sufficient argument. A good interface is likely to be reduced to the essential. I would suggest that you do not create any file out of cp/parser.c for the moment. Just focus on identifying the interface of the parser within cp/parser.c. Do no move data types out of cp/parser.c unless there is a good reason for it. If an existing function does not "poke" into what should morally be (private) data members of the cp_parser struct, don't make it a member function yet. If a function does, then look at whether it can be expressed in terms of more reduced set of observer/mutator functions; if that is the case, then do that. Adding the observer/mutator function does not change semantics. Isolating the interface means isolating the computational basis. -- Gaby
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
On 10 September 2012 16:54, Gabriel Dos Reis wrote: > On Mon, Sep 10, 2012 at 10:41 AM, Aaron Gray > wrote: > >> What I am looking to obtain is isolating the C++ parser with no real >> semantic changes, just isolating the interfaces in order that the >> parser be reusable as a library component and allow migration to other >> solutions. > > Yes, for that, you need reduce the scope of your patch. > > Use Occam's razor. Do not move a declaration out of cp/parser.c unless > you have a compelling reason for it. Okay. > "Classization" is not sufficient argument. Its an incremental step forward. > A good interface is likely to be reduced to the essential. > > I would suggest that you do not create any file out of cp/parser.c for the > moment. Just focus on identifying the interface of the parser within > cp/parser.c. It is actually two "generic" cross frontend functions that are linked to and not actually declared in parser.h - 'c_parse_file()', via cp/cp-lang.c and 'pragma_lex()', used by cp/lex.c. But yes I agree. This comes down to 'cp_parser::translation_unit()', afaics this is the only method that needs exposing in cp_parser. > Do no move data types out of cp/parser.c unless there is a good reason for it. Okay agreed. > If an existing function does not "poke" into what should morally be > (private) data members of the cp_parser struct, don't make it a > member function yet. I made most statics. And also the next stage of making it a class and member functions private would mean you would have to declare these function friend functions ? > If a function does, then look at whether it can > be expressed in terms of more reduced set of observer/mutator functions; > if that is the case, then do that. Adding the observer/mutator function does > not change semantics. Isolating the interface means isolating the > computational > basis. I think this is another stage of abstraction all together. Aaron
The Linux binutils 2.23.51.0.2 is released
Hi,
The big change is to fix STB_SECONDARY support:
a. Generate STB_SECONDARY symbols in DSO by default.
b. Properly handle STB_SECONDAY symbols when linking with archive.
c. Don't allow .weak directive to override .secondary directive.
It may be used to fix the libpthread.a issue in glibc.
H.J.
---
This is the beta release of binutils 2.23.51.0.2 for Linux, which is
based on binutils 2012 0908 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.21.51.0.3 release, you must remove .ctors/.dtors
section sentinels when building glibc or other C run-time libraries.
Otherwise, you will run into:
http://sourceware.org/bugzilla/show_bug.cgi?id=12343
Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.
Starting from the 2.21.51.0.2 release, binutils fully supports compressed
debug sections. However, compressed debug section isn't turned on by
default in assembler. I am planning to turn it on for x86 assembler in
the future release, which may lead to the Linux kernel bug messages like
WARNING: lib/ts_kmp.o (.zdebug_aranges): unexpected non-allocatable section.
But the resulting kernel works fine.
Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.bfd will be installed as ld. You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.23.51.0.2 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.23.51.0.1:
1. Update from binutils 2012 0908.
2. Fix STB_SECONDARY support:
a. Generate STB_SECONDARY symbols in DSO by default.
b. Properly handle STB_SECONDAY symbols when linking with archive.
c. Don't allow .weak directive to override .secondary directive.
3. Optimize i386/x86-64 linker to convert GOT load (MOV) to LEA.
4. Clarify x86 assembler error messages. PR 14457.
5. Improve NOP/prefetch support in x86 disassembler.
6. Improve I
Re: ARM: position-independent data
On 09/04/2012 02:25 PM, Jens Rosenboom wrote:
> Hello All,
>
> Do you maybe know how to find out (in legitimize_pic_address() and in
> arm_assemble_integer()) whether an address (rtx) is in text/rodata or
> in data?
You need to catch this much earlier than this. See the encode_section_info
hook,
where you can set all sorts of bits in SYMBOL_REF_FLAG{,S}.
Indeed it looks as if the bits you want may already be examined.
r~
Re: shrink-wrap leads to ICE at dwarf2cfi.c
On 09/10/2012 01:41 AM, Zhenqiang Chen wrote: > In function maybe_record_trace_start, there is a check: > > /* We ought to have the same state incoming to a given trace no > matter how we arrive at the trace. Anything else means we've > got some kind of optimization error. */ > gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row)); The assert is most definitely valid. The check makes certain that the unwind info as seen by any two paths leading to a common location are the same. When this fails, typically one of two things has happened: (1) The notes for the epilogue unwind info are incorrect, (2) We have applied an invalid code transformation in some earler optimization pass. We can't tell what the real problem is without more information. r~
Re: gcc-c-api
On Mon, 2012-09-10 at 17:20 +0200, Michael Matz wrote:
> Hi David,
>
> On Mon, 10 Sep 2012, David Malcolm wrote:
>
> > Is it possible for you to post your work-in-progress code somewhere?
>
> Attached.
Many thanks for posting this! Various comments inline below.
> > I know that you don't feel it's ready for committing, but I would find
> > it helpful - I'm interested in understanding the general approach,
> > rather than seeing completeness or perfection.
>
> Some sort of brain dump follows:
>
> The idea is as follows: as first cut an introspection API that is tied to
> compiler IR concepts rather than GCC specifics. As such it should be
> implementable also for other compilers, at least the trivial things that
> every traditional compiler will have. So, we have functions, basic
> blocks, instructions, operands and operators. Nothing of that should
> relate to tree or gimple or RTL.
I see. So there's a terminology issue here: we shouldn't refer to
"gimple" or "rtl", we should refer to "instructions" or "statements".
[Possibly crazy idea: should the API actually refer to itself as GCC?
(with "gcc_" prefixes etc) If it's implementable by other compilers,
would another prefix be suitable? I don't think this is a good idea,
but it makes for an interesting thought experiment]
> Take for instance the (included) dump-plugin. The goal would be, that
> depending on where you'd put that dumper in the pass pipeline it would
> work _unchanged_ on GENERIC, on GIMPLE and on RTL. That goal isn't
> reached yet, once because the internal iteration just isn't
> implemented for e.g. RTL instruction stream, and once because the operand
> iterator API isn't well suited to the tree-like nesting in GENERIC and
> RTL currently.
Interesting idea.
I prefer having a little more type-safety, but it's a pain to achieve it
in C. If you look at my proposed API [1], there are dozens of tiny
casting functions. I like that it's typesafe, but it's somewhat
inelegant.
> [The intermediate goal was to redo the operand API to be tree-like at the
> base, and possibly write small wrappers to again expose the nicer
> interface that GIMPLE would provide (i.e. direct access to all read
> operands of an instruction).]
>
> Another thing I want is simplicity. E.g. only the bare minimum of types
> should be exposed. Note how the API itself for instance doesn't expose
> different types of collections, only a general Range which can enumerate
> all things, depending on how it's used (though the implementation has
> runtime checks for wrong usage).
I seem to remember from earlier mailing list discussion there being a
preference for explicit iterator objects, rather than for_each functions
taking callbacks (my API uses the latter approach).
FWIW I don't expose any iterators directly in my plugin, I simply
generate a list of wrapper objects and return that. But I suppose
others might.
> There are some questions to be solved, e.g. memory management for those
> objects that aren't directly tied to GCC objects, e.g. Ranges right now.
> I do have a strong feeling about the relation of e.g. plugin Instructions
> and GCC gimple/rtx, in the sense that plugin authors should _not_ be
> required to manage memory for those things (same for BBs, functions,
> operands).
I'm not sure how to parse what you wrote above, so I'm not quite sure
what your preference here is. I see that you have range-creation
functions (e.g. "gcc_stmts"), which return a Range that's owned by the
caller, together with a cleanup function ("gcc_free_range") that must be
called exactly once assuming the Range was successfully created. The
other entities (e.g. "Function") are in fact "really" just gcc structs
internally (e.g.
"Function" = "struct Function_*" = "cast to (struct function *)" )
and those are GC-managed.
Currently in my proposed API I assume that all objects are GC-managed,
and that the user is required to register a callback hook to mark any
objects that they're referring to. Does that seem like a sane strategy?
If so, would if make sense to make the iterators be GC-managed also?
I'm not sure about this, but it seems worth discussing. It strikes me
that it's a common use-case to use an iterator within code, and it would
be a pain to have to track stack frames explicitly as GC roots, so
having iterators have their own lifetime-management may make that
simpler. (Awkward questions: what happens if a GC collection happens
during a loop? does the iterator hold a reference on the current
element? etc)
[FWIW In my plugin I explicitly keep track of all of my live wrapper
objects in a linked list, so that when the GCC GC runs I can simply walk
the list and call the appropriate marking function on the underlying GCC
objects, so that they don't get swept away from under me]
> There are also other things missing: e.g. operators. The current thing
> doesn't have access to the TREE_CODE/gimple_expr_code/RTX_CODE, and hence
> can
Re: Hello, What's the status of live range shrink in GCC
On 12-09-10 6:05 AM, Bin.Cheng wrote: Hi, I digged into gcc mail archive and found there are several threads discussing about live range shrink, like: As I know Ghassan preferred to work on Open64 that time in AMD and never touched GCC. and http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00188.html In these messages many people showed interests in LRS, in or out of sched1 pass. I am curious about the status now and have following questions: 1. Does sched-pressure patch Vlad worked is the LRS we mentioned in the message? No, the pressure-sensitive insn scheduler is not LRS. It mostly does not increase the register pressure when it is already high. There is other more comprehensive pressure-sensitive heuristic implemented by Richard Sandiford. I think it is better to ask Rcihard the same question about his heuristic. 2. If the answer is no, are there still someone want to do this in sched1? Or as Vlad once mentioned that we should implement LRS in another pass along with register re-materialization? It is still on my list of possible projects although I am busy with LRA project now and don't know when I can start it. I know how to decrease register pressure through rematerialization but I did not figured out yet how to do LRS and how to combine them. 3. What's the status/expectation of LRS now? I don't think there is any status of LRS. I only can say that introduction of IRA made this project more doable for implementation. Before its implementation accurate register pressure estimation just was not possible. I didn't follow the message on this topic before, so please forgive if I have missed some important updates about this.
Re: Hello, What's the status of live range shrink in GCC
On Tue, Sep 11, 2012 at 10:41 AM, Vladimir Makarov wrote: > On 12-09-10 6:05 AM, Bin.Cheng wrote: >> >> Hi, >> I digged into gcc mail archive and found there are several threads >> discussing about live range shrink, like: > > As I know Ghassan preferred to work on Open64 that time in AMD and never > touched GCC. > >> and >> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00188.html >> >> In these messages many people showed interests in LRS, in or out of >> sched1 pass. I am curious about the status now and have following >> questions: >> 1. Does sched-pressure patch Vlad worked is the LRS we mentioned in the >> message? > > No, the pressure-sensitive insn scheduler is not LRS. It mostly does not > increase the register pressure when it is already high. There is other more > comprehensive pressure-sensitive heuristic implemented by Richard Sandiford. > I think it is better to ask Rcihard the same question about his heuristic. > >> 2. If the answer is no, are there still someone want to do this in >> sched1? Or as Vlad once mentioned that we should implement LRS in >> another pass along with register re-materialization? > > It is still on my list of possible projects although I am busy with LRA > project now and don't know when I can start it. I know how to decrease > register pressure through rematerialization but I did not figured out yet > how to do LRS and how to combine them. > >> 3. What's the status/expectation of LRS now? > > I don't think there is any status of LRS. I only can say that introduction > of IRA made this project more doable for implementation. Before its > implementation accurate register pressure estimation just was not possible. > Hi Vlad, Thanks very much for your detailed explanation. -- Best Regards.
