headers
Richard Henderson | 1 May 2003 01:32
Picon
Favicon

Re: GCC warnings for unused global variables

On Wed, Apr 30, 2003 at 10:37:13AM +0200, Philipp Thomas wrote:
> > #ifndef lint
> > static const char rcsid[] =
> >   "$Id: src/dir/file.c 1.12 1999/08/27 23:45:12 me Exp$";
> > #endif /* not lint */
> 
> Why not just use __attribute__((__unused__))?

Or indeed, #ident, which is availalble on many compilers
and doesn't result in extra data at runtime.

r~
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 May 2003 02:03
Picon
Favicon

Re: Using mem_attrs to get the tree of a function being called?

On Wed, Apr 30, 2003 at 04:52:08PM +0200, Alexandre Courbot wrote:
> Are mem_attrs not used when dealing with functions?

No.

> If so, is there any good reason why this is so or shall I go ahead
> and try to implement it?

No, there's no good reason for the MEM at all.  If I were 
going to change anything, it'd be removing that silly bit
of history.

On gcc mainline you can get back to the DECL for a direct
function call via SYMBOL_REF_DECL.  There is no way to do
this for indirect function calls.

Normally in these cases the port generates a cookie for
what it needs to know during FUNCTION_ARG.  There's a 
final call to that hook with VOIDmode.  Return a CONST_INT
containing whatever bits you need, and it'll be given to
the call expander, which can then tuck it away somewhere.
See the ARM port for an example of this.

r~
Permalink | Reply | 3 comments |
headers
Richard Henderson | 1 May 2003 02:21
Picon
Favicon

Re: GCC warnings for unused global variables

On Wed, Apr 30, 2003 at 07:47:30PM -0400, Alexander Kabaev wrote:
> % what `which ls`
> /bin/ls:
>          Copyright (c) 1989, 1993, 1994
>         termcap.c       8.1 (Berkeley) 6/4/93
>         strftime.c      7.38
>         localtime.c     7.57
>         asctime.c       7.7
>         rec_seq.c       8.3 (Berkeley) 7/14/94
>         key_call.c      1.25    94/04/24 SMI
> 
> Does #ident allow that?

Yes.  For ELF this normally winds up in the .comment section.
Of course, this section is removed by strip, so it won't
*necessarily* be there, but ...

> Anyway, my question was about boatload of
> third-party software, which normally should not be modified locally.
> const static rcsid's are very common.

Then you'll have to ignore the warning.

r~
Permalink | Reply | 18 comments |
headers
Zack Weinberg | 1 May 2003 02:25

Re: Compilation time

Don Lindsay <lindsayd <at> cisco.com> writes:

>> (Also, generation of the .ii file is slow, as no one has bothered
>> to make it fast.)
>
> There is now a community who would like it to be fast. Specifically,
> the users of ccache:
>
> 	http://ccache.samba.org/
>
> Do you have a specific reason to think .ii-writing could be made faster?

Oh yes.  I've profiled it and a majority of the total runtime is
wasted on stdio overhead.  If c-ppoutput.c had a custom output buffer
without that overhead, it'd be fast.  This has never made it to the
top of my queue, but if you want to implement it I'll be happy to
review it.

zw
Permalink | Reply | 0 comments |
headers
Dale Johannesen | 1 May 2003 02:30
Picon
Favicon

Re: new register allocator and HARD_REGNO_CALL_PART_CLOBBERED

On Wednesday, April 30, 2003, at 12:31  PM, Herman ten Brugge wrote:

> Hello,
>
> I found a problem with the -fnew-ra option of the compiler. I analysed
> the problem and found that the macro HARD_REGNO_CALL_PART_CLOBBERED
> is not used by the new register allocator.
> I think this is also a bit difficult to implement because we now
> have to check the mode for every register that is used during a 
> CALL_INSN.

You can try the following (mail may have screwed up spacing).  It may
result in even worse code than your patch, but maybe it's better than
trying to work around this new-ra problem in individual targets.
(Untested, I do not have a c4x.)

*** df.c        Thu Apr 17 13:30:04 2003
--- /Volumes/MacOS9/gcc/gcc3.preimport/gcc/df.c Fri Apr  4 10:33:25 2003
*************** df_insn_refs_record (df, bb, insn)
*** 1282,1301 ****
         df_uses_record (df, &PATTERN (insn),
                       DF_REF_REG_USE, bb, insn, 0);

         if (GET_CODE (insn) == CALL_INSN)
         {
           rtx note;

           if (df->flags & DF_HARD_REGS)
!           {
!             /* Kill all registers invalidated by a call.  */
(Continue reading)

Permalink | Reply | 7 comments |
headers
Diego Novillo | 1 May 2003 03:41
Picon
Favicon

When is stage 1 scheduled to close for 3.4?

The work being done on the tree-ssa branch is reaching a state in
which we could start thinking about a merge.  We're nearly done
with basic infrastructure work.  We are now starting to look at
performance tuning.

Depending on what the schedule looks like, it may make sense for
us to try merging the branch into mainline in time for 3.4.

Thanks.  Diego.
Permalink | Reply | 12 comments |
headers
Daniel Berlin | 1 May 2003 03:53

Re: new register allocator and HARD_REGNO_CALL_PART_CLOBBERED


On Wednesday, April 30, 2003, at 03:31  PM, Herman ten Brugge wrote:

> Hello,
>
> I found a problem with the -fnew-ra option of the compiler. I analysed
> the problem and found that the macro HARD_REGNO_CALL_PART_CLOBBERED
> is not used by the new register allocator.

It's not a problem in new-ra (i've dealt with exactly this problem in 
the past month, i never got around to sending a patch to the mainline).
It's in df.c.

All register info used from new-regalloc is coming from df.c, that's 
where you need to add the macro.

Right somewhere in this code:
           if (df->flags & DF_HARD_REGS)
             {
               /* Calls may also reference any of the global registers,
                  so they are recorded as used.  */
               for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
                 if (global_regs[i])
                   {
                     x = df_reg_use_gen (i);
                     df_uses_record (df, &SET_DEST (x),
                                     DF_REF_REG_USE, bb, insn, 0);
                   }
             }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fergus Henderson | 1 May 2003 04:04
Picon
Picon

Re: Using incomplete types to instantiate STL-Templates?

On 30-Apr-2003, Wolfgang Bangerth <bangerth <at> ices.utexas.edu> wrote:
> 
> Note that libstdc++ _does_ actually accept the code Christian showed. It 
> only rejects it if concepts checking is on. I think that's weird, and 
> personally consider it a defect in the way the concepts checks are 
> implemented. 

The point of concept checking is to check that the class used to
instantiated a template meets (the checkable subset of) the standard's
requirements.  One of the requirements that the standard imposes is that
the class must be complete.  So it is surely right for the concept checking
to reject such classes!

--

-- 
Fergus Henderson <fjh <at> cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
Permalink | Reply | 0 comments |
headers
Mark Mitchell | 1 May 2003 07:00

Re: GCC 3.3

> 2. Mark _has_ contributed quite a couple of performance improvements,
>    (and so have others).
> 
>    But just because he is release manager and C++ maintainer, nobody can
>    sensibly demand that he fixes all performance issues showing up from
>    C++ code by himself; even more so if many advances of his are more
>    than offset by the creeping slowdown throughout the compiler.
> 
> So, in the end, I suppose that currently both Mark and myself are somehow
> frustrated (at least that's how I understood his reply).

I just don't think that we're going to be able to fix this for 3.3 given
where we presently are.

In practice, we often have a hard time getting people to fix correctness
regressions that they have introduced; compile-time regressions will be
even tougher, and they're tougher to pin on a particular person.  If I
fix a bug, but introduce a 0.25% slowdown, is that a net win or not? 
What if I speed up some piece of generated code by 1%?  When we still
have quadratic algorithms in the compiler, should we worry about my
0.25% slowdown?  Maybe we should invest in fixing those algorithms
instead -- but that requires major work, and we can't expect someone
who's just fixing a bug somewhere to do that.

The good news is that LANL is interested in seeing the C++ compiler run
faster, so Zack and Nathan and I *are* looking at these issues, from a
variety of different angles.

We are lucky in that LANL and Apple (among others, perhaps) are actively
supporting improvements in this area.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fuxin Zhang | 1 May 2003 07:39
Picon

GCC -O2 failure for mipsel

Hello,
I've met a case where mipsel-linux-gcc -O2 fails,for both
2.96 and the fresh new 3.2.3. Maybe someone can tell me
what's wrong.

I've reduced the problem to the test case below,compile it
with mipsel-linux-gcc -O2(FROM H.J.Lu's redhat miniport,all version,
and 3.2.3 is tested too)

#define PUT_CODE(x,code) ((x)->code = (code))
union test_union {
struct test *t;
int a;
};

struct test {
unsigned short code;
union test_union u[1];
};

char memory[2000];

struct test *test_alloc(int code)
{
struct test *t;
int length=sizeof(struct test);

t = (struct test*)memory;
length = (sizeof(struct test) - sizeof(union test_union)-1)/sizeof(int);
for (;length>=0;length--)
(Continue reading)

Permalink | Reply | 9 comments |

Gmane