Re: VN_INFO might be NULL in PRE
On Wed, Oct 24, 2012 at 3:13 AM, Zhenqiang Chen
wrote:
> On 23 October 2012 18:02, Richard Biener wrote:
>> On Tue, Oct 23, 2012 at 7:36 AM, Zhenqiang Chen
>> wrote:
>>> Hi,
>>>
>>> PRE bases on the result of value numbering (run_scc_vn). At the end,
>>> it free_scc_vn. But before free_scc_vn, it might call cleanup_tree_cfg
>>> ();
>>>
>>> if (do_eh_cleanup || do_ab_cleanup)
>>> cleanup_tree_cfg ();
>>>
>>> cleanup_tree_cfg might call make_ssa_name which might reuse some
>>> "name" from the FREE_SSANAMES list. If the VN_INFO of the "name" is
>>> NULL, free_scc_vn will "Segmentation fault". PR 54902
>>> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54902) shows a real case.
>>> The attached log shows the gdb backtrace to create a new ssa name.
>>>
>>> Here is function VN_INFO:
>>>
>>> vn_ssa_aux_t
>>> VN_INFO (tree name)
>>> {
>>> vn_ssa_aux_t res = VEC_index (vn_ssa_aux_t, vn_ssa_aux_table,
>>> SSA_NAME_VERSION (name));
>>> gcc_checking_assert (res);
>>> return res;
>>> }
>>>
>>> Can we make sure "res" is not NULL for the new ssa name?
>>>
>>> In trunk, Richard's "Make gsi_remove return whether EH cleanup is
>>> required" patches in r186159 and r186164 make "do_eh_cleanup" to
>>> false. So cleanup_tree_cfg is not called in PRE. Then no new ssa name
>>> will be created.
>>>
>>> Does the Richard's patch fix the root cause?
>>
>> I don't think so. Where does cfgcleanup call make_ssa_name? The solution
>> would be to post-pone cleaning up the CFG until after free_ssc_vn. To
>> be able to compute dominators we only have to remove unreachable blocks
>> (delete_unreachable_blocks)
>
> The attachment (bt.log) in previous mail shows the trace to call
> make_ssa_name. PR 54902 includes a test case to reproduce it. The
> bt.log bases on 4.7.
>
> I have no case to reproduce it for trunk. But cleanup_tree_cfg is
> still called before free_ssc_vn.
Ah, call folding on block merging ... :/ I suppose we can even end up
leaking memory that way when SSA names are released there.
Let me take the bug.
Richard.
> Thanks!
> -Zhenqiang
RE: Documentation problem with TEXT_SECTION_ASM_OP
> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Joseph S. Myers > Sent: 23 October 2012 15:28 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: Documentation problem with TEXT_SECTION_ASM_OP > > So far only TRAMPOLINE_SIZE is handled like that; conversions of other > macros are welcome. The list on that wiki page may be a bit out of date, > but should still be a good starting point for this project. > I have finally understood what you meant about TRAMPOLINE_SIZE. I also found the entry where that was made: 2011-06-09 Rainer Orth Joseph Myers * c.opt (fbuilding-libgcc): New option. * c-cppbuiltin.c (c_cpp_builtins): Define __LIBGCC_TRAMPOLINE_SIZE__ if flag_building_libgcc. I will give it a try to doing something similar for TEXT_SECTION_ASM_OP to start with. Paulo Matos
RE: Documentation problem with TEXT_SECTION_ASM_OP
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Joseph S. Myers
> Sent: 23 October 2012 15:28
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Documentation problem with TEXT_SECTION_ASM_OP
>
> conversions of other macros are welcome.
> The list on that wiki page may be a bit out of date,
> but should still be a good starting point for this project.
>
I gave it a go with TEXT_SECTION_ASM_OP.
I started by changing crtstuff.c to use __LIBGCC_TEXT_SECTION_ASM_OP__ instead
of TEXT_SECTION_ASM_OP.
I noticed crtstuff.c is not compiled with -fbuilding-libgcc so I added the
flags to CRTSTUFF_T_CFLAGS in my makefile fragment.
Now to the changes in GCC itself:
* Right where if(flag_building_libgcc) is, in c_cpp_builtins, the if becomes:
/* For libgcc-internal use only. */
if (flag_building_libgcc)
{
/* For libgcc enable-execute-stack.c. */
builtin_define_with_int_value ("__LIBGCC_TRAMPOLINE_SIZE__",
TRAMPOLINE_SIZE);
/* For libgcc crtstuff.c. */
#ifdef TEXT_SECTION_ASM_OP
builtin_define_with_value ("__LIBGCC_TEXT_SECTION_ASM_OP__",
TEXT_SECTION_ASM_OP, true);
#else
/* Is text_section always an unnamed section? */
builtin_define_with_value ("__LIBGCC_TEXT_SECTION_ASM_OP__",
(const char *)text_section->unnamed.data,
true);
#endif
}
The reason for the ifdef is because the docs allow the backend to define either
TEXT_SECTION_ASM_OP or the text_section directly in TARGET_ASM_INIT_SECTIONS.
Therefore if we don't have TEXT_SECTION_ASM_OP we need to grab the text string
from text_section. I assumed text_section was defined in
TARGET_ASM_INIT_SECTIONS with an unnamed section (that's how I did it) but I am
unsure if this is a general assumption.
Then remaining problem is that for preprocessing only no_backend from toplev.c
is true and varasm initialization in that case doesn't run, so I changed
do_compile to have:
/* Set up the back-end if requested. */
if (!no_backend)
backend_init ();
else
init_varasm_once ();
This did the trick, but I am struggling with an interesting problem.
Assume I want text_section asm op to be "\t.section .text, \"ax\"", so I would
define
#define TEXT_SECTION_ASM_OP "\t.section .text, \"ax\""
However, I decided to define it in TARGET_ASM_INIT_SECTIONS with:
text_section = get_unnamed_section (SECTION_CODE, output_section_asm_op,
"\t.section .text, \"ax\"");
But when this gets to libgcc, if I preprocess crtstuff.c __LIBGCC_TEXT_ASM_OP__
is defined to:
#define __LIBGCC_TEXT_SECTION_ASM_OP__ ".section .text, "axU""
If I debug cc1 to see what happens when this is defined I see that in
builtin_define_with_value
Variable buf is defined to:
"__LIBGCC_TEXT_SECTION_ASM_OP__=\"\t.section .text, \"axU\"\""
Which is then passed to: cpp_define (parse_in, buf);
I can workaround this In my port by adjusting the definition of text_section
but it is slightly annoying.
Do you have any hints as to why this happening and if there's a reasonable
workaround?
Also, if you're interested in this code (with any changes you might suggest) as
a patch, I am happy to prepare one.
Paulo Matos
RE: Documentation problem with TEXT_SECTION_ASM_OP
On Wed, 24 Oct 2012, Paulo Matos wrote:
> I gave it a go with TEXT_SECTION_ASM_OP.
Given what you've found, maybe other macros are easier to convert
> I started by changing crtstuff.c to use __LIBGCC_TEXT_SECTION_ASM_OP__
> instead of TEXT_SECTION_ASM_OP. I noticed crtstuff.c is not compiled
> with -fbuilding-libgcc so I added the flags to CRTSTUFF_T_CFLAGS in my
> makefile fragment.
That would seem to make sense anyway.
> /* For libgcc crtstuff.c. */
> #ifdef TEXT_SECTION_ASM_OP
> builtin_define_with_value ("__LIBGCC_TEXT_SECTION_ASM_OP__",
>TEXT_SECTION_ASM_OP, true);
> #else
> /* Is text_section always an unnamed section? */
> builtin_define_with_value ("__LIBGCC_TEXT_SECTION_ASM_OP__",
>(const char *)text_section->unnamed.data,
> true);
> #endif
> }
>
> The reason for the ifdef is because the docs allow the backend to define
> either TEXT_SECTION_ASM_OP or the text_section directly in
> TARGET_ASM_INIT_SECTIONS.
> Therefore if we don't have TEXT_SECTION_ASM_OP we need to grab the text
> string from text_section. I assumed text_section was defined in
> TARGET_ASM_INIT_SECTIONS with an unnamed section (that's how I did it)
> but I am unsure if this is a general assumption.
I don't like this #else. Presumably the libgcc code already works if
TEXT_SECTION_ASM_OP isn't defined at all. So the equivalent is simply not
to define __LIBGCC_TEXT_SECTION_ASM_OP__ in that case, rather than
synthesizing a definition from other information.
If however you want to synthesize a definition, then I think
TEXT_SECTION_ASM_OP should be converted to a target hook (at least to the
extent of targhooks.c being the only place testing it, if it remains at
all), so that the logic generating predefined macros is unconditional.
> #define __LIBGCC_TEXT_SECTION_ASM_OP__ ".section .text, "axU""
So you should teach builtin_define_with_value to generate proper escapes
when producing a string.
--
Joseph S. Myers
jos...@codesourcery.com
RE: Documentation problem with TEXT_SECTION_ASM_OP
> -Original Message- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: 24 October 2012 13:32 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: RE: Documentation problem with TEXT_SECTION_ASM_OP > > On Wed, 24 Oct 2012, Paulo Matos wrote: > > > I gave it a go with TEXT_SECTION_ASM_OP. > > Given what you've found, maybe other macros are easier to convert > Thanks for the comments. Even if they're easier to convert, I need TEXT_SECTION_ASM_OP to work so I will keep working on this. Will keep you up-to-date. Paulo Matos
Re: alias template bug?
> .. right now I can't really check, but looks like 54912 & co Hmm... is anybody actively working on this? It's breaking a lot of my code. I'd take a stab at fixing this, but not for the next couple of weeks. Andrew
Re: alias template bug?
On 10/24/2012 03:42 PM, Andrew Sutton wrote: .. right now I can't really check, but looks like 54912 & co Hmm... is anybody actively working on this? It's breaking a lot of my code. I'd take a stab at fixing this, but not for the next couple of weeks. It's a serious regression, thus will be definitely fixed in time for the release. That said, if you find the issue particularly urgent, help is definitely welcome, as usual! Paolo.
RE: Documentation problem with TEXT_SECTION_ASM_OP
> -Original Message- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: 24 October 2012 13:32 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: RE: Documentation problem with TEXT_SECTION_ASM_OP > > I don't like this #else. Presumably the libgcc code already works if > TEXT_SECTION_ASM_OP isn't defined at all. So the equivalent is simply not > to define __LIBGCC_TEXT_SECTION_ASM_OP__ in that case, rather than > synthesizing a definition from other information. > Let me add that I am not so sure about this. I arrived at this problem because I started defining text_section through TARGET_ASM_INIT_SECTIONS instead of TEXT_SECTION_ASM_OP and crtstuff.c started complaining during libgcc compile time that TEXT_SECTION_ASM_OP was not defined. I looked at most of the upstream backends and unfortunately none seem to not define TEXT_SECTION_ASM_OP even though according to the documents that's possible cause it allows you to define text_section through the TARGET_ASM_INIT_SECTIONS hook instead. Paulo Matos
Re: AIX trunk build fail #3
I thought I found a pilot error last night but it made no difference. I was calling "make" and not "make bootstrap". Part of my current difficulty is I do "make bootstrap" (on a 100% clean directory after configure) and it does as I reported before. If I then just do "make bootstrap" a second time, the build fails at a different place. > Checking multilib configuration for libatomic... > make[2]: Entering directory > `/usr/work/build/gcc.git/powerpc-ibm-aix6.1.0.0/libatomic' > Makefile:407: .deps/gcas.Plo: No such file or directory > Makefile:408: .deps/gexch.Plo: No such file or directory > Makefile:409: .deps/glfree.Plo: No such file or directory > Makefile:410: .deps/gload.Plo: No such file or directory > Makefile:411: .deps/gstore.Plo: No such file or directory > Makefile:412: .deps/init.Plo: No such file or directory > Makefile:413: .deps/lock.Plo: No such file or directory > make[2]: *** No rule to make target `.deps/lock.Plo'. Stop. > make[2]: Leaving directory > `/usr/work/build/gcc.git/powerpc-ibm-aix6.1.0.0/libatomic' > make[1]: *** [all-target-libatomic] Error 2 > make[1]: Leaving directory `/usr/work/build/gcc.git' > make: *** [bootstrap] Error 2 Can anyone help me figure out why the 2nd build dies in a different spot? Thank you, Perry Smith
RE: Documentation problem with TEXT_SECTION_ASM_OP
> -Original Message- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: 24 October 2012 13:32 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: RE: Documentation problem with TEXT_SECTION_ASM_OP > > > I don't like this #else. Presumably the libgcc code already works if > TEXT_SECTION_ASM_OP isn't defined at all. So the equivalent is simply not > to define __LIBGCC_TEXT_SECTION_ASM_OP__ in that case, rather than > synthesizing a definition from other information. > > If however you want to synthesize a definition, then I think > TEXT_SECTION_ASM_OP should be converted to a target hook (at least to > the > extent of targhooks.c being the only place testing it, if it remains at > all), so that the logic generating predefined macros is unconditional. > I think we might really need to synthesize it since as I said before I don't think crtstuff.c is ok with it if TEXT_SECTION_ASM_OP is not defined. I will look into the best way to do that. > > #define __LIBGCC_TEXT_SECTION_ASM_OP__ ".section .text, "axU"" > > So you should teach builtin_define_with_value to generate proper escapes > when producing a string. > I am slightly amazed that nothing implemented this before in GCC. I have defined a simple function that deals with the most used escapes. Is there a better source of allowed escapes in GCC besides looking into the lexer? Are these changes to handling of TEXT_SECTION_ASM_OP interesting for GCC? If they are I will look further into improving the code and turning it into a patch. Cheers, Paulo Matos
Re: if-conversion/HOT-COLD partitioning
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. merge_if_block calls merge_blocks unconditionally several times (in my case, the wrong one is merge_blocks (combo_bb, join_bb)). Christophe.
Re: AIX trunk build fail #3
On 24 October 2012 15:10, Perry Smith wrote: > I thought I found a pilot error last night but it made no difference. I was > calling "make" and not "make bootstrap". Just "make" is correct, and has been for many years now.
Re: AIX trunk build fail #3
On Oct 24, 2012, at 11:20 AM, Jonathan Wakely wrote: > On 24 October 2012 15:10, Perry Smith wrote: >> I thought I found a pilot error last night but it made no difference. I was >> calling "make" and not "make bootstrap". > > Just "make" is correct, and has been for many years now. Thanks. Any ideas of why it dies a different death the second pass? It makes debugging my original problem harder.
RE: Documentation problem with TEXT_SECTION_ASM_OP
On Wed, 24 Oct 2012, Paulo Matos wrote: > Are these changes to handling of TEXT_SECTION_ASM_OP interesting for > GCC? If they are I will look further into improving the code and turning > it into a patch. Conversions of target macros to hooks are generally of interest. I don't think we want a stream-of-consciousness sequence of messages about successive aspects of the issue. Rather, when you are ready, send to gcc-patches a patch (or patch series) with a thorough self-contained analysis of the issue, the approach your patch uses to tackle it and the rationale for that approach. Explain in your message what TEXT_SECTION_ASM_OP is, what its semantics are, how it relates to the mechanisms for section selection in GCC, how it is used in different parts of GCC and how your patch cleans things up and addresses identified issues around this macro. -- Joseph S. Myers jos...@codesourcery.com
Retrieve GENERIC function body in plugin
Hi, I am writing a plugin to analyse C code by walking the AST in GENERIC format, and have trouble getting the body of function declarations. The plugin registers a callback to PLUGIN_FINISH_UNIT, and therein retrieves function_decl nodes of the current translation unit by iterating over cgraph_nodes. However, getting the function body using DECL_SAVED_TREE(node) always returns NULL. I verified the output of -fdump-translation-unit, and there the function body is available, as output by DECL_SAVED_TREE in tree-dump.c. Am I hooking into the wrong plugin event, or is there something else that I am missing? Thanks, Peter
Re: if-conversion/HOT-COLD partitioning
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... > 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. Ciao! Steven
Bootstrap broken on rs6000
Hello,
../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
rs6000_density_test(rs6000_cost_data*)':
../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
was not declared in this scope
This is due to:
2012-10-24 Sharad Singhai
* dumpfile.c (dump_enabled_p): Make it inline and move the definition
to dumpfile.h.
(dump_kind_p): Deleted. Functionality replaced by dump_enabled_p.
Make alt_dump_file extern.
* dumpfile.h (dump_enabled_p): Move inline definition here.
(dump_kind_p): Delete declaration.
...
It's kinda nice to check target code as well when changing things... ;-)
Is the change at the bottom of this email correct?
Ciao!
Steven
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision 192780)
+++ config/rs6000/rs6000.c (working copy)
@@ -3547,7 +3547,7 @@ rs6000_density_test (rs6000_cost_data *data)
&& vec_cost + not_vec_cost > DENSITY_SIZE_THRESHOLD)
{
data->cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
- if (dump_kind_p (MSG_NOTE))
+ if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
"density %d%%, cost %d exceeds threshold, penalizing "
"loop body cost by %d%%", density_pct,
Re: Bootstrap broken on rs6000
On Wed, Oct 24, 2012 at 2:13 PM, Steven Bosscher wrote:
> Hello,
>
> ../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
> rs6000_density_test(rs6000_cost_data*)':
> ../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
> was not declared in this scope
>
> This is due to:
>
> 2012-10-24 Sharad Singhai
>
> * dumpfile.c (dump_enabled_p): Make it inline and move the definition
> to dumpfile.h.
> (dump_kind_p): Deleted. Functionality replaced by dump_enabled_p.
> Make alt_dump_file extern.
> * dumpfile.h (dump_enabled_p): Move inline definition here.
> (dump_kind_p): Delete declaration.
> ...
>
> It's kinda nice to check target code as well when changing things... ;-)
Sorry about that. Will do so in future.
> Is the change at the bottom of this email correct?
Yes, that is correct. If there are any more instances of dump_kind_p
(), they should be replaced by dump_enabled_p () as well.
Thanks,
Sharad
>
> Ciao!
> Steven
>
>
> Index: config/rs6000/rs6000.c
> ===
> --- config/rs6000/rs6000.c (revision 192780)
> +++ config/rs6000/rs6000.c (working copy)
> @@ -3547,7 +3547,7 @@ rs6000_density_test (rs6000_cost_data *data)
>&& vec_cost + not_vec_cost > DENSITY_SIZE_THRESHOLD)
> {
>data->cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
> - if (dump_kind_p (MSG_NOTE))
> + if (dump_enabled_p ())
> dump_printf_loc (MSG_NOTE, vect_location,
> "density %d%%, cost %d exceeds threshold, penalizing
> "
> "loop body cost by %d%%", density_pct,
Re: Retrieve GENERIC function body in plugin
On Wed, Oct 24, 2012 at 12:55:23PM -0400, Peter Colberg wrote: > The plugin registers a callback to PLUGIN_FINISH_UNIT, and therein > retrieves function_decl nodes of the current translation unit by > iterating over cgraph_nodes. However, getting the function body > using DECL_SAVED_TREE(node) always returns NULL. Never mind, I figured out a solution. One may register a callback for PLUGIN_PRE_GENERICIZE, which receives a function declaration as the first argument. This declaration contains the body. Peter
Re: Documentation problem with TEXT_SECTION_ASM_OP
On 24/10/12 17:30, Joseph S. Myers wrote: On Wed, 24 Oct 2012, Paulo Matos wrote: Conversions of target macros to hooks are generally of interest. I don't think we want a stream-of-consciousness sequence of messages about successive aspects of the issue. I apologize if my messages became a nuisance. My aim was to ensure the code would meet GCC standards before sending a patch, instead of sending a patch and seeing it being ignored because it was far from what the maintainers expected. I will however, get a patch ready and send it in. Cheers, -- PMatos
Re: Bootstrap broken on rs6000
Is someone going to apply this patch?
Thanks, David
On Wed, Oct 24, 2012 at 5:18 PM, Sharad Singhai wrote:
> On Wed, Oct 24, 2012 at 2:13 PM, Steven Bosscher
> wrote:
>> Hello,
>>
>> ../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
>> rs6000_density_test(rs6000_cost_data*)':
>> ../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
>> was not declared in this scope
>>
>> This is due to:
>>
>> 2012-10-24 Sharad Singhai
>>
>> * dumpfile.c (dump_enabled_p): Make it inline and move the definition
>> to dumpfile.h.
>> (dump_kind_p): Deleted. Functionality replaced by dump_enabled_p.
>> Make alt_dump_file extern.
>> * dumpfile.h (dump_enabled_p): Move inline definition here.
>> (dump_kind_p): Delete declaration.
>> ...
>>
>> It's kinda nice to check target code as well when changing things... ;-)
>
> Sorry about that. Will do so in future.
>
>> Is the change at the bottom of this email correct?
>
> Yes, that is correct. If there are any more instances of dump_kind_p
> (), they should be replaced by dump_enabled_p () as well.
>
> Thanks,
> Sharad
>
>>
>> Ciao!
>> Steven
>>
>>
>> Index: config/rs6000/rs6000.c
>> ===
>> --- config/rs6000/rs6000.c (revision 192780)
>> +++ config/rs6000/rs6000.c (working copy)
>> @@ -3547,7 +3547,7 @@ rs6000_density_test (rs6000_cost_data *data)
>>&& vec_cost + not_vec_cost > DENSITY_SIZE_THRESHOLD)
>> {
>>data->cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
>> - if (dump_kind_p (MSG_NOTE))
>> + if (dump_enabled_p ())
>> dump_printf_loc (MSG_NOTE, vect_location,
>> "density %d%%, cost %d exceeds threshold,
>> penalizing "
>> "loop body cost by %d%%", density_pct,
Re: Bootstrap broken on rs6000
I thought Steven was going to do that. If not, I can apply it.
Thanks,
Sharad
Sharad
On Wed, Oct 24, 2012 at 4:00 PM, David Edelsohn wrote:
> Is someone going to apply this patch?
>
> Thanks, David
>
> On Wed, Oct 24, 2012 at 5:18 PM, Sharad Singhai wrote:
>> On Wed, Oct 24, 2012 at 2:13 PM, Steven Bosscher
>> wrote:
>>> Hello,
>>>
>>> ../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
>>> rs6000_density_test(rs6000_cost_data*)':
>>> ../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
>>> was not declared in this scope
>>>
>>> This is due to:
>>>
>>> 2012-10-24 Sharad Singhai
>>>
>>> * dumpfile.c (dump_enabled_p): Make it inline and move the
>>> definition
>>> to dumpfile.h.
>>> (dump_kind_p): Deleted. Functionality replaced by dump_enabled_p.
>>> Make alt_dump_file extern.
>>> * dumpfile.h (dump_enabled_p): Move inline definition here.
>>> (dump_kind_p): Delete declaration.
>>> ...
>>>
>>> It's kinda nice to check target code as well when changing things... ;-)
>>
>> Sorry about that. Will do so in future.
>>
>>> Is the change at the bottom of this email correct?
>>
>> Yes, that is correct. If there are any more instances of dump_kind_p
>> (), they should be replaced by dump_enabled_p () as well.
>>
>> Thanks,
>> Sharad
>>
>>>
>>> Ciao!
>>> Steven
>>>
>>>
>>> Index: config/rs6000/rs6000.c
>>> ===
>>> --- config/rs6000/rs6000.c (revision 192780)
>>> +++ config/rs6000/rs6000.c (working copy)
>>> @@ -3547,7 +3547,7 @@ rs6000_density_test (rs6000_cost_data *data)
>>>&& vec_cost + not_vec_cost > DENSITY_SIZE_THRESHOLD)
>>> {
>>>data->cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
>>> - if (dump_kind_p (MSG_NOTE))
>>> + if (dump_enabled_p ())
>>> dump_printf_loc (MSG_NOTE, vect_location,
>>> "density %d%%, cost %d exceeds threshold,
>>> penalizing "
>>> "loop body cost by %d%%", density_pct,
Re: Bootstrap broken on rs6000
Committed in r192788.
Thanks,
Sharad
Sharad
On Wed, Oct 24, 2012 at 4:02 PM, Sharad Singhai wrote:
> I thought Steven was going to do that. If not, I can apply it.
>
> Thanks,
> Sharad
> Sharad
>
>
> On Wed, Oct 24, 2012 at 4:00 PM, David Edelsohn wrote:
>> Is someone going to apply this patch?
>>
>> Thanks, David
>>
>> On Wed, Oct 24, 2012 at 5:18 PM, Sharad Singhai wrote:
>>> On Wed, Oct 24, 2012 at 2:13 PM, Steven Bosscher
>>> wrote:
Hello,
../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
rs6000_density_test(rs6000_cost_data*)':
../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
was not declared in this scope
This is due to:
2012-10-24 Sharad Singhai
* dumpfile.c (dump_enabled_p): Make it inline and move the
definition
to dumpfile.h.
(dump_kind_p): Deleted. Functionality replaced by dump_enabled_p.
Make alt_dump_file extern.
* dumpfile.h (dump_enabled_p): Move inline definition here.
(dump_kind_p): Delete declaration.
...
It's kinda nice to check target code as well when changing things... ;-)
>>>
>>> Sorry about that. Will do so in future.
>>>
Is the change at the bottom of this email correct?
>>>
>>> Yes, that is correct. If there are any more instances of dump_kind_p
>>> (), they should be replaced by dump_enabled_p () as well.
>>>
>>> Thanks,
>>> Sharad
>>>
Ciao!
Steven
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision 192780)
+++ config/rs6000/rs6000.c (working copy)
@@ -3547,7 +3547,7 @@ rs6000_density_test (rs6000_cost_data *data)
&& vec_cost + not_vec_cost > DENSITY_SIZE_THRESHOLD)
{
data->cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
- if (dump_kind_p (MSG_NOTE))
+ if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
"density %d%%, cost %d exceeds threshold,
penalizing "
"loop body cost by %d%%", density_pct,
Re: i386 --with-abi={x32|32|64} extending multiarch ....
On Mon, Oct 22, 2012 at 10:15 AM, Gregory Nietsky wrote: > > In using 4.7.2 and am working on extending our distro to have > x86/x86_64/x32/arm > > Ive yanked the H.Lu patch to add --with-abi support from trunk and am > extending it to > have a default 32bit ABI we have nicknamed this the LOTR compiler [One > compiler to compile them all] [for the i386 at least] > > with out the support for --with-abi=32 i would not be able to cheat and ship > the x86_64 compiler as default on i686 with the ability > to x compile to 64/x32 built in also this allows been run on 64 bit as a > universal intel compiler i find this appealing as a "seed/bootstrap" > compiler > and this will be on our repository. > > if there is any interest im happy to supply the patch when tested and we > happy. Does trunk work OK? If not, please submit a patch for trunk. If yes, please try hjl/x32/gcc-4_7-branch branch. -- H.J.
Re: AIX trunk build fail #3
On Oct 24, 2012, at 11:28 AM, Perry Smith wrote: > > On Oct 24, 2012, at 11:20 AM, Jonathan Wakely wrote: > >> On 24 October 2012 15:10, Perry Smith wrote: >>> I thought I found a pilot error last night but it made no difference. I >>> was calling "make" and not "make bootstrap". >> >> Just "make" is correct, and has been for many years now. > > Thanks. Any ideas of why it dies a different death the second pass? It > makes debugging my original problem harder. To recap, there are two questions: 2) why does "make" a second time go down a different path? The reason is because powerpc-ibm-aix6.1.0.0/libatomic exists and the code for configure-target-libatomic (and others) does an exit 0 if the directory exists (assuming all is well and good). Otherwise, it continues on and does work. So... there needs to be a catch to delete the directory when something fails (which may be a really bad idea) or touch a file when it is done to know that it completed successfully. Testing just the directory (which is created at the start of the processing) is not correct. 1b) What is the story of LD_LIBRARY_PATH? AIX started looking at LD_LIBRARY_PATH in 6.1 gold. You can do a search of LD_LIBRARY_PATH here http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp and get some hits. Not sure why Google didn't cough that out previously. It usually does. Note: some people may find searching for LDR_PRELOAD interesting as well. I didn't take the time to fully read it and understand it. 1a) why is the configure failing? Because LD_LIBRARY_PATH is being set to the 64 bit path on the invocation of xgcc (and cc1). So, the loader tries to load the libraries from the path it has been told to load them from. I'm not clear why LD_LIBRARY_PATH is now being set. 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. 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. Thank you, Perry Smith
