On 10/29/2009 01:06 AM, Jerry Quinn wrote:
And here is the latest patch.
This one is OK, thanks.
Jason
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 ca
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 gi
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 plugin
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
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.
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
> 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 som
> 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
> 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
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
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*
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 du
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 in
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 un
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_
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
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 low
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 verb
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_
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-b
21 matches
Mail list logo
