Re: What is ccp_fold_builtin() for vs. fold_builtin_1() ?

On Mar 31, 2005, at 5:46 PM, Kaveh R. Ghazi wrote:

> I'm wondering what ccp_fold_builtin() is for, and particularly why it
> only handles BUILT_IN_STRLEN, BUILT_IN_FPUTS, BUILT_IN_FPUTS_UNLOCKED,
> BUILT_IN_STRCPY and BUILT_IN_STRNCPY.
>
> Why were these builtins chosen to live in this function and not
> others?
>
> And what is the place of fold_builtin_1() given we have
> ccp_fold_builtin() ?
>
> Would someone please enlighten me?

ccp_fold_builtin handles converting some of the string builtins to
other builtins if the string length are the same for two strings
for an example:
#include <stdio.h>
void f(int i)
{
   const char *a;
   if (i)
    a = "aa";
   else
    a = "bb";
   __builtin_fputs(a,stdout);
}

We convert it to:

Re: What is ccp_fold_builtin() for vs. fold_builtin_1() ?

On Thu, Mar 31, 2005 at 05:46:40PM -0500, Kaveh R. Ghazi wrote:

> And what is the place of fold_builtin_1() given we have
> ccp_fold_builtin() ?
> 
> Would someone please enlighten me?
> 
ccp_fold_builtin was mostly an attempt to enhance CCP so that we
could propagate constant string attributes from non constant
values.  It uses a rudimentary use-def chain walker that will do
simple things like:

if (random ())
  s_1 = "xxx";
else
  s_2 = "yyy";
s_3 = PHI <s_1, s_2>
return strlen (s_3);

Even if the value of s_3 is non-constant, we know that
strlen(s_3) is always 3.

The implementation is very crude and primitive.  A better
propagator that was able to handle other attributes could now be
implemented using the SSA propagation engine.

Interested?  I never got around to fixing this wart.

Diego.

Re: [Fwd: Re: compiler interpretation of *mptr++ = mptr]

On Thu, 31 Mar 2005, Ajoy K Thamattoor wrote:

> 
>   A colleague of mine pointed out gcc gave warnings on the following 
> constructs. I understand a strictly conforming implementation is allowed 
> to warn on anything, but some of these are actually valid constructs. 
> Wanted clarification on why gcc wants to provide sequence-point warnings 
> on these. Please cc me on the response, since I am not subscribed to the 
> list...

I don't think you understand what dg-bogus means.  You are quoting from 
gcc.dg/sequence-pt-1.c and dg-bogus is testing that GCC *doesn't* warn for 
those constructs.  And, indeed, the test passes: GCC does not warn for 
these constructs.

If you have a genuine bug in -Wsequence-point, report it to GCC Bugzilla 
with a complete testcase to reproduce the bug.

--

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm <at> polyomino.org.uk (personal mail)
    joseph <at> codesourcery.com (CodeSourcery mail)
    jsm28 <at> gcc.gnu.org (Bugzilla assignments and CCs)

Re: PCH versus --enable-mapped-location

Per Bothner <per <at> bothner.com> writes:

> Geoff Keating wrote:
>   >> * Any source_location values handed out before the #include
> >> that restores the gch will become invalid.  They will be re-mapped
> >> to that in the pre-compiled header.  Presumably that's ok - there's
> >> no declartions or expressions in the main file at that point, or
> >> the restore would have failed.  Any declarations that are <builtin>
> >> or in the <command line> will presumably be the same either way.
> > Another way of putting this is that source_location values should be
> > in GCed memory.  I think they all are, certainly all declarations
> > and macro definitions are.
> 
> I think you're misunderstanding my concern.  The issue is when we're
> processing a .c file normally we generate source_location cookies
> for <builtin>, <command line>, and any tokens until we process the
> #include that restores the pch.  At that point we (need to) restore
> the line number saved in the pch.  Any source_location cookies
> that we've handed out up until then become invalid, because they
> refer to a line_table that has been replaced.  My point is that
> presumably it doesn't matter, since the source_location cookies
> and declarations corresponing to <builtin> and <command line>
> should match, when compared with those at pch-generation time.

The invalid cookies should no longer exist in the compiler's memory,
because they were stored in GCed memory and they were replaced by the
ones from the PCH.  After a PCH load it is as if those cookies were
never generated.

Thus, it's irrelevant whether they match, which is good, because I

Re: PCH versus --enable-mapped-location

Per Bothner <per <at> bothner.com> writes:

> Daniel Jacobowitz wrote:
>   > That's exactly what Geoff said.  There are two relevant properties of
> > GCed memory here:
> >   - Anything in GCed memory will be saved to the PCH
> >   - Anything in GCed memory will be overwritten by loading the PCH.
> 
> So the corrollary: After a restore any pointers from non-gc'd memory to
> gc'd memory will be a dangling pointer, if we count static variables
> marked with GTY as "gc'd memory" in this context.

Yes.  Don't keep pointers to GCed memory in non-GCed memory.  The GC/PCH
machinery assumes that it can see all pointers to the objects it
allocates.

> Right now, as far as I can tell, the filenames in the line_table are
> allocated from non-gc'd memory.  This complicates using gc.

This is the reverse case: pointers to non-GCed memory in GCed memory.
There is one case where this is allowed, which just happens to be the
case that you want: a pointer to a C string.

Re: ia64 bootstrap failure with the reload-branch

Steven Bosscher wrote:
> ../../reload-branch/gcc/unwind.inc:313: error: Attempt to delete prologue/epilogue insn:
> (insn/f 137 136 138 0 ../../reload-branch/gcc/unwind.inc:285 (set (reg:DI 33 r35)
>         (reg:DI 320 b0)) -1 (nil)
>     (nil))

Reload is using registers without setting regs_ever_live.  The IA-64 
prologue code needs a temp register to save/restore b0, and it uses 
regs_ever_live to find one.  Also, because we have variable size 
register windows, we need the regs_ever_live info to be accurate so we 
can set up the register windows properly.

The problem happens in inherit_one_chain, but it looks like there are 
other similar places that may have the same problem.  Ugly patch 
attached that gets me past this problem.  We should probably get Bernd's 
opinion on how he thinks this should be fixed.
--

-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Index: reload1.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/reload1.c,v
retrieving revision 1.463.2.2
diff -p -p -r1.463.2.2 reload1.c
*** reload1.c	20 Mar 2005 19:49:08 -0000	1.463.2.2
--- reload1.c	1 Apr 2005 00:05:53 -0000
*************** inherit_one_chain (struct inherit_chain 
*** 3682,3687 ****
--- 3682,3691 ----

RFC: #pragma optimization_level

I've currently got the job of implementing pragma(s) to change
optimization level in the middle of a file.  This has come up a few 
times before,

http://gcc.gnu.org/ml/gcc/2001-06/msg01275.html
http://gcc.gnu.org/ml/gcc/2002-09/msg01171.html
http://gcc.gnu.org/ml/gcc/2003-01/msg00557.html

and so far nothing has been done, but the users who want
this feature have not gone away, so I will be doing it now.
The only real opposition to the idea was from Mark Mitchell, in
the earliest of these threads,

http://gcc.gnu.org/ml/gcc/2001-06/msg01395.html

So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?  If so, I'll go do this as 
a local
patch, Geoff will complain a lot, and it will be done 4 times as fast :)

Let's assume for the sake of argument that Mark is OK with it.
Mark's message also raises some good questions about semantics.
My answers are:
- Flags that logically refer to a whole file at once cannot be changed.
In this category I know of -funit-at-a-time and -fmerge-constants; there
may be others I haven't found.
- When function A is inlined into B, the inlined copy is now part of B, 
and
whatever flags were in effect at the beginning of B apply to it.  (The 
decision

Re: RFC: #pragma optimization_level

Dale Johannesen <dalej <at> apple.com> writes:

> For mainline I assume we'll need "GCC" to the syntax; that local
> change is small compared to making it work though.)

If you're implementing a #pragma for compatibility with another
compiler, we don't require the "GCC" prefix.

zw

Re: ia64 bootstrap failure with the reload-branch

Steven Bosscher wrote:
> Bootstrap with the reload-branch dies on ia64 in stage0 while
> building unwind-ia64.c:

I needed one more minor patch to quiet a warning in reload.c, and I 
couldn't help but notice that reload1.c is being compiled with -Wno-error.

Thhis got me all the way to a bootstrap compare failure, which I haven't 
bothered to look at.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Index: reload.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.268.6.1
diff -p -p -r1.268.6.1 reload.c
*** reload.c	18 Mar 2005 18:40:32 -0000	1.268.6.1
--- reload.c	1 Apr 2005 02:33:48 -0000
*************** static int refers_to_regno_for_reload_p 
*** 236,242 ****
  static int
  push_secondary_reload (int in_p, rtx x, int opnum, int optional,
  		       enum reg_class reload_class,
! 		       enum machine_mode reload_mode, enum reload_type type,
  		       enum insn_code *picode)
  {
    enum reg_class class = NO_REGS;
--- 236,243 ----

Problems using cfg_layout_finalize()

Hello,

I am trying to reorder certain basic blocks again after
rest_of_handle_reorder_blocks() (which in turn calls
reorder_basic_blocks).  What I do is this:

cfg_layout_initialize (flags);

reorder_selected_blocks(); // sets bb->rbi->next on them

/* Leave the rest as it was. */
  FOR_EACH_BB (bb)
    if ((bb->next_bb != EXIT_BLOCK_PTR) && (!bb->rbi->next))
      bb->rbi->next = bb->next_bb;

cfg_layout_finalize();

If I do that before rest_of_handle_partition_blocks, it works
just fine.  (btw. I ensure that all blocks I force to follow
one another belong to the same partition)  But then some of
them get repositioned, so I want to run the above again
after rest_of_handle_reorder_blocks() is done.

If I do that I run into an infinite loop in fixup_reorder_chain()
in its first for loop at:

  for (bb = ENTRY_BLOCK_PTR->next_bb, index = 0;
       bb != 0;
       bb = bb->rbi->next, index++)
    {