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