question
You could not me to send some source code connected with compiling under linux -- Respectfully yours, Moskovtsev Vitaliy. http://www.vncwin.ru
Re: AIX trunk build fail #3
On 25 October 2012 02:12, Perry Smith wrote: > > This also changes a previous statement I made: while I did build 4.5.2 on a > different level of AIX, it was a 6.1 level and has the same LD_LIBRARY_PATH > feature. Thus, something has changed in the build process of gcc to include > LD_LIBRARY_PATH into the environment before calling xgcc since 4.5.2 was > released. At least, that is my current theory. I assume the difference is that 4.5.2 wasn't built with the C++ compiler so didn't need libstdc++.so, so it's not a problem if the wrong libstdc++.so is in your LD_LIBRARY_PATH, because it's not used anyway.
Re: AIX trunk build fail #3
On Oct 24, 2012, at 8:12 PM, Perry Smith wrote: > Just to satisfy my curiosity, I will build 4.5.2 on the same machine I'm now > using to verify what I just said. Yes. the gcc-4.5.2 tarball builds just fine on the same host using roughly the same configuration options. I've added only --disable-werrors (sp?) to the trunk build.
Re: AIX trunk build fail #3
On Oct 25, 2012, at 3:25 AM, Jonathan Wakely wrote: > On 25 October 2012 02:12, Perry Smith wrote: >> >> This also changes a previous statement I made: while I did build 4.5.2 on a >> different level of AIX, it was a 6.1 level and has the same LD_LIBRARY_PATH >> feature. Thus, something has changed in the build process of gcc to include >> LD_LIBRARY_PATH into the environment before calling xgcc since 4.5.2 was >> released. At least, that is my current theory. > > I assume the difference is that 4.5.2 wasn't built with the C++ > compiler so didn't need libstdc++.so, so it's not a problem if the > wrong libstdc++.so is in your LD_LIBRARY_PATH, because it's not used > anyway. Close but not really. I am building c and c++ in all cases. The difference is that cc1 now (the trunk build) links with libstdc++ which has its different bit versions in different paths. Is it normal for cc1 to link to libstdc++? Perry
Re: if-conversion/HOT-COLD partitioning
On 24 October 2012 22:07, Steven Bosscher wrote: > On Wed, Oct 24, 2012 at 6:11 PM, Christophe Lyon wrote: >> On 24 October 2012 00:42, Steven Bosscher wrote: >>> On Tue, Oct 23, 2012 at 10:29 PM, Christophe Lyon wrote: Well, both of these functions appear to check that the 2 blocks to merge belong to the same partition, so it should be OK. >>> >>> In your first email, you said if-convert was merging two blocks from >>> different partitions. can_merge_block_p() would rejected merging the >>> two blocks, so merge_blocks shouldn't be called on them. >>> >>> IIRC cfghooks.c:merge_blocks() used to have a >>> gcc_assert(can_merge_blocks(a,b)) but it's not there now. But if >>> can_merge_blocks() returns false, merge_blocks should fail. Your bug >>> is that merge_blocks is being called at all on those blocks from >>> different partitions. >>> >>> But not all calls to merge_blocks are guarded by if (can_merge_block_p()), this is probably where the problem is? >>> >>> Not sure. Depends on what blocks get merged. It may be that >>> if-conversion shouldn't even be attempting whatever transformation >>> it's attempting. Not enough information. >>> >> >> What happens is that merge_if_block() is called with test_bb, then_bb >> and else_bb in the cold section, while join_bb is in the hot one. > > AFAICT that can only happen if the join_bb has more predecessors than > just then_bb and else_bb. Otherwise, you'd be looking at a complete > diamond region, and test_bb and either else_bb or then_bb should be in > the hot partition as well. But if the join_bb has more predecessors, > then merge_blocks shouldn't be able to merge away the join block. > > So either something's wrong with the CFG so that merge_if_blocks sees > a join_bb with fewer than 2 predecessors (the only path to the > merge_blocks call in merge_if_blocks), or the profile data is so > corrupted that the partitioning has somehow gone wrong. So... > It looks like something is wrong with the CFG: | 19 (COLD) / \ / \ 20 (COLD) 21 (COLD) \ / \ / 22 (HOT) but indeed we have EDGE_COUNT (join_bb->preds) == 1 >> merge_if_block calls merge_blocks unconditionally several times (in my >> case, the wrong one is merge_blocks (combo_bb, join_bb)). > > ... still not quite enough information. > > A more detailed explanation of the paths through the code that lead to > the error would be nice. A test case would be good. A PR would be > best. I understand; the problem is that I am not allowed to publish the input code leading to this situation :-( Thanks for your help, Christophe.
Re: AIX trunk build fail #3
On 25 October 2012 14:16, Perry Smith wrote: > > On Oct 25, 2012, at 3:25 AM, Jonathan Wakely wrote: > >> On 25 October 2012 02:12, Perry Smith wrote: >>> >>> This also changes a previous statement I made: while I did build 4.5.2 on a >>> different level of AIX, it was a 6.1 level and has the same LD_LIBRARY_PATH >>> feature. Thus, something has changed in the build process of gcc to >>> include LD_LIBRARY_PATH into the environment before calling xgcc since >>> 4.5.2 was released. At least, that is my current theory. >> >> I assume the difference is that 4.5.2 wasn't built with the C++ >> compiler so didn't need libstdc++.so, so it's not a problem if the >> wrong libstdc++.so is in your LD_LIBRARY_PATH, because it's not used >> anyway. > > Close but not really. I am building c and c++ in all cases. That's not what I meant. Let me rephrase, 4.5.2 isn't built *using* the C++ compiler. > The difference is that cc1 now (the trunk build) links with libstdc++ which > has its different bit versions in different paths. > > Is it normal for cc1 to link to libstdc++? For trunk, yes, see the top entry of http://gcc.gnu.org/gcc-4.8/changes.html That isn't the case for 4.5.2, so as I said, 4.5.2 isn't built with the C++ compiler so doesn't link to libstdc++.so so doesn't care if you have incompatible versions in your LD_LIBRARY_PATH.
Re: if-conversion/HOT-COLD partitioning
On 25 October 2012 16:10, Christophe Lyon wrote: > On 24 October 2012 22:07, Steven Bosscher wrote: >> On Wed, Oct 24, 2012 at 6:11 PM, Christophe Lyon wrote: >>> On 24 October 2012 00:42, Steven Bosscher wrote: On Tue, Oct 23, 2012 at 10:29 PM, Christophe Lyon wrote: > Well, both of these functions appear to check that the 2 blocks to > merge belong to the same partition, so it should be OK. In your first email, you said if-convert was merging two blocks from different partitions. can_merge_block_p() would rejected merging the two blocks, so merge_blocks shouldn't be called on them. IIRC cfghooks.c:merge_blocks() used to have a gcc_assert(can_merge_blocks(a,b)) but it's not there now. But if can_merge_blocks() returns false, merge_blocks should fail. Your bug is that merge_blocks is being called at all on those blocks from different partitions. > But not all calls to merge_blocks are guarded by if > (can_merge_block_p()), this is probably where the problem is? Not sure. Depends on what blocks get merged. It may be that if-conversion shouldn't even be attempting whatever transformation it's attempting. Not enough information. >>> >>> What happens is that merge_if_block() is called with test_bb, then_bb >>> and else_bb in the cold section, while join_bb is in the hot one. >> >> AFAICT that can only happen if the join_bb has more predecessors than >> just then_bb and else_bb. Otherwise, you'd be looking at a complete >> diamond region, and test_bb and either else_bb or then_bb should be in >> the hot partition as well. But if the join_bb has more predecessors, >> then merge_blocks shouldn't be able to merge away the join block. >> >> So either something's wrong with the CFG so that merge_if_blocks sees >> a join_bb with fewer than 2 predecessors (the only path to the >> merge_blocks call in merge_if_blocks), or the profile data is so >> corrupted that the partitioning has somehow gone wrong. So... >> > It looks like something is wrong with the CFG: > >| >19 (COLD) > / \ >/ \ > 20 (COLD) 21 (COLD) >\ / > \ / > 22 (HOT) > > but indeed we have EDGE_COUNT (join_bb->preds) == 1 > This is because after merging 19 & 20, and then 19 & 21, there is only 1 egde left between 19 and 22, and is actually the expected case as the comment says.
Re: AIX trunk build fail #3
On Thu, Oct 25, 2012 at 12:20 PM, Jonathan Wakely wrote: > On 25 October 2012 14:16, Perry Smith wrote: >> >> On Oct 25, 2012, at 3:25 AM, Jonathan Wakely wrote: >> >>> On 25 October 2012 02:12, Perry Smith wrote: This also changes a previous statement I made: while I did build 4.5.2 on a different level of AIX, it was a 6.1 level and has the same LD_LIBRARY_PATH feature. Thus, something has changed in the build process of gcc to include LD_LIBRARY_PATH into the environment before calling xgcc since 4.5.2 was released. At least, that is my current theory. >>> >>> I assume the difference is that 4.5.2 wasn't built with the C++ >>> compiler so didn't need libstdc++.so, so it's not a problem if the >>> wrong libstdc++.so is in your LD_LIBRARY_PATH, because it's not used >>> anyway. >> >> Close but not really. I am building c and c++ in all cases. > > That's not what I meant. > > Let me rephrase, 4.5.2 isn't built *using* the C++ compiler. > >> The difference is that cc1 now (the trunk build) links with libstdc++ which >> has its different bit versions in different paths. >> >> Is it normal for cc1 to link to libstdc++? > > For trunk, yes, see the top entry of http://gcc.gnu.org/gcc-4.8/changes.html > > That isn't the case for 4.5.2, so as I said, 4.5.2 isn't built with > the C++ compiler so doesn't link to libstdc++.so so doesn't care if > you have incompatible versions in your LD_LIBRARY_PATH. I bootstrap GCC on AIX with GCC 4.6. - David
Kill ebitmap?
It turns out that gcc/ebitmap.[hc] is not used. Should we kill it? -- Lawrence Crowl
Re: AIX trunk build fail #3
On Oct 25, 2012, at 11:31 AM, David Edelsohn wrote: > On Thu, Oct 25, 2012 at 12:20 PM, Jonathan Wakely > wrote: >> On 25 October 2012 14:16, Perry Smith wrote: >>> >> For trunk, yes, see the top entry of http://gcc.gnu.org/gcc-4.8/changes.html >> >> That isn't the case for 4.5.2, so as I said, 4.5.2 isn't built with >> the C++ compiler so doesn't link to libstdc++.so so doesn't care if >> you have incompatible versions in your LD_LIBRARY_PATH. > > I bootstrap GCC on AIX with GCC 4.6. Does the group / team have an AIX 6.1 build machine to build the trunk on? Or am I the first to person walk into this?
Re: Kill ebitmap?
On Thu, Oct 25, 2012 at 2:24 PM, Lawrence Crowl wrote: > It turns out that gcc/ebitmap.[hc] is not used. > Should we kill it? Yes. Diego.
Re: if-conversion/HOT-COLD partitioning
On Thu, Oct 25, 2012 at 4:10 PM, Christophe Lyon wrote: > It looks like something is wrong with the CFG: > >| >19 (COLD) > / \ >/ \ > 20 (COLD) 21 (COLD) >\ / > \ / > 22 (HOT) So the partitioning is messed up, the above makes no sense. Where does it come from? > I understand; the problem is that I am not allowed to publish the > input code leading to this situation :-( SPEC GAP is maybe not GPL, I don't know. But the "official" GAP is GPLv2 so you may be able to produce a test case from that code base instead. The problem is that this bug only triggers with some profile data, but you could attach gcda/gcno files to a PR. Ciao! Steven
Re: if-conversion/HOT-COLD partitioning
On Fri, Oct 26, 2012 at 12:14 AM, Steven Bosscher wrote:
> On Thu, Oct 25, 2012 at 4:10 PM, Christophe Lyon wrote:
>> It looks like something is wrong with the CFG:
>>
>>|
>>19 (COLD)
>> / \
>>/ \
>> 20 (COLD) 21 (COLD)
>>\ /
>> \ /
>> 22 (HOT)
>
> So the partitioning is messed up, the above makes no sense. Where does
> it come from?
Oh, and you can of course always attach dumps to a PR. If you dump
with -fdump-{tree,rtl}-all-blocks-details, the profile counts are also
reported in the dumps, and the evolution of the CFG from the initial
partitioning to the thing you've ASCII-arted above can be deduced.
Ciao!
Steven
Re: if-conversion/HOT-COLD partitioning
On Thu, Oct 25, 2012 at 3:14 PM, Steven Bosscher wrote: > On Thu, Oct 25, 2012 at 4:10 PM, Christophe Lyon wrote: >> It looks like something is wrong with the CFG: >> >>| >>19 (COLD) >> / \ >>/ \ >> 20 (COLD) 21 (COLD) >>\ / >> \ / >> 22 (HOT) > > So the partitioning is messed up, the above makes no sense. Where does > it come from? > > >> I understand; the problem is that I am not allowed to publish the >> input code leading to this situation :-( > > SPEC GAP is maybe not GPL, I don't know. But the "official" GAP is > GPLv2 so you may be able to produce a test case from that code base > instead. The problem is that this bug only triggers with some profile > data, but you could attach gcda/gcno files to a PR. The official wording from SPEC is that the sources are under the same license as they are provided to them. It is the data files which are under the SPEC license. Thanks, Andrew Pinski
Re: if-conversion/HOT-COLD partitioning
On Fri, Oct 26, 2012 at 12:26 AM, Andrew Pinski wrote: > The official wording from SPEC is that the sources are under the same > license as they are provided to them. It is the data files which are > under the SPEC license. Good. So the only things needed to reproduce the problem can be shared: the source file that causes the ICE, the gcda+gcno files for the profile, the compiler SVN revision number, and the compiler configuration and options. Ciao! Steven
Re: AIX trunk build fail #3
On Oct 25, 2012, at 1:31 PM, Perry Smith wrote: > > On Oct 25, 2012, at 11:31 AM, David Edelsohn wrote: > >> On Thu, Oct 25, 2012 at 12:20 PM, Jonathan Wakely >> wrote: >>> On 25 October 2012 14:16, Perry Smith wrote: >>> For trunk, yes, see the top entry of http://gcc.gnu.org/gcc-4.8/changes.html >>> >>> That isn't the case for 4.5.2, so as I said, 4.5.2 isn't built with >>> the C++ compiler so doesn't link to libstdc++.so so doesn't care if >>> you have incompatible versions in your LD_LIBRARY_PATH. >> >> I bootstrap GCC on AIX with GCC 4.6. > > Does the group / team have an AIX 6.1 build machine to build the trunk on? > Or am I the first to person walk into this? I'm still curious in the question above But moving on: I wrapped xgcc with this script: = #!/bin/ksh unset LD_LIBRARY_PATH exec /usr/work/build/gcc.git/gcc/.hide/xgcc "$@" = I got into my build tree, did: rm -r powerpc-ibm-aix6.1.0.0/libatomic make configure-target-libatomic which completed successfully. This was my short test I was doing before to recreate / debug the issue. Can anyone help me understand why LD_LIBRARY_PATH is being set? Is it needed for another platform? For AIX, the executable has one already built into it and should be valid until the executable is installed -- at which time it is often relinked (I believe). The other question -- for AIX, why was LD_LIBRARY_PATH picked (which is just post 6.1) and not LIBPATH? This is part of why I'm asking my question above... is it maybe the case that this code has just never been ported to AIX? (the multi-lib configure code) Thank you, Perry Smith
