Should warning of -Wunreachable-code be generated when optimization is taken?
Hi,
I run into such an XPASS for trunck. And it seems an old problem.
XPASS: gcc.dg/Wunreachable-8.c (test for bogus messages, line 7)
/* { dg-do compile } */
/* { dg-options "-O2 -Wunreachable-code" } */
float Factorial(float X)
{
float val = 1.0;
int k,j;
for (k=1; k < 5; k++) /* { dg-bogus "will never be executed" "" {
xfail *-*-* } } */
{
val += 1.0; /* { dg-bogus "will never be executed" "" { xfail *-*-* } } */
}
return (val); /* { dg-bogus "will never be executed" } */
}
The warning is generated during remove_bb in
pass_complete_unrolli. It's odd that after complete unrolling, there
is one redundant iteration bb.
(gdb) p debug_function (current_function_decl,1)
Factorial (float X)
{
int k;
float val;
:
:
val_10 = 2.0e+0;
k_11 = 2;
:
# val_12 = PHI
# k_13 = PHI
:
val_14 = val_12 + 1.0e+0;
k_15 = k_13 + 1;
:
# val_16 = PHI
# k_17 = PHI
:
val_18 = val_16 + 1.0e+0;
k_19 = k_17 + 1;
:
# val_20 = PHI
# k_21 = PHI
:
val_22 = val_20 + 1.0e+0;
k_23 = k_21 + 1;
goto ;
:
val_5 = val_1 + 1.0e+0;
k_6 = k_2 + 1;
:
Invalid sum of outgoing probabilities 180.0%
Invalid sum of incoming frequencies 3600, should be 2000
# val_1 = PHI
# k_2 = PHI
if (1 == 0)
goto ;
else
goto ;
:
return val_1;
}
Regards,
Eric
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Mon, 2009-10-26 at 09:53 -0400, Jason Merrill wrote:
> On 10/26/2009 07:14 AM, Jakub Jelinek wrote:
> >> -/* Generate the mangled representation of TYPE for the typeinfo name.
> >> */
> >> +/* Generate the mangled representation of TYPE. */
> >>
> >> const char *
> >> -mangle_type_string_for_rtti (const tree type)
> >> +mangle_type_string (const tree type)
> >
> > Why this change?
>
> This change is part of reverting my earlier fake namespace patch.
>
> I agree with Jakub's other comments, though.
>
> Jason
Here's the updated patch.
2009-10-28 Jerry Quinn
* mangle.c (mangle_type_string_for_rtti): Revert r149964.
(needs_fake_anon): Likewise.
(write_name): Likewise.
(write_nested_name): Likewise.
* cp-tree.h (mangle_type_string_for_rtti): Likewise.
(get_anonymous_namespace): Likewise.
* name-lookup.c (get_anonymous_namespace_name): Likewise.
* rtti.c (tinfo_name): Insert '*' in front of private names.
(tinfo_base_init): Use it.
2009-10-28 Jerry Quinn
* libsupc++/tinfo.cc (operator=(const type_info&)): Compare by
pointer if name begins with '*'.
* libsupc++/typeinfo (type_info::name()): Likewise.
* libsupc++/tinfo2.cc (before): Likewise.
Index: gcc/cp/rtti.c
===
--- gcc/cp/rtti.c (revision 153489)
+++ gcc/cp/rtti.c (working copy)
@@ -102,7 +102,7 @@
static GTY (()) VEC(tinfo_s,gc) *tinfo_descs;
static tree ifnonnull (tree, tree);
-static tree tinfo_name (tree);
+static tree tinfo_name (tree, bool);
static tree build_dynamic_cast_1 (tree, tree, tsubst_flags_t);
static tree throw_bad_cast (void);
static tree throw_bad_typeid (void);
@@ -349,16 +349,30 @@
return exp;
}
-/* Generate the NTBS name of a type. */
+/* Generate the NTBS name of a type. If MARK_PRIVATE, put a '*' in
front so that
+ comparisons will be done by pointer rather than string comparison.
*/
static tree
-tinfo_name (tree type)
+tinfo_name (tree type, bool mark_private)
{
const char *name;
+ int length;
tree name_string;
- name = mangle_type_string_for_rtti (type);
- name_string = fix_string_type (build_string (strlen (name) + 1,
name));
- return name_string;
+ name = mangle_type_string (type);
+ length = strlen (name);
+
+ if (mark_private)
+{
+ /* Inject '*' at beginning of name to force pointer comparison.
*/
+ char* buf = (char*) XALLOCAVEC (char, length + 1);
+ buf[0] = '*';
+ memcpy (buf + 1, name, length);
+ name_string = build_string (length + 1, buf);
+}
+ else
+name_string = build_string (length + 1, name);
+
+ return fix_string_type (name_string);
}
/* Return a VAR_DECL for the internal ABI defined type_info object for
@@ -839,13 +853,12 @@
tree vtable_ptr;
{
-tree name_name;
+tree name_name, name_string;
/* Generate the NTBS array variable. */
tree name_type = build_cplus_array_type
(build_qualified_type (char_type_node, TYPE_QUAL_CONST),
NULL_TREE);
-tree name_string = tinfo_name (target);
/* Determine the name of the variable -- and remember with which
type it is associated. */
@@ -862,6 +875,7 @@
DECL_TINFO_P (name_decl) = 1;
set_linkage_according_to_type (target, name_decl);
import_export_decl (name_decl);
+name_string = tinfo_name (target, !TREE_PUBLIC (name_decl));
DECL_INITIAL (name_decl) = name_string;
mark_used (name_decl);
pushdecl_top_level_and_finish (name_decl, name_string);
Index: gcc/cp/ChangeLog
===
--- gcc/cp/ChangeLog(revision 153489)
+++ gcc/cp/ChangeLog(working copy)
@@ -1,3 +1,15 @@
+2009-10-28 Jerry Quinn
+
+ * mangle.c (mangle_type_string_for_rtti): Revert r149964.
+ (needs_fake_anon): Likewise.
+ (write_name): Likewise.
+ (write_nested_name): Likewise.
+ * cp-tree.h (mangle_type_string_for_rtti): Likewise.
+ (get_anonymous_namespace): Likewise.
+ * name-lookup.c (get_anonymous_namespace_name): Likewise.
+ * rtti.c (tinfo_name): Insert '*' in front of private names.
+ (tinfo_base_init): Use it.
+
2009-10-21 Jakub Jelinek
* mangle.c (finish_mangling_get_identifier): Use
Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c (revision 153489)
+++ gcc/cp/mangle.c (working copy)
@@ -105,10 +105,6 @@
static GTY (()) globals G;
-/* Whether or not to pretend that a static function is in an anonymous
- namespace. */
-static bool fake_anon_scope;
-
/* The obstack on which we build mangled names. */
static struct obstack *mangle_obstack;
@@ -734,20 +730,6 @@
}
}
-/* Since we now use strcmp to compare typeinfos on all targets because
of
- the RTLD_LOCAL problem, we need to munge the typeinfo name u
Re: Problems with selective scheduling
Thank you very much for your detailed response! > I suspect your machine description says that dependency between loads and > multiply-add has zero latency, thus allowing the scheduler to place them > into > one instruction group. Grep for various comments about tick_check_p > function. > In verbose scheduler dumps, there should be something like > > Expr 35 is not ready yet until cycle 2 > No best expr found! > Finished a cycle. Current cycle = 2 At a glance when compiling without the -fsel-sched-pipelining flag (but with -fselective-scheduling2) proper VLIW grouping is performed so I guess the dependency is not zero latency but I will try to investigate the details. Increasing verbosity and comparing dumps to ia64 will probably be helpful. > On the high level, yes. In this particular example, pipelining of loads > would > not be possible for the following reasons: > 1) speculative motion of loads with pre/post-increment is not implemented > (ia64 backend disables auto-inc generation pass when sel-sched is enabled); Is there a fundamental problem with pre/post-increment support in the selective scheduling approach or is this something that might be implemented in the future? > 2) when pipelining loads, scheduler needs to transform them into > control-speculative form (since loop epilogue is not generated, load on the > very last iteration of the transformed loop may access unallocated memory). > In other words, selective scheduler does not preserve number of instruction > executions (pipelined instructions from original loop will be executed more > times than number of loop iterations). > Speculative loads are not supported by any mainline GCC target except ia64. On my target it is always safe to performs loads so I suppose I could pretend to support speculative loads in order to get around this. /Markus
Puzzles about implementation of bb-reorder pass
Hi :
The bb-reorder pass is relative simple comparing with others, but still
I got following puzzles.
1 : the comment at top of the bb-reorder.c file says that :
There are two parameters: Branch Threshold and Exec Threshold.
If the edge to a successor of the actual basic block is lower than
Branch Threshold or the frequency of the successor is lower than
Exec Threshold the successor will be the seed in one of the next rounds.
but when computing which_heap in function "find_traces_1_round", it uses
push_to_next_round_p to decide whether the successor should go to next round,
which takes only exec_th as argument, not branch_th.
Is this inconsistent ?
2 : when checking for situation :
A
/ |
B |
\ |
C
gcc uses the condition
EDGE_FREQUENCY (AB) + EDGE_FREQUENCY (BC)
>= EDGE_FREQUENCY (AC).
what does "EDGE_FREQUENCY (AB) + EDGE_FREQUENCY (BC)"
stand for? Since edge B is dominated by A and C is the only successor,
the frequency of path(ABC) is less than path(AC), I think.
3 : It is possible to merge two traces by copying exactly one basic block.
gcc uses following code to take trace which has only one bb into consider:
if (bbd[e->dest->index].start_of_trace >= 0
&& traces[bbd[e->dest->index].start_of_trace].length
== 1)
{
best = e;
try_copy = true;
continue;
}
Here is the question, what about that trace has already been merged and has
no free successor traces(traces which start bb is the successor of
the single bb).
in this situation next_bb is NULL and all we did is just copy a
already merged bb.
Is this right?
Please correct me and help me out, Thanks.
--
Best Regards.
Re: plugin hooks
Hello All
Basile STARYNKEVITCH wrote:
Ian Lance Taylor wrote:
Basile STARYNKEVITCH writes:
* propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
Do this.
Will do probably tommorow or this evening!
I already did sent an initial proposal for the patch.
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01623.html
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Problems with selective scheduling
Hi Markus, Markus L wrote: Thank you very much for your detailed response! I suspect your machine description says that dependency between loads and multiply-add has zero latency, thus allowing the scheduler to place them into one instruction group. Grep for various comments about tick_check_p function. In verbose scheduler dumps, there should be something like Expr 35 is not ready yet until cycle 2 No best expr found! Finished a cycle. Current cycle = 2 At a glance when compiling without the -fsel-sched-pipelining flag (but with -fselective-scheduling2) proper VLIW grouping is performed so I guess the dependency is not zero latency but I will try to investigate the details. Increasing verbosity and comparing dumps to ia64 will probably be helpful. You are welcome to email me or Alexander if you'd need any help with debugging this. On the high level, yes. In this particular example, pipelining of loads would not be possible for the following reasons: 1) speculative motion of loads with pre/post-increment is not implemented (ia64 backend disables auto-inc generation pass when sel-sched is enabled); Is there a fundamental problem with pre/post-increment support in the selective scheduling approach or is this something that might be implemented in the future? There is no problem, we just didn't have time for this within the frames of that project. We are willing to tackle this within our spare time during next stage1, if we would have any. 2) when pipelining loads, scheduler needs to transform them into control-speculative form (since loop epilogue is not generated, load on the very last iteration of the transformed loop may access unallocated memory). In other words, selective scheduler does not preserve number of instruction executions (pipelined instructions from original loop will be executed more times than number of loop iterations). Speculative loads are not supported by any mainline GCC target except ia64. On my target it is always safe to performs loads so I suppose I could pretend to support speculative loads in order to get around this. That's good. You can check that VINSN_MAY_TRAP_P is false for your loads (it is set from haifa_classify_insn which in turn uses may_trap_exp). If this is the case, then you should be safe. Yours, Andrey /Markus
Re: enable-build-with-cxx bootstrap compare broken by r149964
On 10/28/2009 07:29 AM, Jerry Quinn wrote: + length = strlen (name); + if (mark_private) + name_string = build_string (length + 1, buf); + else +name_string = build_string (length + 1, name); These two calls shouldn't be using the same length. I think the +1 in the old code was unnecessary, so you can just remove it from the second call. Jason
Re: dg-error vs. i18n?
On Tue, 27 Oct 2009, Ross Ridge wrote: > Eric Blake writes: > >The correct workaround is indeed to specify a locale with specific charset > >encodings, rather than relying on plain "C" (hopefully cygwin will > >support "C.ASCII", if it does not already). > > The correct fix is for GCC not to intentionally choose to rely on > implementation defined behaviour when using the "C" locale. GCC can't > portably assume any other locale exists, but can portibly and easily > choose to get consistant output when using the "C" locale. GCC is behaving properly according to the user's locale (representing English-language diagnostics as best it can - remember that ASCII does not allow good representation of English in all cases). The problem here is not a bug in the compiler proper, it is an issue with how to test the compiler portably - that is, how the testsuite can portably set a locale with English language and ASCII character set in order to test the output the compiler gives in such a locale. (Ideally it would be possible for individual tests to specify other locale character sets to test the output given in those locales as well - for example, to test that in an ISO 8859-1 locale extended characters in identifiers that are in ISO 8859-1 are shown as is in diagnostics while those that are not in ISO 8859-1 are shown as UCNs.) -- Joseph S. Myers jos...@codesourcery.com
help on - writing a testcase to detect structural hazard in gcc
Hi All, Our project is to optimize instruction scheduling in gcc by detecting structural hazards. We looked at the current dfa implementation(gen-automata.c and insn-automata.c). We are trying to come up with a test case for the same, a scenario wherein one of the instructions is stalled due to the resource being used by some other instruction. However, we are unable to do so. 1. We wrote a C program - doing - floating point multiplications, divisions and additions. However in both the files - 'progname.s' file and 'progname.c.190r.sched2' file, the instructions were scheduled for execution in sequential order. We couldn't find a way to detect a stall, by looking at the assembly code generated. Question: How do we detect that a stall has occurred if execution is being carried out in a particular sequence? Also we would like to know of a tool, which given a 'progname.s' file, gives details of the execution time of each instruction and the clock cycle in which stall will occur, if execution is carried out in this sequence. 2. We saw that integer operations were already being performed during compilation. Hence we were left with only floating point operations to be looked into for structural hazards. Question: Once a stall is detected in case of floating point unit being used currently by some other instruction, which instruction can be scheduled in so as to avoid this stall(since integer operations are performed at compile time and floating point units are being used)? Target machine architecture: 686 Working on: Intel Pentium Dual Core processor Thanking you, Dhiraj -- View this message in context: http://www.nabble.com/help-on---writing-a-testcase-to-detect-structural-hazard-in-gcc-tp26098843p26098843.html Sent from the gcc - Dev mailing list archive at Nabble.com.
plugin specific LTO data?
Hello All,
Is there some way from a plugin to read and to write some plugin
specific LTO data?
When glancing in lto-streamer.h I believe I see no such things. But I
don't understand all the details.
I was thinking of e.g. functions like
void lto_input_plugin_data(struct lto_file_decl_data*file_data,
const char* plugin_name,
char **datap,
size_t*sizep);
A pass from the plugin FOO would call
char* mydata = NULL;
size_t mydatasize = 0;
lto_input_plugin_data(file_data, "FOO", &mydata, &mydatasize);
and then the buffer mydata would be malloc-ed by the LTO infrastructure
and it will be read, and mydatasize set to the size of the read data.
For writing, I would be happy with
void lto_output_plugin_data(struct lto_file_decl_data *file_data,
const char* plugin_name,
char* data, size_t size);
and the plugin would call
lto_output_plugin_data(file_data, "FOO", mydata, mysize);
Perhaps the lto_file_decl_data* type above is wrong (and should be
something else).
Is it too late to add such a simple functionality in the LTO infrastructure.
There are many possible usage for that. For example, imagine a plugin
which try to detect that every malloc() result has been tested against
null. To work between compilation unit, that plugin has to serialize
properties like "rootine foo returns a malloc()-ed pointer untested" etc.
Are there other alternatives?
BTW, the comment in lto-streamer.h near line 809 of rev 153460 reads
/* In lto-streamer-in.c */
extern void lto_input_cgraph (struct lto_file_decl_data *, const char*);
But I cannot find any lto_input_cgraph in rev 153460 of the trunk
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: dg-error vs. i18n?
Ross Ridge wrote: > The correct fix is for GCC not to intentionally choose to rely on > implementation defined behaviour when using the "C" locale. GCC can't > portably assume any other locale exists, but can portibly and easily > choose to get consistant output when using the "C" locale. Joseph S. Myers writes: >GCC is behaving properly according to the user's locale (representing >English-language diagnostics as best it can - remember that ASCII does not >allow good representation of English in all cases). This is an issue of style, but as I far as I'm concerned using these fancy quotes in English locales is unnecessary and unhelpful. >The problem here is not a bug in the compiler proper, it is an issue >with how to test the compiler portably - that is, how the testsuite can >portably set a locale with English language and ASCII character set in >order to test the output the compiler gives in such a locale. It's a design flaw in GCC. The "C" locale is the only locale that GCC can use to reliably and portably get consistant output across all ASCII systems and so should be the locale used to achieve consistant output. GCC can simply choose to restrict it's output to ASCII. It's not in any way being forced by POSIX to output non-ASCII characters, or for that matter to treat the "C" locale as an English locale. Ross Ridge
Re: plugin hooks
> We should add hooks as we find plugins that need them. Simply adding > a laundry list of hooks that we think might be needed will most likely > cause us to overdesign. We know that we can write interesting plugins > today, so we're not missing anything critical. > > I agree that it should be OK to add hooks in stage 3, if they are > clearly safe and clearly needed. Sorry for being late in joining the thread. I fully agree with this. We should add hooks as someone finds a need for it. Changes like this are likely to be safe, but I am not sure if they are stage3 OK. We should probably look at it in a case by case basis. > Ian > Cheers, -- Rafael Ávila de Espíndola
Re: plugin hooks
> I believe there is a strong chicken & egg issue here. Ian is suggesting that > hooks should be added only when an existing plugin would need them, but I > believe that on the contrary plugins won't appear if they don't have a > sufficient set of hooks. People won't even bother to make plugins if they > feel the set of hooks is blantly unsufficient. [They will either > experiment on their own GCC branch, or avoid GCC entirely, for instance > using LLVM instead]. But working on one's branch is much more painful > than coding a plugin! I don't see a chicken and egg problem. Your work on making the GC accessible to plugins is a good example why it is not :-) > I have a concrete example here: plugin-specific pragmas (see > PLUGIN_REGISTER_PRAGMA on http://gcc.gnu.org/wiki/plugin%20hook for > details) > > I have two imaginary use cases here. Sorry, the point is precisely that they should be concrete :-) If you are actually coding a plugin and get to the stage "ok, now I need a new hook", please send a patch adding the hook and a description of what the plugin is trying to do. Cheers, -- Rafael Ávila de Espíndola
Re: plugin hooks
> From several face to face discussions with ICI CTuning people (that it
> Grigori Fursin, Albert Cohen, Zbignew Chamski; all 3 are in CC of this
> reply) I understood that GCC ICI is exactly doing that: it has replaced GCC
> pass manager by its own, which invokes all the existing GCC passes in some
> better order (or better number of invocation) and produces better generated
> code (the tuning is done by machine learning techniques; they did run their
> modified GCC a large number of times and did build a database of measures.).
>
> I cannot explain more in details what GCC ICI is actually doing. I hope my
> ICI friends will answer here. Perhaps even Zbignew's latest patches are
> related to the answer.
We talked a bit in the summit about it. I think that the correct
solution is to make the gcc pass manager have the flexibility they
need so that their plugin can just call into the regular pass manager.
> Regards.
>
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
Cheers,
--
Rafael Ávila de Espíndola
Re: plugin hooks
Hello All Rafael Espindola wrote: I have a concrete example here: plugin-specific pragmas (see PLUGIN_REGISTER_PRAGMA on http://gcc.gnu.org/wiki/plugin%20hook for details) I have two imaginary use cases here. There are not so imaginary. I am sure I will need plugin specific pragmas in 2010. I explained why. But I also told that it is more than one man-year effort to exhibit a realistic plugin needing PLUGIN_REGISTER_PRAGMA People won't even bother to make plugins if they > feel the set of hooks is blantly unsufficient. [They will either > experiment on their own GCC branch, or avoid GCC entirely, for instance > using LLVM instead]. But working on one's branch is much more painful > than coding a plugin! I don't see a chicken and egg problem. Your work on making the GC accessible to plugins is a good example why it is not :-) Honestly, the [enormous in my view] effort I did make to push that GGC related features into the trunk have been disproportionately important w.r.t. the result. My work on GGC plugin events is precisely a good example of why I need to anticipate my plugin needs. Sorry, the point is precisely that they should be concrete :-) If you are actually coding a plugin and get to the stage "ok, now I need a new hook", please send a patch adding the hook and a description of what the plugin is trying to do. You are forgetting an important point in GCC. The majority of GCC users won't compile GCC. Actually, I have concrete experience that most GCC users are not even able (that is willing to make the effort) to compile it. They will use a GCC in some distributed *binary* form (e.g. the gcc-4.5 package of some future Ubuntu, Debian, ... distribution, released in mid 2010). So in christmas 2010, a recently released Ubuntu contains the gcc-4.5 package (the compiler) and the gcc-dev-4.5 package (enough to compile a gcc 4.5 plugin). Now I (Basile) have developed a plugin by that time which will use a PLUGIN_REGISTER_PRAGMA. If I requires its users to compile a gcc-trunk (since only after mid 2010 will I be able to really demonstrate a valid use of PLUGIN_REGISTER_PRAGMA), nobody -I really think not a single person- will use my plugin. If my plugin runs on a standard 4.5 binary distribution of gcc, I might have a few users! I really think we should add more plugin hooks *now* for gcc-4.5. They really cannot wait the future 4.6 release (in 2011, 2012?), especially since the patches adding them are so short. And by definition, these patches can't break anything [provided they don't hurt performance measurably on compilation not using plugins, this is why I wrote about plugin events whose invoke_plugin_callbacks is not called a million times but only a few dozen times... or perhaps a few hundred times on a big compilation. I mean that one additional invoke_plugin_callbacks at each pass execution is probably acceptable]. So adding new events should be done now. The PLUGIN_REGISTER_PRAGMA should not hurt performance of GCC, since its invoke_plugin_callbacks is called once for a whole cc1 process! And in a couple of years, indeed we might want to obsolete some plugin events (like we do obsolete some other features of GCC). Only time can tell which events are really useful. Mind you, the buying point for plugins is to avoid asking users to compile the entire GCC compiler but still have some extension ability. Nobody likes to do that, except we GCC hackers, and Linux distribution makers. Sometimes I have the intuition that several GCC people are afraid of plugins. I cannot understand why. When the Adobe Flash plugin crash in my Mozilla, I don't curse the Mozilla team, but Adobe (and of course the many sites using too much that proprietary technology). The main concern of the GCC community should not be abuse of plugins, it should be the survival of GCC in the long term. I really think we should help as much as possible plugins to be a success! And in my opinion, that means provide the necessary hooks in 4.5 [especially those for which the patch is tiny, like PLUGIN_REGISTER_PRAGMA] not in the trunk in a couple of years. This takes into account that GCC releases are quite a rare event (there is no major GCC release every 3 months). Regards PS. Are we absolutely sure that GCC will still be dominant in the compiler landscape five or ten years from now? I am not! PPS. I think that most north-american GCC hackers grossly underestimate the effort needed to push even a minor patch for e.g. european hackers. There are lot of issues (English language, timezone, lack of near collegues working on GCC and which I could meet in a few minutes, major cultural differences, market differences [most processor makers are not European]...) to consider -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions
Re: plugin specific LTO data?
On Wed, Oct 28, 2009 at 6:34 PM, Basile STARYNKEVITCH wrote: > Hello All, > > Is there some way from a plugin to read and to write some plugin specific > LTO data? > > When glancing in lto-streamer.h I believe I see no such things. But I don't > understand all the details. > > I was thinking of e.g. functions like > > void lto_input_plugin_data(struct lto_file_decl_data*file_data, > const char* plugin_name, > char **datap, > size_t*sizep); > > A pass from the plugin FOO would call > > char* mydata = NULL; > size_t mydatasize = 0; > lto_input_plugin_data(file_data, "FOO", &mydata, &mydatasize); > > and then the buffer mydata would be malloc-ed by the LTO infrastructure and > it will be read, and mydatasize set to the size of the read data. > > For writing, I would be happy with > > void lto_output_plugin_data(struct lto_file_decl_data *file_data, > const char* plugin_name, > char* data, size_t size); > > and the plugin would call > lto_output_plugin_data(file_data, "FOO", mydata, mysize); > > Perhaps the lto_file_decl_data* type above is wrong (and should be something > else). > > Is it too late to add such a simple functionality in the LTO infrastructure. You have to write an IPA pass, those can output/input pass specific data to the LTO sections. No need to add anything plugin specific. Richard.
Re: plugin hooks
On Wed, Oct 28, 2009 at 8:34 PM, Basile STARYNKEVITCH wrote: > Hello All > > Rafael Espindola wrote: >>> >>> I have a concrete example here: plugin-specific pragmas (see >>> PLUGIN_REGISTER_PRAGMA on http://gcc.gnu.org/wiki/plugin%20hook for >>> details) >>> >>> I have two imaginary use cases here. >> > > There are not so imaginary. I am sure I will need plugin specific pragmas in > 2010. I explained why. But I also told that it is more than one man-year > effort to exhibit a realistic plugin needing PLUGIN_REGISTER_PRAGMA > > >>> People won't even bother to make plugins if they >>> > feel the set of hooks is blantly unsufficient. [They will either >>> > experiment on their own GCC branch, or avoid GCC entirely, for instance >>> > using LLVM instead]. But working on one's branch is much more painful >>> > than coding a plugin! >> >> I don't see a chicken and egg problem. Your work on making the GC >> accessible to plugins is a good example why it is not :-) > > Honestly, the [enormous in my view] effort I did make to push that GGC > related features into the trunk have been disproportionately important > w.r.t. the result. My work on GGC plugin events is precisely a good example > of why I need to anticipate my plugin needs. > > >> Sorry, the point is precisely that they should be concrete :-) >> >> If you are actually coding a plugin and get to the stage "ok, now I >> need a new hook", please send a patch adding the hook and a >> description of what the plugin is trying to do. > > > You are forgetting an important point in GCC. > > The majority of GCC users won't compile GCC. Actually, I have concrete > experience that most GCC users are not even able (that is willing to make > the effort) to compile it. They will use a GCC in some distributed *binary* > form (e.g. the gcc-4.5 package of some future Ubuntu, Debian, ... > distribution, released in mid 2010). > > So in christmas 2010, a recently released Ubuntu contains the gcc-4.5 > package (the compiler) and the gcc-dev-4.5 package (enough to compile a gcc > 4.5 plugin). > > Now I (Basile) have developed a plugin by that time which will use a > PLUGIN_REGISTER_PRAGMA. If I requires its users to compile a gcc-trunk > (since only after mid 2010 will I be able to really demonstrate a valid use > of PLUGIN_REGISTER_PRAGMA), nobody -I really think not a single person- will > use my plugin. If my plugin runs on a standard 4.5 binary distribution of > gcc, I might have a few users! > > > I really think we should add more plugin hooks *now* for gcc-4.5. They > really cannot wait the future 4.6 release (in 2011, 2012?), especially since I don't agree at all. Also I have the feeling that plugins will in the end result in less developers on the core GCC infrastructure and thus plugins are bad for GCC. Richard.
Re: plugin hooks
Richard Guenther wrote:
On Wed, Oct 28, 2009 at 8:34 PM, Basile STARYNKEVITCH
wrote:
I really think we should add more plugin hooks *now* for gcc-4.5. They
really cannot wait the future 4.6 release (in 2011, 2012?), especially since
I don't agree at all. Also I have the feeling that plugins will in
the end result
in less developers on the core GCC infrastructure and thus plugins are bad
for GCC.
I respectfully disagree with Richard, and have the following opinion.
Because of plugins ability, some *more* people will learn a bit the
internals of GCC (enough to code their plugin) and amongst them, a few
people will eventually -later- join the core GCC developers (e.g.
because they need a hook). So the effect of plugins on the size of the
GCC community should be a gradual increase, not a regression!
The point is that plugins will enable unexpected usage of GCC, and this
is positive (and will bring gradually more people inside the community).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: when (not) use bugzilla for GCC?
Basile STARYNKEVITCH wrote:
Richard Guenther wrote:
On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor
wrote:
Basile STARYNKEVITCH writes:
Are you suggesting me to upload to bugzilla the nearly 3000
preprocessed forms of the files? I could do that, but the *.i files
totalize more than one gigabyte. A bzip2 compressed tar archive of
them is almost 80Mbytes.
I actually found that the bug is triggered by any gcc -flto -O2
compilation of a lot of files.
I submitted PRµ41858 with a tiny C-source file generator. So the example
main.c in the bugzilla is tiny, but able to generate a lot of source code.
I hope that this helps.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: enable-build-with-cxx bootstrap compare broken by r149964
On Wed, 2009-10-28 at 11:35 -0400, Jason Merrill wrote:
> On 10/28/2009 07:29 AM, Jerry Quinn wrote:
> > + length = strlen (name);
> > + if (mark_private)
> > + name_string = build_string (length + 1, buf);
> > + else
> > +name_string = build_string (length + 1, name);
>
> These two calls shouldn't be using the same length. I think the +1 in
> the old code was unnecessary, so you can just remove it from the second
> call.
And here is the latest patch.
Index: gcc/cp/rtti.c
===
--- gcc/cp/rtti.c (revision 153489)
+++ gcc/cp/rtti.c (working copy)
@@ -102,7 +102,7 @@
static GTY (()) VEC(tinfo_s,gc) *tinfo_descs;
static tree ifnonnull (tree, tree);
-static tree tinfo_name (tree);
+static tree tinfo_name (tree, bool);
static tree build_dynamic_cast_1 (tree, tree, tsubst_flags_t);
static tree throw_bad_cast (void);
static tree throw_bad_typeid (void);
@@ -349,16 +349,30 @@
return exp;
}
-/* Generate the NTBS name of a type. */
+/* Generate the NTBS name of a type. If MARK_PRIVATE, put a '*' in
front so that
+ comparisons will be done by pointer rather than string comparison.
*/
static tree
-tinfo_name (tree type)
+tinfo_name (tree type, bool mark_private)
{
const char *name;
+ int length;
tree name_string;
- name = mangle_type_string_for_rtti (type);
- name_string = fix_string_type (build_string (strlen (name) + 1,
name));
- return name_string;
+ name = mangle_type_string (type);
+ length = strlen (name);
+
+ if (mark_private)
+{
+ /* Inject '*' at beginning of name to force pointer comparison.
*/
+ char* buf = (char*) XALLOCAVEC (char, length + 1);
+ buf[0] = '*';
+ memcpy (buf + 1, name, length);
+ name_string = build_string (length + 1, buf);
+}
+ else
+name_string = build_string (length, name);
+
+ return fix_string_type (name_string);
}
/* Return a VAR_DECL for the internal ABI defined type_info object for
@@ -839,13 +853,12 @@
tree vtable_ptr;
{
-tree name_name;
+tree name_name, name_string;
/* Generate the NTBS array variable. */
tree name_type = build_cplus_array_type
(build_qualified_type (char_type_node, TYPE_QUAL_CONST),
NULL_TREE);
-tree name_string = tinfo_name (target);
/* Determine the name of the variable -- and remember with which
type it is associated. */
@@ -862,6 +875,7 @@
DECL_TINFO_P (name_decl) = 1;
set_linkage_according_to_type (target, name_decl);
import_export_decl (name_decl);
+name_string = tinfo_name (target, !TREE_PUBLIC (name_decl));
DECL_INITIAL (name_decl) = name_string;
mark_used (name_decl);
pushdecl_top_level_and_finish (name_decl, name_string);
Index: gcc/cp/ChangeLog
===
--- gcc/cp/ChangeLog(revision 153489)
+++ gcc/cp/ChangeLog(working copy)
@@ -1,3 +1,15 @@
+2009-10-28 Jerry Quinn
+
+ * mangle.c (mangle_type_string_for_rtti): Revert r149964.
+ (needs_fake_anon): Likewise.
+ (write_name): Likewise.
+ (write_nested_name): Likewise.
+ * cp-tree.h (mangle_type_string_for_rtti): Likewise.
+ (get_anonymous_namespace): Likewise.
+ * name-lookup.c (get_anonymous_namespace_name): Likewise.
+ * rtti.c (tinfo_name): Insert '*' in front of private names.
+ (tinfo_base_init): Use it.
+
2009-10-21 Jakub Jelinek
* mangle.c (finish_mangling_get_identifier): Use
Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c (revision 153489)
+++ gcc/cp/mangle.c (working copy)
@@ -105,10 +105,6 @@
static GTY (()) globals G;
-/* Whether or not to pretend that a static function is in an anonymous
- namespace. */
-static bool fake_anon_scope;
-
/* The obstack on which we build mangled names. */
static struct obstack *mangle_obstack;
@@ -734,20 +730,6 @@
}
}
-/* Since we now use strcmp to compare typeinfos on all targets because
of
- the RTLD_LOCAL problem, we need to munge the typeinfo name used for
- local classes of static functions to fix g++.dg/abi/local1.C. We do
- that by pretending that the function is in an anonymous namespace.
*/
-
-static bool
-needs_fake_anon (const_tree decl)
-{
- /* Pretend there's an anonymous namespace right around a static
- function if we're mangling for RTTI. */
- return (fake_anon_scope && !TREE_PUBLIC (decl)
- && TREE_CODE (decl) == FUNCTION_DECL);
-}
-
/* Lambdas can have a bit more context for mangling, specifically
VAR_DECL
or PARM_DECL context, which doesn't belong in DECL_CONTEXT. */
@@ -791,18 +773,13 @@
context = decl_mangling_context (decl);
- gcc_assert (context != NULL_TREE);
-
- /* If we need a fake anonymous namespace, force the nested name path.
*/
- if (needs_fake_anon (decl) && context == global_na
Re: enable-build-with-cxx bootstrap compare broken by r149964
On 10/29/2009 01:06 AM, Jerry Quinn wrote: And here is the latest patch. This one is OK, thanks. Jason
