GCC 4.7.0 Status Report (2012-01-09), Stage 3 ends now
Status == Stage 3 is now officially over, after a bit more than two months. The GCC trunk is now in regression and documentation fixes only state (so-called stage4). The trunk will remain in this state until it is sufficiently stable for release. At this point we will create the 4.7 branch and do a first release candidate. The overall status is improving nicely since the last report. Quality Data Priority # Change from Last Report --- --- P1 13 - 13 P2 84 - 13 P3 16 - 33 --- --- Total 113 - 59 We currently also have 128 P4 or P5 regression bugs open, those include regressions for non-primary languages and targets that are not included in the list of primary and secondary targets. Previous Report === http://gcc.gnu.org/ml/gcc/2011-12/msg00069.html The next report will be sent by Jakub.
Re: Access to unused global variable declarations from a plugin
On Thu, Jan 5, 2012 at 5:16 PM, David Malcolm wrote: > I'm working on a GCC plugin which performs static analysis of Python > extension code [1] > > In various places I need access to a VAR_DECL for various globals from C > code, many of which potentially aren't used directly within the > compilation unit. For example, I may need to reference this global: > extern PyObject * PyExc_MemoryError; > when reasoning about the possible exception objects that could have been > set within a function, even if the code in question doesn't explicitly > reference that global. > > Previously, I've been looking with the TRANSLATION_UNIT_DECL's block, > and then looking within BLOCK_VARS(). > > This works with 4.6.1, but doesn't work in 4.7 [2]; on debugging, it > seems to have been broken by the fix for PR debug/51410: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51410 > which seems to be slimming down the debuginfo by removing these decls. > > I suspect I was going about this the wrong way - so is there a good way > to access VAR_DECLs for global variable declarations? (as opposed to > *definitions*, which I'm able to access via "varpool_nodes"). > Previously I'd also tried looking them up via an identifier, but by the > time my code runs the scope's binding from the identifier to the > VAR_DECL has been lost. > > FWIW I'm tracking the breakage on my side as > https://fedorahosted.org/gcc-python-plugin/ticket/21 Mere declarations are gone and not kept as you leave the frontends domain. You can probably access them in frontend specific ways before cgraph_finalize_compilation_unit is called. Richard. > Thanks > Dave > > [1] https://fedorahosted.org/gcc-python-plugin/ > [2] specifically, on Fedora's builds of GCC, with > gcc-4.6.1-9.fc15.x86_64 and gcc-4.7.0-0.2.fc17.x86_64 respectively > >
Re: [4.7,trans-mem] Summary of unsolved known bugs
stage3 is over, so let's have a look at the open bugs again... Looking at Patrick's old list, the following bugs are still open > [trans-mem] save/restore of thread-local data in nested txns is missing > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49581 Aldy, you wanted to take a look. Were you able to reproduce? I haven't looked at it in a long time... > * [trans-mem] problem with TM clone aliases > Leads to add _ITM_getTMCloneOrIrrevocable in a __transaction_atomic. > -> Fix proposed. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51516 Aldy, has this been fixed? You said you were waiting for review. > * ICE when lto1 does not have -fgnu-tm and object file uses TM > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 Still open? > Probably should be closed: > * libitm failures > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124 Can be closed? the static ctor part is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51173 > * infinite loop when compiling > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075 Not really related to us. ICE on invalid. Any other remaining issues? Everyone, what about the "variadic argument of _ITM_beginTransaction" that Patrick reported? Things we still can do: - install.texi: libitm disable/enable, needs C++ to be enabled 4.7 issues, we will look at these again for 4.8: - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752 publication safety - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771 setjmp hack, fix abnormal edges instead - (needs no PR) STM not tuned - (no PR yet, but an early test case): attribute (safe/unsafe/...) rules are not enforced - (no PR yet) goes irrevocable early - (no PR yet) we don't save/restore FP state on txn begin/restart - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51173 allow static ctors in transactions. Were do we document these? In the Wiki, and copy them to the release notes later, or what's the proper procedure here? For libitm, I have one patch pending review (filter out undos to libitm's stack) and want to work on a multiple-lock write-through today. Plus perhaps some cache miss tuning. I heard that new patches might be allowed for libitm even though we're in stage4.
Re: return vs simple_return
On 12/28/2011 07:13 PM, Michael Eager wrote: > Hi -- > > I've run into a problem with the MicroBlaze backend > where it is not recognizing a return pattern. I'm > trying to modify the back end to use the 'simple_return' > pattern, rather than 'return', since MicroBlaze has > exactly what the documentation describes: a no-frills > return instruction which does nothing more than branch > back to the caller. > > When I define only 'simple_return', there are undefined > references in function.c for emit_return_into_block() > and emit_use_return_register_into_block(), since these > are defined when HAVE_return is defined. > > MIPS has a similar call/return model, with a trivial > return instruction. mips.md defines expanders for both > 'return' and 'simple_return' and identical insn's for both > which generate the return jump. > > ARM also has a simple return, but the back end defines > 'return' and does not define 'simple_return'. > > My guess is that the #ifdef HAVE_return in function.c > which surrounds the undefined functions should be removed. > > What is the correct model for the back end? Define only > 'return' like ARM, define both 'return' and 'simple_return' > like MIPS, or define only 'simple_return' like I tried to do? We should probably work towards the point where a port can define only simple_return. Historically that pattern didn't exist, so essentially every port uses return patterns and guards them with checks for an empty epilogue. If you want the least amount of work, define only such a return pattern. If you also want shrink-wrapping, define a simple_return pattern and make sure your epilogues are properly annotated with CFA information. If you want to help clean up this area, define only a simple_return pattern and fix the middle end to deal with this configuration. Bernd
Re: ChangeLog rotation
Oh, my bad, sorry about the conflict marker. I didn't realize the "Start of New Year" procedure until after I googled it, sorry again. -Han
Broken links (HTTP 404) on http://gcc.gnu.org/onlinedocs/
Hello, I would like to report some broken links on http://gcc.gnu.org/onlinedocs/ Namely links to PDF version of "GCC 4.6.2 Standard C++ Library Reference Manual" and "GCC 4.6.2 Standard C++ Library Manual" referencing http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual.pdf.bz2 http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api.pdf.bz2 They result in HTTP 404 error. Thank you for your work. With best regards, Filip Jares
[trans-mem] RFC Fix missing REG_TM notes
In trans-mem.c:make_tm_edge, it gets the slot for insertion but it
doesn't set it. Fixing this makes cfgexpand.c:
mark_transaction_restart_calls fails because sometimes the instruction
is not found. In the attached patch, I just ignore if insn is NULL but
do you have an idea why this happens?
On my side, I was able to fix the problem with genome but the patch is
not clean at all and I need to find exactly where and why the problem
was fixed.
Thanks!
--
Patrick Marlier.
Index: trans-mem.c
===
--- trans-mem.c (revision 183019)
+++ trans-mem.c (working copy)
@@ -2517,6 +2517,7 @@ make_tm_edge (gimple stmt, basic_block bb, struct
{
n = ggc_alloc_tm_restart_node ();
*n = dummy;
+ *slot = n;
}
else
{
Index: cfgexpand.c
===
--- cfgexpand.c (revision 183019)
+++ cfgexpand.c (working copy)
@@ -1978,16 +1978,22 @@ mark_transaction_restart_calls (gimple stmt)
tree list = n->label_or_list;
rtx insn;
- for (insn = next_real_insn (get_last_insn ());
- !CALL_P (insn);
+ /* ??? mark only the first call, is it right? */
+ for (insn = get_last_insn ();
+ insn && !CALL_P (insn);
insn = next_real_insn (insn))
continue;
+ /* ??? insn can be NULL, why? -> some reg_note are missing. */
+ if (!insn || find_reg_note(insn, REG_TM, NULL_RTX))
+ return;
+
if (TREE_CODE (list) == LABEL_DECL)
add_reg_note (insn, REG_TM, label_rtx (list));
else
for (; list ; list = TREE_CHAIN (list))
add_reg_note (insn, REG_TM, label_rtx (TREE_VALUE (list)));
+
}
}
Re: [trans-mem] RFC Fix missing REG_TM notes
On Mon, 2012-01-09 at 15:55 -0500, Patrick Marlier wrote: > On my side, I was able to fix the problem with genome but the patch is > not clean at all and I need to find exactly where and why the problem > was fixed. What do you mean? Do you still see issues with Genome, even with the returns-twice patch? If so, just on i686 or x86_64 too? With libitm?
Re: [trans-mem] RFC Fix missing REG_TM notes
On 01/09/2012 04:04 PM, Torvald Riegel wrote: On Mon, 2012-01-09 at 15:55 -0500, Patrick Marlier wrote: On my side, I was able to fix the problem with genome but the patch is not clean at all and I need to find exactly where and why the problem was fixed. What do you mean? Do you still see issues with Genome, even with the returns-twice patch? If so, just on i686 or x86_64 too? With libitm? Sorry for confusion. Of course, I disabled your returns-twice patch. I patched at different places and I hope to figure out where is the problem and that it is not a side effect... I am currently testing on x86_64 with libitm. Patrick.
Re: [4.7,trans-mem] Summary of unsolved known bugs
On 01/09/2012 05:20 AM, Torvald Riegel wrote: * ICE when lto1 does not have -fgnu-tm and object file uses TM > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 Still open? Yes. I have started a thread here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01221.html But as I said, probably out of my knowledge... Here some more PR: * Bug 51698 - [trans-mem] TM runtime and application with LTO * [libitm, build] Clear hardware capabilities on libitm.so with Sun ld http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02093.html Not sure to know the status of this (Rainer?). PR? * Bug 51773 - error building libitm/aatree.cc on ARM * Bug 51173 - XFAIL: libitm.c++/static_ctor.C error: unsafe function call ‘void __cxa_guard_release(long long int*)’ within ‘transaction_safe’ function error: unsafe function call ‘int __cxa_guard_acquire(long long int*)’ within ‘transaction_safe’ function The static initialization is using locks. One way to fix that is to transform the acq/rel to a transaction, right? * Bug 51124 - libitm failures FAIL: libitm.c++/eh-1.C execution test -> Darwin: Xcode 4+ problem http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html -> Solaris: ?. -- Patrick Marlier
Missed optimization opportunity
Hello,
I've come across an issue when working on a smart pointer
implementation. Gcc does not seem to propagate constants enough, missing
some optimization opportunities. I don't think that this issue is
specific to smart pointers, so there might be other cases when gcc
generates suboptimal code.
Attached a simple test case. The smart pointer here is a unique pointer,
always only a single instance holds a raw pointer to the resource. The
deletion can be customized through a policy class. In main(), I allocate
an int, then pass it through several smart pointers. At the end, the
last smart pointer holds the raw pointer to the allocated memory.
Compiled as:
g++ -g -O3 -o gccoptbug.o -c gccoptbug.cpp
g++ -o gccoptbug gccoptbug.o
The generated code on AMD64 looks like this:
0x004004d0 <+0>:sub$0x8,%rsp
0x004004d4 <+4>:mov$0x4,%edi
0x004004d9 <+9>:callq 0x4004c0 <_Znwm@plt> ; operator new
0x004004de <+14>:mov%rax,%rdi
0x004004e1 <+17>:callq 0x4004a0 <_ZdlPv@plt> ; operator
delete
0x004004e6 <+22>:xor%edi,%edi
0x004004e8 <+24>:callq 0x4004a0 <_ZdlPv@plt>
0x004004ed <+29>:xor%edi,%edi
0x004004ef <+31>:callq 0x4004a0 <_ZdlPv@plt>
0x004004f4 <+36>:xor%edi,%edi
0x004004f6 <+38>:callq 0x4004a0 <_ZdlPv@plt>
0x004004fb <+43>:xor%edi,%edi
0x004004fd <+45>:callq 0x4004a0 <_ZdlPv@plt>
0x00400502 <+50>:xor%eax,%eax
0x00400504 <+52>:add$0x8,%rsp
0x00400508 <+56>:retq
The allocated memory is freed, then op delete is called four times with
a 0 pointer. The dtor and the called deleter fn was inlined. So far so good.
If I modify the deleter policy to call op delete only when the pointer
is not zero (#if 1 at line 6), the generated code changes to:
0x004004d0 <+0>:sub$0x58,%rsp
0x004004d4 <+4>:mov$0x4,%edi
0x004004d9 <+9>:callq 0x4004c0 <_Znwm@plt>
0x004004de <+14>:lea0x40(%rsp),%rdi
0x004004e3 <+19>:mov%rax,0x40(%rsp)
0x004004e8 <+24>:movq $0x0,(%rsp)
0x004004f0 <+32>:movq $0x0,0x10(%rsp)
0x004004f9 <+41>:movq $0x0,0x20(%rsp)
0x00400502 <+50>:movq $0x0,0x30(%rsp)
0x0040050b <+59>:callq 0x400630
>::~Ptr()>
0x00400510 <+64>:lea0x30(%rsp),%rdi
0x00400515 <+69>:callq 0x400630
>::~Ptr()>
0x0040051a <+74>:lea0x20(%rsp),%rdi
0x0040051f <+79>:callq 0x400630
>::~Ptr()>
0x00400524 <+84>:lea0x10(%rsp),%rdi
0x00400529 <+89>:callq 0x400630
>::~Ptr()>
0x0040052e <+94>:mov%rsp,%rdi
0x00400531 <+97>:callq 0x400630
>::~Ptr()>
0x00400536 <+102>:xor%eax,%eax
0x00400538 <+104>:add$0x58,%rsp
0x0040053c <+108>:retq
Instead of eliminating the calls to op delete, the actual smart ptr
objects appear on the stack, and the dtor is not inlined anymore.
gcc 4.4 and 4.5 optimizes as expected:
0x00400640 <+0>:sub$0x8,%rsp
0x00400644 <+4>:mov$0x4,%edi
0x00400649 <+9>:callq 0x400540 <_Znwm@plt>
0x0040064e <+14>:test %rax,%rax
0x00400651 <+17>:je 0x40065b
0x00400653 <+19>:mov%rax,%rdi
0x00400656 <+22>:callq 0x400510 <_ZdlPv@plt>
0x0040065b <+27>:xor%eax,%eax
0x0040065d <+29>:add$0x8,%rsp
0x00400661 <+33>:retq
4.6 and 4.7 (r182889) generates the suboptimal code as above.
I've checked bugzilla, and #46076
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076) is related, I guess.
There, Jan Hubicka 2010-10-19 03:20:48 UTC writes that main() is
optimized for size. To check this, I've added foo() to the test case,
and it is optimized correctly w/ 4.6 and 4.7. Moreover, -Os produces the
same foo() and main() functions. However, the size optimized version is
more than 3 times as large as the other one. Is this normal?
Regards, Peter
template
struct Deleter
{
static void Delete(T* p_)
{
#if 0 // if enabled, Delete() is not inlined
if (p_)
#endif
delete p_;
}
};
template >
class Ptr
{
public:
Ptr() : m_ptr(0)
{
}
Ptr(T* p_) : m_ptr(p_)
{
}
Ptr(const Ptr& p_) : m_ptr(p_.Forget())
{
}
~Ptr()
{
D::Delete(m_ptr);
}
T* Forget() const
{
T* s = m_ptr;
m_ptr = 0;
return s;
}
private:
mutable T* m_ptr;
};
int main()
{
typedef Ptr MyPtr;
MyPtr p0 = new int;
MyPtr p1 = p0;
MyPtr p2 = p1;
MyPtr p3 = p2;
MyPtr p4 = p3;
}
Re: Broken links (HTTP 404) on http://gcc.gnu.org/onlinedocs/
> I would like to report some broken links on > http://gcc.gnu.org/onlinedocs/ Namely links to PDF version of "GCC > 4.6.2 Standard C++ Library Reference Manual" and "GCC 4.6.2 Standard > C++ Library Manual" referencing > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual.pdf.bz2 > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api.pdf.bz2 Thanks for the report! These links are now fixed. best, Benjamin
contributing to gcc
Hey guys, I'm a sophomore in college, and I'm a solid C programmer. I'd like to work on an open source project, and the gcc compiler seems like a great one. However, I'm not sure if work is still done on the compiler itself, or just porting it to other systems? I'm interested in the former, but I don't know much about compilers. Would it be possible for me to make meaningful contributions, and if so, how should I start? Thanks, Aayush
Trouble installing gfortran
Recently I have been describing my troubles installing gfortran in the comp.lang.fortran newsgroup, and FX has given useful help. But today my system won't let me read anything in that newsgroup so I'm emailing to you. One thing that wasn't suggested but I find allowed me to configure GCC, make and make install was rm -f /tmp/gccobj/prev-* before starting. (I used a bash shell script saying inter alia srcdir=/tmp/gcc-4.6.2 objdir=/tmp/gccobj prefix=/tmp/gf gccopts=" --prefix=$prefix --enable-languages=c,c++,fortran" gccopts=$gccopts" --disable-libada" # unlikely to need ADA! gccopts=$gccopts" --with-gmp=$HOME --with-mpfr-include=$HOME/mpfr-3.0.0" gccopts=$gccopts" --with-mpfr-lib=$HOME/mpfr-3.0.0/.libs" gccopts=$gccopts" --with-mpc=$HOME/mpc-0.9" $srcdir/configure $gccopts # http://gcc.gnu.org/install/configure.html because my HOME disk space is too small for GCC and all the things it needs.) My little test program then compiled but wouldn't run even though the library said to be missing does exist. It was peresumably put somewhere that gfortran couldn't find it. What should I do now? Evidence: rimu[/tmp]$ ls -l */*/libquadmath.so* lrwxrwxrwx 1 harperj1 harperj1 20 Jan 10 12:35 gf/lib/libquadmath.so -> libquadmath.so.0.0.0 lrwxrwxrwx 1 harperj1 harperj1 20 Jan 10 12:35 gf/lib/libquadmath.so.0 -> libquadmath.so.0.0.0 -rwxr-xr-x 1 harperj1 harperj1 966329 Jan 10 12:35 gf/lib/libquadmath.so.0.0.0 rimu[/tmp]$ cd rimu[~]$ /tmp/gf/bin/gfortran -v hello.f Driving: /tmp/gf/bin/gfortran -v hello.f -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=/tmp/gf/bin/gfortran COLLECT_LTO_WRAPPER=/tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: /tmp/gcc-4.6.2/configure --prefix=/tmp/gf --enable-languages=c,c++,fortran --disable-libada --with-gmp=/home/harperj1 --with-mpfr-include=/home/harperj1/mpfr-3.0.0 --with-mpfr-lib=/home/harperj1/mpfr-3.0.0/.libs --with-mpc=/home/harperj1/mpc-0.9 Thread model: posix gcc version 4.6.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/f951 hello.f -ffixed-form -quiet -dumpbase hello.f -mtune=generic -march=pentiumpro -auxbase hello -version -fintrinsic-modules-path /tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/finclude -o /tmp/ccDukrje.s GNU Fortran (GCC) version 4.6.2 (i686-pc-linux-gnu) compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.6.2 (i686-pc-linux-gnu) compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' as --32 -o /tmp/ccGzx8Uk.o /tmp/ccDukrje.s Reading specs from /tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/../../../libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' COMPILER_PATH=/tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/:/tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/:/tmp/gf/libexec/gcc/i686-pc-linux-gnu/:/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/:/tmp/gf/lib/gcc/i686-pc-linux-gnu/ LIBRARY_PATH=/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/:/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /tmp/gf/libexec/gcc/i686-pc-linux-gnu/4.6.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/crtbegin.o -L/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2 -L/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/../../.. /tmp/ccGzx8Uk.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/crtend.o /usr/lib/crtn.o rimu[~]$ ./a.out ./a.out: error while loading shared libraries: libquadmath.so.0: cannot open shared object file: No such file or directory rimu[~]$ -- John Harper, School of Mathematics Statistics and Operations Research Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045
Re: contributing to gcc
On Mon, Jan 09, 2012 at 04:33:54PM -0800, Aayush Upadhyay wrote: > I'm a sophomore in college, and I'm a solid C programmer. I'd like to work on an open source project, and the gcc compiler seems like a great one. However, I'm not sure if work is still done on the compiler itself, or just porting it to other systems? I'm interested in the former, but I don't know much about compilers. Would it be possible for me to make meaningful contributions, and if so, how should I start? Quite a bit of work is being done on the compiler itself, with lots of brainpower devoted to making it better and to implement the latest language standards. There is a great deal of information on gcc development on http://gcc.gnu.org/ . As this is a core piece of infrastructure for GNU/Linux and lots of other folks, standards are extremely high. However, you could start out by reading http://gcc.gnu.org/contribute.html and http://gcc.gnu.org/projects/beginner.html The latter lists some projects that non-experts could contribute to, though it is wise to check for duplication and relevance before starting any major efforts.
Re: [trans-mem] RFC Fix missing REG_TM notes
On 01/09/2012 04:19 PM, Patrick Marlier wrote: On 01/09/2012 04:04 PM, Torvald Riegel wrote: On Mon, 2012-01-09 at 15:55 -0500, Patrick Marlier wrote: On my side, I was able to fix the problem with genome but the patch is not clean at all and I need to find exactly where and why the problem was fixed. What do you mean? Do you still see issues with Genome, even with the returns-twice patch? If so, just on i686 or x86_64 too? With libitm? Sorry for confusion. Of course, I disabled your returns-twice patch. I patched at different places and I hope to figure out where is the problem and that it is not a side effect... I am currently testing on x86_64 with libitm. Patrick. Continuation... In genome, the problem is that in ira-lives.c the bb has lost its abnormal edge and thus this 'if' is never satisfied for TM back edge. /* Allocnos can't go in stack regs at the start of a basic block that is reached by an abnormal edge. Likewise for call clobbered regs, because caller-save, fixup_abnormal_edges and possibly the table driven EH machinery are not quite ready to handle such allocnos live across such edges. */ if (bb_has_abnormal_pred (bb)) The bb has lost its abnormal edge here in cfgbuild.c:gimple_expand_cfg /* At the moment not all abnormal edges match the RTL representation. It is safe to remove them here as find_many_sub_basic_blocks will rediscover them. In the future we should get this fixed properly. */ if ((e->flags & EDGE_ABNORMAL) && !(e->flags & EDGE_SIBCALL)) remove_edge (e); So if I apply the modification from the previous post and if I don't remove_edge here, genome seems to work correctly. Actually, I don't really know what to do with this remove_edge... I hope this may help you guys! and thanks in advance for any comment on this (I will be happy to learn!). -- Patrick Marlier.
