Re: GCC online documentation
On 28 June 2011 09:44, Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > "GCC 4.6.1 Standard C++ Library Manual" and "GCC 4.6.1 Standard C++ Library > Reference Manual" missing. > > http://gcc.gnu.org/onlinedocs/gcc-4.6.1/libstdc++/manual/spine.html > > Not Found > > The requested URL /onlinedocs/gcc-4.6.1/libstdc++/manual/spine.html was not > found on this server. > Apache/2.0.52 (Red Hat) Server at gcc.gnu.org Port 80 I'm not sure if someone needs to generate those libstdc++ docs manually. Gerald or Benjamin should know.
Re: GSoC libgomp task project: What should I do next?
Sho Nakatani wrote: > Then I would like to ask you what I should do next. > > (A) Try to change implementation of libgomp following > my current implementation. >Then test and evaluate it using some applications. >(I think Barcelona OpenMP Task Suite [3] contains good applications >to test OpenMP Task implementations) I think it makes sense to start working on libgomp; even if the chosen implementation is not perfect, one can make real-world experiments with it. Additionally, to be used at the end, it has to end up in libgomp. Tobias
Re: [google] Merged gcc-4_6-branch -> google/gcc-4_6
Hi, On Tue, Jun 28, 2011 at 05:06:34PM -0400, Diego Novillo wrote: > This merge brings google/gcc-4_6 up to date with the recently > released 4.6.1 (rev 175583). > > Since there was some interest in a few fixes in the upstream > branch, these are the revisions that made it through in this > merge. > > Ollie, Martin's fix to PR 49516 will be committed in the next few > days. If needed, we could take his fix directly from trunk. The fix for 49094 had to be changed and is still being tested, even for trunk, and thus I have committed a 4.6 "backport" of the fix for PR 49516 on its own today (as revision 175634). Nevertheles yes, the patch is exactly the same, only with a minor line offset. Martin > > Validated on x86_64. > > > Diego. > > > r175024 | jakub | 2011-06-14 11:01:10 -0400 (Tue, 14 Jun 2011) | 9 lines > > PR rtl-optimization/49390 > Revert: > 2010-06-29 Bernd Schmidt > > * cse.c (exp_equiv_p): For MEMs, if for_gcse, only compare > MEM_ALIAS_SET. > > * gcc.c-torture/execute/pr49390.c: New test. > > r175029 | jakub | 2011-06-14 11:28:21 -0400 (Tue, 14 Jun 2011) | 11 lines > > PR fortran/49103 > * tree.h (DECL_NONSHAREABLE): Define. > (struct tree_decl_common): Change decl_common_unused to > decl_nonshareable_flag. > * cfgexpand.c (expand_used_vars_for_block, clear_tree_used): > Ignore vars with DECL_NONSHAREABLE bit set. > * tree-cfg.c (gimple_duplicate_bb): Set DECL_NONSHAREABLE > on stores to automatic aggregate vars. > > * gfortran.dg/pr49103.f90: New test. > > r175048 | rth | 2011-06-14 15:12:53 -0400 (Tue, 14 Jun 2011) | 18 lines > > Backport from mainline > 2011-03-22 Richard Henderson > > * config/avr/avr.c (TARGET_EXCEPT_UNWIND_INFO): New. > (avr_incoming_return_addr_rtx): New. > (emit_push_byte): New. > (expand_prologue): Use it. Remove incorrect dwarf annotation for > SREG, RAMPZ, zero register. Push frame pointer by bytes. Add dwarf > annotation for __prologue_saves__. Fixup dwarf annotation for CFA. > (emit_pop_byte): New. > (expand_epilogue): Use it. Pop frame pointer by bytes. > * config/avr/avr.h (FRAME_POINTER_CFA_OFFSET): Remove. > (INCOMING_RETURN_ADDR_RTX): New. > (INCOMING_FRAME_SP_OFFSET): New. > (ARG_POINTER_CFA_OFFSET): New. > * config/avr/avr.md (*pushqi): Fix mode of auto-inc. > (*pushhi, *pushsi, *pushsf, popqi): Likewise. > (pophi): Remove. > > r175049 | rth | 2011-06-14 15:13:00 -0400 (Tue, 14 Jun 2011) | 5 lines > > PR debug/48459 > * dwarf2out.c (frame_pointer_fb_offset_valid): New. > (based_loc_descr): Assert it's true. > (compute_frame_pointer_to_fb_displacement): Set it, rather than > aborting immediately. > > r175058 | jason | 2011-06-14 18:13:19 -0400 (Tue, 14 Jun 2011) | 2 lines > > PR c++/49290 > * semantics.c (cxx_eval_indirect_ref): Remove assert. > > r175059 | jason | 2011-06-14 18:13:29 -0400 (Tue, 14 Jun 2011) | 2 lines > > PR c++/49369 > * class.c (build_base_path): Fix cv-quals in unevaluated context. > > r175060 | jason | 2011-06-14 18:13:36 -0400 (Tue, 14 Jun 2011) | 3 lines > > PR c++/49117 > * call.c (perform_implicit_conversion_flags): Print source type as > well as expression. > > r175061 | jason | 2011-06-14 18:13:45 -0400 (Tue, 14 Jun 2011) | 1 line > > * error.c (type_to_string): Print typedef-stripped version too. > > r175069 | gccadmin | 2011-06-14 20:18:32 -0400 (Tue, 14 Jun 2011) | 1 line > > Daily bump. > > r175087 | gccadmin | 2011-06-15 20:18:11 -0400 (Wed, 15 Jun 2011) | 1 line > > Daily bump. > > r175094 | jakub | 2011-06-16 03:52:44 -0400 (Thu, 16 Jun 2011) | 16 lines > > Backported from mainline > 2011-06-13 Edmar Wienskoski > > PR target/44618 > * config/rs6000/rs6000.md (save_gpregs_): Replaced pattern > with a set of similar patterns, where the MATCH_OPERAND for the > function argument is replaced with individual references to hardware > registers. > (save_fpregs_): Ditto > (restore_gpregs_): Ditto > (return_and_restore_gpregs_): Ditto > (return_and_restore_fpregs_): Ditto > (return_and_restore_fpregs_aix_): Ditto > > * gcc.target/powerpc/outofline_rnreg.c: New testcase. > > r175095 | jakub | 2011-06-16 03:54:43 -0400 (Thu, 16 Jun 2011) | 8 lines > > PR tree-optimization/49419 > * tree-vrp.c (execute_vrp): Call init_range_assertions > before estimate_numbers_of_iterations, call > free_number_of_iterations_estimates before calling > remove_range_assertions. > > * gcc.c-torture/execut
Re: [google] Merged gcc-4_6-branch -> google/gcc-4_6
On 11-06-29 11:42 , Martin Jambor wrote: The fix for 49094 had to be changed and is still being tested, even for trunk, and thus I have committed a 4.6 "backport" of the fix for PR 49516 on its own today (as revision 175634). Nevertheles yes, the patch is exactly the same, only with a minor line offset. Great, thanks. Diego.
Re: [google] Merged gcc-4_6-branch -> google/gcc-4_6
On Wed, Jun 29, 2011 at 10:42 AM, Martin Jambor wrote: > > The fix for 49094 had to be changed and is still being tested, even > for trunk, and thus I have committed a 4.6 "backport" of the fix for > PR 49516 on its own today (as revision 175634). Nevertheles yes, the > patch is exactly the same, only with a minor line offset. Great! Please cherry-pick that change into the google/gcc-4_6 branch. Ollie
nested switch optimization
Hello
i have code:
void a(int i)
{
switch(i)
{
default:
switch(i) // exactly that same i
{
case 0:
f0();
break;
case 1:
f1();
break;
case 2:
f2();
break;
case 3:
f3a();
break;
}
break;
case 3:
f3();
break;
case 4:
f4();
break;
}
}
will be possible to add optimization that merge this two (or more) switch in
one big one (even if inner one is from inline function?) and then use one jump
table for both switches?
goal is to made that previous switch work exactly like this switch:
void a(int i)
{
switch(i)
{
case 0:
f0();
break;
case 1:
f1();
break;
case 2:
f2();
break;
//case 3: ignored because you cant get here
//f3a();
//break;
case 3:
f3();
break;
case 4:
f4();
break;
}
}
propose of this is to made switch work better with c++ templates (especially
variadic one).
with that change you could easily modify number of cases in switch only editing
one value in template argument (or adding new argument).
Re: [google] Merged gcc-4_6-branch -> google/gcc-4_6
On Wed, Jun 29, 2011 at 12:24, Ollie Wild wrote: > On Wed, Jun 29, 2011 at 10:42 AM, Martin Jambor wrote: >> >> The fix for 49094 had to be changed and is still being tested, even >> for trunk, and thus I have committed a 4.6 "backport" of the fix for >> PR 49516 on its own today (as revision 175634). Nevertheles yes, the >> patch is exactly the same, only with a minor line offset. > > Great! Please cherry-pick that change into the google/gcc-4_6 branch. Sure. I'll cherry-pick it today. Diego.
Re: [google] Merged gcc-4_6-branch -> google/gcc-4_6
On Wed, Jun 29, 2011 at 11:24 AM, Ollie Wild wrote: > > On Wed, Jun 29, 2011 at 10:42 AM, Martin Jambor wrote: > > > > The fix for 49094 had to be changed and is still being tested, even > > for trunk, and thus I have committed a 4.6 "backport" of the fix for > > PR 49516 on its own today (as revision 175634). Nevertheles yes, the > > patch is exactly the same, only with a minor line offset. > > Great! Please cherry-pick that change into the google/gcc-4_6 branch. Oops! Wrong Martin. :-) Diego will merge this to the google/gcc-4_6 branch. Thanks for the fix! Ollie
Re: GSoC libgomp task project: What should I do next?
Hello Tobias, > I think it makes sense to start working on libgomp; even if the chosen > implementation is not perfect, one can make real-world experiments with > it. Additionally, to be used at the end, it has to end up in libgomp. Thank you for your advice. I'll work on libgomp soon. Sho Nakatani
Re: GSoC libgomp task project: What should I do next?
On Wed, Jun 29, 2011 at 02:49:05PM +0200, Tobias Burnus wrote: > Sho Nakatani wrote: > > Then I would like to ask you what I should do next. > > > > (A) Try to change implementation of libgomp following > > my current implementation. > >Then test and evaluate it using some applications. > >(I think Barcelona OpenMP Task Suite [3] contains good applications > >to test OpenMP Task implementations) > > I think it makes sense to start working on libgomp; even if the chosen > implementation is not perfect, one can make real-world experiments with > it. Additionally, to be used at the end, it has to end up in libgomp. Yeah. And, please post patches from time to time, even if they aren't completely finished, so that others can comment on them. Jakub
Re: GSoC libgomp task project: What should I do next?
Hi Jakub, > Yeah. And, please post patches from time to time, even if they aren't > completely finished, so that others can comment on them. OK. I'll work on it. Sho Nakatani
Re: nested switch optimization
"Marcin J." writes: > will be possible to add optimization that merge this two (or more) switch in > one big one (even if inner one is from inline function?) and then use one > jump table for both switches? Is it possible? Sure. It's quite a special case, though, so if it's enabled by default it would have to be really fast. Fortunately it's easy to find switch statements as they will be the last statement in a basic block. See gcc/tree-switch-conversion.c for ideas on how to approach this. Ian
clz pattern
Hi, I'm trying to utilize the clz pattern: (define_insn "clzhi2" [(set (match_operand:HI 0 "register_operand" "=r") (clz:HI (match_operand:HI 1 "register_operand" "r")))] "" "cntlz %0 %1") I can build a compiler successfully with this pattern, but I can't find any C source that will utilize this pattern. I was wondering how GCC utilizes these patterns (and others like it), which have a functionality that does not straightforwardly map to any C operator. Thanks, John Lu
Re: clz pattern
Lu, John schrieb: Hi, I'm trying to utilize the clz pattern: (define_insn "clzhi2" [(set (match_operand:HI 0 "register_operand" "=r") (clz:HI (match_operand:HI 1 "register_operand" "r")))] "" "cntlz %0 %1") I can build a compiler successfully with this pattern, but I can't find any C source that will utilize this pattern. I was wondering how GCC utilizes these patterns (and others like it), which have a functionality that does not straightforwardly map to any C operator. Thanks, John Lu You can use it through __builtin_clz*, look for example into longlong.h. Johann
weak_global_object_name useless?
Adding gcc@gcc.gnu.org On Wed, Jun 29, 2011 at 6:08 PM, Gabriel Charette wrote: > > What's the purpose of weak_global_object_name? Defined in gcc/varasm.c > grepping from the base of the source recursively I only find this: > ./gcc/ChangeLog-1998: * varasm.c (assemble_start_function): Add > weak_global_object_name. > ./gcc/output.h:extern const char *weak_global_object_name; > ./gcc/ChangeLog-2000: weak_global_object_name here, as const char *. > ./gcc/ChangeLog-2000: first_global_object_name or weak_global_object_name. > Clean up string > ./gcc/ChangeLog-2000: * varasm.c (first_global_object_name, > weak_global_object_name): > ./gcc/tree.c: const char *name = weak_global_object_name; > ./gcc/ChangeLog-2005: (weak_global_object_name): Likewise. > ./gcc/varasm.c:extern GTY(()) const char *weak_global_object_name; > ./gcc/varasm.c:const char *weak_global_object_name; > ./gcc/varasm.c: Set first_global_object_name and weak_global_object_name as > appropriate. */ > ./gcc/varasm.c: type = &weak_global_object_name; > It seems like it's never actually set... some references to it are set... but > that seems like a very weird usage? And there is never any code that checks > whether `something == weak_global_object_name`... > I'm tempted to try to remove it... shall we ask Jason? > Gab
Re: weak_global_object_name useless?
On Wed, Jun 29, 2011 at 6:13 PM, Gabriel Charette wrote: > Adding gcc@gcc.gnu.org > > On Wed, Jun 29, 2011 at 6:08 PM, Gabriel Charette wrote: >> >> What's the purpose of weak_global_object_name? Defined in gcc/varasm.c >> grepping from the base of the source recursively I only find this: >> ./gcc/ChangeLog-1998: * varasm.c (assemble_start_function): Add >> weak_global_object_name. >> ./gcc/output.h:extern const char *weak_global_object_name; >> ./gcc/ChangeLog-2000: weak_global_object_name here, as const char *. >> ./gcc/ChangeLog-2000: first_global_object_name or weak_global_object_name. >> Clean up string >> ./gcc/ChangeLog-2000: * varasm.c (first_global_object_name, >> weak_global_object_name): >> ./gcc/tree.c: const char *name = weak_global_object_name; >> ./gcc/ChangeLog-2005: (weak_global_object_name): Likewise. >> ./gcc/varasm.c:extern GTY(()) const char *weak_global_object_name; >> ./gcc/varasm.c:const char *weak_global_object_name; >> ./gcc/varasm.c: Set first_global_object_name and weak_global_object_name >> as appropriate. */ >> ./gcc/varasm.c: type = &weak_global_object_name; >> It seems like it's never actually set... some references to it are set... >> but that seems like a very weird usage? And there is never any code that >> checks whether `something == weak_global_object_name`... >> I'm tempted to try to remove it... shall we ask Jason? It is set in notice_global_symbol if I read the code correctly. *type is either weak_global_object_name or first_global_object_name. If first_global_object_name was set by this function, then weak_global_object_name would never be set. Otherwise weak_global_object_name is set to the first time notice_global_symbol is called with a weak decl, or an one only decl, or when flag_shlib is true. get_file_function_name uses weak_global_object_name if first_global_object_name was not set. The purpose is the name of the first weak global symbol to create a name which is uniq at link time. get_file_function_name uses it to create a semi uniq number. Thanks, Andrew Pinski
Re: weak_global_object_name useless?
On Wed, Jun 29, 2011 at 6:26 PM, Andrew Pinski wrote: > On Wed, Jun 29, 2011 at 6:13 PM, Gabriel Charette wrote: >> Adding gcc@gcc.gnu.org >> >> On Wed, Jun 29, 2011 at 6:08 PM, Gabriel Charette wrote: >>> >>> What's the purpose of weak_global_object_name? Defined in gcc/varasm.c >>> grepping from the base of the source recursively I only find this: >>> ./gcc/ChangeLog-1998: * varasm.c (assemble_start_function): Add >>> weak_global_object_name. >>> ./gcc/output.h:extern const char *weak_global_object_name; >>> ./gcc/ChangeLog-2000: weak_global_object_name here, as const char *. >>> ./gcc/ChangeLog-2000: first_global_object_name or weak_global_object_name. >>> Clean up string >>> ./gcc/ChangeLog-2000: * varasm.c (first_global_object_name, >>> weak_global_object_name): >>> ./gcc/tree.c: const char *name = weak_global_object_name; >>> ./gcc/ChangeLog-2005: (weak_global_object_name): Likewise. >>> ./gcc/varasm.c:extern GTY(()) const char *weak_global_object_name; >>> ./gcc/varasm.c:const char *weak_global_object_name; >>> ./gcc/varasm.c: Set first_global_object_name and weak_global_object_name >>> as appropriate. */ >>> ./gcc/varasm.c: type = &weak_global_object_name; >>> It seems like it's never actually set... some references to it are set... >>> but that seems like a very weird usage? And there is never any code that >>> checks whether `something == weak_global_object_name`... >>> I'm tempted to try to remove it... shall we ask Jason? > > It is set in notice_global_symbol if I read the code correctly. > *type is either weak_global_object_name or first_global_object_name. > If first_global_object_name was set by this function, then > weak_global_object_name would never be set. Otherwise > weak_global_object_name is set to the first time notice_global_symbol > is called with a weak decl, or an one only decl, or when flag_shlib is > true. > get_file_function_name uses weak_global_object_name if > first_global_object_name was not set. > The purpose is the name of the first weak global symbol to create a > name which is uniq at link time. > get_file_function_name uses it to create a semi uniq number. I should mention the easiest way to get weak_global_object_name set is to use -fPIC when compiling since that sets flag_shlib to true. Thanks, Andrew Pinski
Re: weak_global_object_name useless?
Well looking at notice_global_symbol: The comments says that weak_global_object_name is set in it, but there is nothing actually doing so... The only line of code containing weak_global_object_name in notice_global_symbol is: type = &weak_global_object_name; Gab On Wed, Jun 29, 2011 at 6:26 PM, Andrew Pinski wrote: > On Wed, Jun 29, 2011 at 6:13 PM, Gabriel Charette wrote: >> Adding gcc@gcc.gnu.org >> >> On Wed, Jun 29, 2011 at 6:08 PM, Gabriel Charette wrote: >>> >>> What's the purpose of weak_global_object_name? Defined in gcc/varasm.c >>> grepping from the base of the source recursively I only find this: >>> ./gcc/ChangeLog-1998: * varasm.c (assemble_start_function): Add >>> weak_global_object_name. >>> ./gcc/output.h:extern const char *weak_global_object_name; >>> ./gcc/ChangeLog-2000: weak_global_object_name here, as const char *. >>> ./gcc/ChangeLog-2000: first_global_object_name or weak_global_object_name. >>> Clean up string >>> ./gcc/ChangeLog-2000: * varasm.c (first_global_object_name, >>> weak_global_object_name): >>> ./gcc/tree.c: const char *name = weak_global_object_name; >>> ./gcc/ChangeLog-2005: (weak_global_object_name): Likewise. >>> ./gcc/varasm.c:extern GTY(()) const char *weak_global_object_name; >>> ./gcc/varasm.c:const char *weak_global_object_name; >>> ./gcc/varasm.c: Set first_global_object_name and weak_global_object_name >>> as appropriate. */ >>> ./gcc/varasm.c: type = &weak_global_object_name; >>> It seems like it's never actually set... some references to it are set... >>> but that seems like a very weird usage? And there is never any code that >>> checks whether `something == weak_global_object_name`... >>> I'm tempted to try to remove it... shall we ask Jason? > > It is set in notice_global_symbol if I read the code correctly. > *type is either weak_global_object_name or first_global_object_name. > If first_global_object_name was set by this function, then > weak_global_object_name would never be set. Otherwise > weak_global_object_name is set to the first time notice_global_symbol > is called with a weak decl, or an one only decl, or when flag_shlib is > true. > get_file_function_name uses weak_global_object_name if > first_global_object_name was not set. > The purpose is the name of the first weak global symbol to create a > name which is uniq at link time. > get_file_function_name uses it to create a semi uniq number. > > Thanks, > Andrew Pinski >
Re: weak_global_object_name useless?
On Wed, Jun 29, 2011 at 6:44 PM, Gabriel Charette wrote: > Well looking at notice_global_symbol: > > The comments says that weak_global_object_name is set in it, but there > is nothing actually doing so... > > The only line of code containing weak_global_object_name in > notice_global_symbol is: > type = &weak_global_object_name; > *type = name; does the setting. Thanks, Andrew Pinski
Re: weak_global_object_name useless?
Aaah my bad! Thanks, Gab On Wed, Jun 29, 2011 at 6:45 PM, Andrew Pinski wrote: > On Wed, Jun 29, 2011 at 6:44 PM, Gabriel Charette wrote: >> Well looking at notice_global_symbol: >> >> The comments says that weak_global_object_name is set in it, but there >> is nothing actually doing so... >> >> The only line of code containing weak_global_object_name in >> notice_global_symbol is: >> type = &weak_global_object_name; >> > > *type = name; > does the setting. > > Thanks, > Andrew Pinski >
