Re: does the instruction combiner regards (foo & 0xff) as a special case?

[ibanez]

sorry to Ian for replying to the wrong address :)

The result after instruction combination is in *.20.combine
but the rtl pattern *.19.life in

 1.) if(foo & 0x1ff)

 2.) if(foo & 0xff)

are almost the same
I mean the debugging dump only shows the "input" and "output" of
the combination.
But what I wanna know is why the "output"
of case (2) acts against my expection,
and the debugging dump tells nothing about that.
Because things also happens in

  3.) if(foo & 0x)

I guess the combiner generates something like
a trucation pattern when special constant are detected.
The combiner also takse a similiar action in pattern

  4.) if(foo & 0x1)

which generates a

[(set (reg:CC_Z CC_REGNUM)
   (compare:CC_Z (zero_extract:SI
 (match_operand:SI 0 "register_operand" "")
 (const_int 1)
 (match_operand:SI 1 "" ""))
(const_int 0)))]
instead of the normal

[(set (reg:CC_Z CC_REGNUM)
 (compare:CC_Z
   (and:SI (match_operand:SI 0 "register_operand" "")
 (match_operand:SI 1 "" ""))
   (const_int 0)))]



>[EMAIL PROTECTED] writes:

>> I have read the debugging dump before I post my question.
>> But the debugging dump is patterns which have
>> successfully matched instead of patterns which
>> combiner tries to match.
>> In other words, the debugging dump does not tell me why
>> combiner use different scheme when the magic
>> numbers 0xff/0x are used.
>> Am I wrong?

>Please reply to the mailing list and not just to me.  Thanks.

>The debugging dump from before the combine pass shows the instructions
>which the combine pass sees.  The debugging dump from the combine pass
>shows the instructions after they have been combined.

>The combine pass does put instructions together by substituting the
>source of a set of a pseudo-register for a use of the
>pseudo-register.  So you have to take that into account.  But other
>than that, what you see in the dump before combine is what combine
>will see.

>Ian

Re: Large, modular C++ application performance ...

[michael meeks]

Hi Giovanni,

On Sat, 2005-07-30 at 15:36 +0200, Giovanni Bajo wrote:
> I'm slow, but I can't understand why a careful design of the interfaces of
> the dynamic libraries

Well - sure, depends how 'careful' you are ;-) clearly if no C++
classes with virtual methods form the interface of any library, then
there is no problem ;-) unfortunately, mandating that would rather
cripple C++.

>  together with the new -fvisibility flags, should not
> be sufficient. It worked well in other scenarios

-fvisibility is helpful - as the paper says, not as helpful as the old
-Bsymbolic (or link maps exposing only 3 or so functions) were. However
- -fvisibility can only help so much - if you have:

class LibraryAClass {
virtual void doFoo(void);
};
class LibraryBClass : public LibraryAClass {
virtual void doBaa(void);
};

then there are 2 problems:

a) there is no symbol visibility that will trigger internal
   binding in addition to a symbol export. ie. if 
   'LibraryBClass' is a public interface - no useful
   visibility markup can be done; and hence we have a named
   relocation for 'doBaa's vtable slot.
   [ IMHO this is a feature-gap, we need a new ('export'?)
 visibility attribute for this case ].

b) even if LibraryBClass is a 'hidden' class - to build it's
   vtable we have to have a slot for 'doFoo' which is in
   an external library (A) => another named relocation. An 
   unavoidable consequence of using virtual classes as part of
   a library's API.

> IMHO, it's unreasonable to break the C++ ABI for 1 second of warm time
> startup.

Well - it's an option that was considered, although - as you say -
highly unpleasant, and probably quite unnecessary - as the paper
explains.

Regards,

Michael.

-- 
 [EMAIL PROTECTED]  <><, Pseudo Engineer, itinerant idiot

Re: Large, modular C++ application performance ...

[michael meeks]

On Sat, 2005-07-30 at 18:25 +0100, Andrew Haley wrote:
>  > > All input much appreciated; no doubt my terminology is irritatingly up
>  > > the creek, hopefully the sentiment will win through.
>  > >
>  > > http://go-oo.org/~michael/OOoStartup.pdf
> 
> One thing I don't understand is the formula where you write linking
> time is proprortional to the log of the total number of symbols.  Does
> this come from drepper's paper, or somewhere else?

I defer to Ulrich's text:
http://people.redhat.com/drepper/dsohowto.pdf

Section 1.5 of:

"Deficiencies in the ELF hash table function and various ELF extensions
modifying the symbol lookup functionality may well increase the factor
to O(R + r.n.log(s)) where s is the number of symbols. This should make
clear that for improved performance it is significant to reduce the
number of relocations and symbols as much as possible".

However - the log(s) term is rather irrelevant to my argument :-)

HTH,

Michael.

-- 
 [EMAIL PROTECTED]  <><, Pseudo Engineer, itinerant idiot

re: Large, modular C++ application performance ...

[michael meeks]

Hi Dan,

On Sat, 2005-07-30 at 11:19 -0400, [EMAIL PROTECTED] wrote:
> MM wrote in http://go-oo.org/~michael/OOoStartup.pdf:
> "... not one slot was overridden by an implementation
> method external to the implementing library."

This is really an issue rather orthogonal to that of 'final', what I'm
trying to say (clearly, rather badly) - is that in those 3 libraries
there were 0 instances of virtual functions of a given class implemented
in that DSO, being implemented outside that DSO.[1]

The significance of this is that - if we can markup classes to generate
internal relocations for their overridden slots, and copy the parent
library's (also internally) relocated version for inherited slots,
(during this proposed idle vtable relocation process). Then we would
avoid needing ~any named relocations at all to construct these vtables.
ie. go from many tens of thousands of the slowest type of relocation, to
none.

HTH,

Michael.

[1] - further research AFAIR showed only a handful of these instances
across all OO.o libraries.
-- 
 [EMAIL PROTECTED]  <><, Pseudo Engineer, itinerant idiot

Doubt about Pseudo register uses.

[Chunjiang Li]

Hi, all,

When I read the GCC source code about register allocation,
I wonder is it true that one Pseudo  register is only corresponding to one 
basic block?
the reg_info struct is:

typedef struct reg_info_def
{   /* fields set by reg_scan */
  int first_uid;/* UID of first insn to use (REG n) */
  int last_uid; /* UID of last insn to use (REG n) */

/* fields set by reg_scan & flow_analysis */
  int sets; /* # of times (REG n) is set */

/* fields set by flow_analysis */
  int refs; /* # of times (REG n) is used or set */
  int freq; /* # estimated frequency (REG n) is used or set 
*/
  int deaths;   /* # of times (REG n) dies */
  int live_length;  /* # of instructions (REG n) is live */
  int calls_crossed;/* # of calls (REG n) is live across */
  int basic_block;  /* # of basic blocks (REG n) is used in */
} reg_info;

It seems that one Pseudo register is only used in one basic block.
But I am not sure.
Please help me.


Creative Compiler Research Group,
National University of Defense Technology, China.

Re: Doubt about Pseudo register uses.

[Ian Lance Taylor]

Chunjiang Li <[EMAIL PROTECTED]> writes:

> I wonder is it true that one Pseudo  register is only corresponding to one 
> basic block?

No, it isn't.

> the reg_info struct is:
> 
> typedef struct reg_info_def
> { /* fields set by reg_scan */
>   int first_uid;  /* UID of first insn to use (REG n) */
>   int last_uid;   /* UID of last insn to use (REG n) */
> 
>   /* fields set by reg_scan & flow_analysis */
>   int sets;   /* # of times (REG n) is set */
> 
>   /* fields set by flow_analysis */
>   int refs;   /* # of times (REG n) is used or set */
>   int freq;   /* # estimated frequency (REG n) is used or set 
> */
>   int deaths; /* # of times (REG n) dies */
>   int live_length;/* # of instructions (REG n) is live */
>   int calls_crossed;  /* # of calls (REG n) is live across */
>   int basic_block;/* # of basic blocks (REG n) is used in */
> } reg_info;
> 
> It seems that one Pseudo register is only used in one basic block.

If the register is used in more than one basic block, the basic_block
field is set to REG_BLOCK_GLOBAL.  See REG_BASIC_BLOCK in
basic-block.h and flow.c.

Ian

Bugzilla mail interface

[Gabriel Dos Reis]

[EMAIL PROTECTED] writes:

[...]

| index  
| 
|   Send list of open bugs in product , component .
|   You can use '*' for components, which returns all of the open bugs in
|   every component for that product.

Hi Dan,

Now that "index" has been enhanced to accept target version, we
probably want to update the documentation too :-)

   I'm also wondering what is the magic command for retrieving PRs that
have been closed in a given laps of time, based on version,
components, etc?  If none exists, could we have one?

Thanks,

-- Gaby

PS: I'm currently in a place where the connection is not realible enough
for me to spend time on the web interface without turning it into an
exercise in frustration, and it seems to be a good job for mail agents
anyway :-)

Re: Large, modular C++ application performance ...

[Steven Bosscher]

On Monday 01 August 2005 11:44, michael meeks wrote:
>   However - the log(s) term is rather irrelevant to my argument :-)

Not really.  Maybe the oprofile results for the linker show that the
behavior is worse, or maybe better - who knows :-)
Have you looked at any profiles btw?  Just for the curious...

Gr.
Steven

[autovect] Why all these redundant computations?

[Sebastian Pop]

Hello,

I was just looking at the output of the data dep analyzer for
ltrans-1.c and I was quite surprised to see that array indexes are
analyzed twice, as in the following output:

(analyze_array 
  (ref = u[D.1485_16];
)
(analyze_scalar_evolution 
  (loop_nb = 1)
  (scalar = D.1485_16)
(get_scalar_evolution 
  (scalar = D.1485_16)
  (scalar_evolution = {0, +, 1336}_1))
(set_scalar_evolution 
  (scalar = D.1485_16)
  (scalar_evolution = {0, +, 1336}_1))
)
(instantiate_parameters 
  (loop_nb = 1)
  (chrec = {0, +, 1336}_1)
  (res = {0, +, 1336}_1))
)

Here D.1485_16 has an evolution already stored in the cache.  However,
just below we get a full recomputation of the same D.1485_16:

(analyze_scalar_evolution 
  (loop_nb = 1)
  (scalar = D.1485_16)
(get_scalar_evolution 
  (scalar = D.1485_16)
  (scalar_evolution = {0, +, 1336}_1))
(analyze_scalar_evolution 
  (loop_nb = 1)
  (scalar = i_3)
(get_scalar_evolution 
  (scalar = i_3)
  (scalar_evolution = {0, +, 1}_1))
(analyze_initial_condition 
  (loop_phi_node = 
i_3 = PHI ;)
  (init_cond = 0))
(analyze_evolution_in_loop 
  (loop_phi_node = i_3 = PHI ;)
(add_to_evolution 
  (loop_nb = 1)
  (chrec_before = 0)
  (to_add = 1)
  (res = {0, +, 1}_1))
  (evolution_function = {0, +, 1}_1))
(set_scalar_evolution 
  (scalar = i_3)
  (scalar_evolution = {0, +, 1}_1))
)
(analyze_scalar_evolution 
  (loop_nb = 1)
  (scalar = 1336)
(get_scalar_evolution 
  (scalar = 1336)
  (scalar_evolution = 1336))
)
(set_scalar_evolution 
  (scalar = D.1485_16)
  (scalar_evolution = {0, +, 1336}_1))
)

The problem seems to be that analyze_offset_expr calls the scev
analyzer explicitely asking for recomputation (third parameter is
true):

  /* 2. Variable. Try to substitute with initial_condition of the corresponding
 access_fn in the current loop.  */
  if (SSA_VAR_P (expr))
{
  tree access_fn = analyze_scalar_evolution (loop, expr, true, 
 &unknown_evolution);

Why should we start the analysis from scratch in this case?  The same
question could be asked for all the uses of analyze_scalar_evolution
in the vectorizer...  Grepping for analyze_scalar_evolution, you get
the following places (in autovect branch) that explicitely ask for
scev recomputation:

tree-vect-analyze.c:551:  access_fn = analyze_scalar_evolution (loop, def, 
true, &unknown_evolution);
tree-vect-analyze.c:2226:   (loop, analyze_scalar_evolution (loop, 
PHI_RESULT (phi), true, 
tree-vect-transform.c:605:access_fn = analyze_scalar_evolution (loop, 
def, true,
tree-vect-transform.c:2548:  access_fn = analyze_scalar_evolution (loop, 
PHI_RESULT (phi), true,
tree-data-ref.c:940:  tree access_fn = analyze_scalar_evolution (loop, ptr_ref, 
true, 
tree-data-ref.c:1151:  tree access_fn = analyze_scalar_evolution (loop, 
expr, true, 

[no subject]

[Chunjiang Li]

Hi, all:

Also the problem about Pseudo register usage.

I want to know the Pseudo registers used (def and ref) in a basic block.
How can I get these result using the APIs presented in GCC?
Need help. Urgently

Chunjiang Li



Creative Compiler Research Group,
National University of Defense Technology, China.

Also about the Pseudo reg usage problem.

[Chunjiang Li]

Hi, all:

Also the problem about Pseudo register usage.

I want to know the Pseudo registers used (def and ref) in a basic block.
How can I get these result using the APIs presented in GCC?
Need help. Urgently.

May be need to refer the df.c and df.h interface, but I am not sure.




Chunjiang Li



Creative Compiler Research Group,
National University of Defense Technology, China.

Re: [autovect] Why all these redundant computations?

[Dorit Naishlos]

> ...
>
> The problem seems to be that analyze_offset_expr calls the scev
> analyzer explicitely asking for recomputation (third parameter is
> true):
>
> ...
>
> Why should we start the analysis from scratch in this case?  The same
> question could be asked for all the uses of analyze_scalar_evolution
> in the vectorizer...  Grepping for analyze_scalar_evolution, you get
> the following places (in autovect branch) that explicitely ask for
> scev recomputation:
>

I don't think there was an intention to force recomputation - probably just
overlooked what the third argument actually stands for. These occurrences
could probably be changed to false.

dorit

Re: Doubt about Pseudo register uses.

[Chunjiang Li]

Thx.
I also guessed that.
But, for I am a rookie in GCC, I know little about GCC, need advice.

 Ian Lance Taylor :

> Chunjiang Li <[EMAIL PROTECTED]> writes:
>
> > I wonder is it true that one Pseudo  register is only corresponding to one
>  basic block?
>
> No, it isn't.
>
> > the reg_info struct is:
> >
> > typedef struct reg_info_def
> > {   /* fields set by reg_scan */
> >   int first_uid;/* UID of first insn to use (REG n) */
> >   int last_uid; /* UID of last insn to use (REG n) */
> >
> > /* fields set by reg_scan & flow_analysis */
> >   int sets; /* # of times (REG n) is set */
> >
> > /* fields set by flow_analysis */
> >   int refs; /* # of times (REG n) is used or set */
> >   int freq; /* # estimated frequency (REG n) is used or set 
> > */
> >   int deaths;   /* # of times (REG n) dies */
> >   int live_length;  /* # of instructions (REG n) is live */
> >   int calls_crossed;/* # of calls (REG n) is live across */
> >   int basic_block;  /* # of basic blocks (REG n) is used in */
> > } reg_info;
> >
> > It seems that one Pseudo register is only used in one basic block.
>
> If the register is used in more than one basic block, the basic_block
> field is set to REG_BLOCK_GLOBAL.  See REG_BASIC_BLOCK in
> basic-block.h and flow.c.
>
> Ian
> 



Creative Compiler Research Group,
National University of Defense Technology, China.

Re:

[Daniel Berlin]

On Mon, 2005-08-01 at 22:36 +0800, Chunjiang Li wrote:
> Hi, all:
> 
> Also the problem about Pseudo register usage.
> 
> I want to know the Pseudo registers used (def and ref) in a basic block.
> How can I get these result using the APIs presented in GCC?
> Need help. Urgently
> 

See df.h/df.c

Re: [autovect] Why all these redundant computations?

[Daniel Berlin]

On Mon, 2005-08-01 at 17:27 +0300, Dorit Naishlos wrote:
> 
> 
> 
> > ...
> >
> > The problem seems to be that analyze_offset_expr calls the scev
> > analyzer explicitely asking for recomputation (third parameter is
> > true):
> >
> > ...
> >
> > Why should we start the analysis from scratch in this case?  The same
> > question could be asked for all the uses of analyze_scalar_evolution
> > in the vectorizer...  Grepping for analyze_scalar_evolution, you get
> > the following places (in autovect branch) that explicitely ask for
> > scev recomputation:
> >
> 
> I don't think there was an intention to force recomputation - probably just
> overlooked what the third argument actually stands for. These occurrences
> could probably be changed to false.
> 

Yeah, i agree with dorit.
The only other possible reason i can think of is that it fixed a bug
somewhere due to not properly invalidating the cache, and that fix was
just copied around.

> dorit
> 

Re: [autovect] Why all these redundant computations?

[Sebastian Pop]

Daniel Berlin wrote:
> On Mon, 2005-08-01 at 17:27 +0300, Dorit Naishlos wrote:
> > 
> > I don't think there was an intention to force recomputation - probably just
> > overlooked what the third argument actually stands for. These occurrences
> > could probably be changed to false.
> > 
> 
> Yeah, i agree with dorit.
> The only other possible reason i can think of is that it fixed a bug
> somewhere due to not properly invalidating the cache, and that fix was
> just copied around.
> 

Okay, then I'll try to bootstrap and test with these flags passed to
false.

Thanks.

On implicit_builtin_decls and/or assert at cp/call.c:322

[Richard Guenther]

Hi!

I'm a bit confused about the uses of the decls stored in the
implicit_builtin_decls and builtin_decls arrays.  I suppose
the builtin_decls array should contain the __builtin_X variant,
while the implicit_builtin_decls variant should contain the X
variant.  Most of the code emitting calls to f.i. memcpy use
the implicit_builtin_decls variant, but cp/call.c:322 seems
to rely on the fact that even the implicit_builtin_decls variant
contains the __builtin_X variant:

  if (decl && ! TREE_USED (decl))
{
  /* We invoke build_call directly for several library functions.
 These may have been declared normally if we're building libgcc,
 so we can't just check DECL_ARTIFICIAL.  */
  gcc_assert (DECL_ARTIFICIAL (decl)
  || !strncmp (IDENTIFIER_POINTER (DECL_NAME (decl)),
   "__", 2));
  mark_used (decl);
}

apart from some confusing parts of the comment (we're talking about
cp/call.c and still see libgcc mentioned?), using implicit_builtin_decls
variant of memcpy and getting the "memcpy" variant (as asked for(??)),
this assert fires on me.

What is the rationale for this assert?  And what is the rationale for
putting the __builtin_X variant also in implicit_builtin_decls?  What
is the rationale for using the implicit_builtin_decl then, instead of
the builtin_decl?

Thanks,
Richard.

Re: Large, modular C++ application performance ...

[H. J. Lu]

On Mon, Aug 01, 2005 at 10:38:46AM +0100, michael meeks wrote:
> Hi Giovanni,
> 
> On Sat, 2005-07-30 at 15:36 +0200, Giovanni Bajo wrote:
> > I'm slow, but I can't understand why a careful design of the interfaces of
> > the dynamic libraries
> 
>   Well - sure, depends how 'careful' you are ;-) clearly if no C++
> classes with virtual methods form the interface of any library, then
> there is no problem ;-) unfortunately, mandating that would rather
> cripple C++.
> 
> >  together with the new -fvisibility flags, should not
> > be sufficient. It worked well in other scenarios
> 
>   -fvisibility is helpful - as the paper says, not as helpful as the old
> -Bsymbolic (or link maps exposing only 3 or so functions) were. However
> - -fvisibility can only help so much - if you have:
> 

Since you were comparing Windows vs. ELF, doesn't Windows need a file
to define which symbols to export for a shared library? Why can't you
you do it with ELF using a linker map? Libstdc++.so is built with
a linker map. Any C++ shared library should use one if the startup
time is a big concern. Of coursee, if gcc can generate a list of
symbols suitable for linker map, which needs to be exported, it will
be very helpful. I don't think it will be too hard to implement.


H.J.

Re: does the instruction combiner regards (foo & 0xff) as a special case?

[Joern RENNECKE]

But I found they fails to match

if(foo & 0xff) and if(foo & 0x)


These get simplified to foo.


Look at the debugging dump before the combine pass to see what you
need to match.


It doesn't work that way.  What you get from there are only the insn numbers.

Then you run cc1 (or whatever languiage-specific compiler you use) under
gdb control, with a breakpoint on the point in try_combine - in this case,
before the first recog_for_combine call - with a condition to match the
insn numbers.  E.g. for breakpoint 5, to match any combination that ends
in insn 42,
you say:

cond 5 i3->u.fld[0].rt_int == 42

to match a combination of insns 40, 41 and 42 (and only in exactly that
order):

cond 5 
i3->u.fld[0].rt_int == 42 && i2->u.fld[0].rt_int == 41 && i1 && i1->u.fld[0].rt_int == 40


or for an older codebase:

i3->fld[0].rtint == 42 && i2->fld[0].rtint == 41 && i1 && i1->fld[0].rtint == 40

Re: Large, modular C++ application performance ...

[Dan Nicolaescu]

michael meeks <[EMAIL PROTECTED]> writes:

  > Hi there,
  > 
  > I've been doing a little thinking about how to improve OO.o startup
  > performance recently; and - well, relocation processing happens to be
  > the single, biggest thing that most tools flag.

Have you tried eliminating all the unneeded shared libraries linked to
all the OO.o binaries and shared libraries? This should have an impact on
startup time.

ldd -u -r BINARY_OR_SHARED_LIBRARY 
should not print anything 

(as a side note Gnome is a much bigger offender on linking way too
many unused shared libraries...)

Re: rfa (x86): 387<=>sse moves

[Dale Johannesen]

On Jul 31, 2005, at 9:51 AM, Uros Bizjak wrote:


Hello!

With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code 
like


   double d = atof(foo);
   int i = d;


   callatof
   fstpl   -8(%ebp)
   movsd   -8(%ebp), %xmm0
   cvttsd2si   %xmm0, %eax


(This is Linux, Darwin is similar.) I think the difficulty is that for


This problem is similar to the problem, described in PR target/19398. 
There is another testcase and a small analysis in the PR that might 
help with this problem.


Thanks, that does seem relevant.  The patches so far don't fix this 
case;

I've commented the PR explaining why.

ICE and reg class problems in 3.4.5-20050801 in g++.dg/eh/simd-2.C

[Kean Johnston]

Hi all,

I'm getting the following ICE when testing $subject:
simd-2.C: In function `int __vector__ vecfunc(int __vector__)':
simd-2.C:14: error: insn does not satisfy its constraints:
(insn 41 40 35 0 (set (reg:SI 21 xmm0 [ beachbum+12 ])
(mem:SI (plus:SI (reg/f:SI 6 bp)
(const_int -4 [0xfffc])) [0 S4 A8])) 37 
{*movsi_1_nointernunit} (nil)

(nil))
simd-2.C:14: internal compiler error: in reload_cse_simplify_operands, 
at postreload.c:391


That's pretty much gobbldygook to me, but I see that other
X86 targets aren't having this problem, so it's something with
my port. And guidance as to what it could be would be greatly
appreciated.

I dont know if its related but I also get other errors
(not ICE) when compiling a few things in PIC mode. For example:

gcc.c-torture/compile/2804-1.c: In function f:
error: can't find a register in class `GENERAL_REGS' while reloading `asm'

If anyone can point me in the right direction I'd be most grateful.

Kean

Re: -b vs -bundle

[Geoff Keating]

On 31/07/2005, at 12:03 PM, Jack Howarth wrote:



  In compiling xplor-nih under the gcc/g++ of 4.1 branch instead
of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the
gnu gcc compiler doesn't gracefully handle the -bundle flag. On  
Apple's

compiler I can have a Makefile entry like...

createSharedModule = $(CXX) -bundle  \
-flat_namespace -undefined suppress $^ -o $@

and it compiles the shared module without error. However I see the
error...

g++-4 -bundle -flat_namespace -undefined suppress _xplorWrap.o  
libswigpy-xplor.dylib -o _xplorWrap.so -L/Users/howarth/Desktop/ 
xplor-nih-2.11.2.1/bin.Darwin_8/ -lcommon -lnmrPot -lintVar -lvmd - 
lpy  -lswigpy-xplor \
 -lcrypto -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/ 
bin.Darwin_8/

g++-4: couldn't run 'undle-gcc-4.1.0': No such file or directory

with the gnu gcc compiler. I noticed that you rejected a proposed  
patch

a few years ago...

http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00655.html
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01961.html

Could you revisit this issue and see if something could be done for  
4.0
and 4.1 branch? I would think that either the compiler should  
require the

-b flag to have a space before the machine name. Alternatively if the
gnu gcc compiler mustn't allow -bundle to be the first argument passed
to the compiler, it should at least treat that as a defined error  
rather
than producing the cryptic one it does now. Thanks in advance for  
looking

at this again.



Hi Jack,

I believe everything I said back then is still valid.  See especially  
.


I don't think we can require -b to have a space; that would break  
existing scripts.


smime.p7s
Description: S/MIME cryptographic signature

Re: -b vs -bundle

[Jack Howarth]

Geoff,
   What I don't understand is how Apple's compiler can parse the
-bundle as the first argument and the gnu gcc compiler can't. 
Shouldn't the same mechanism Apple uses to allow this to work
be backportable into gnu gcc?
 Jack

Re: -b vs -bundle

[Geoff Keating]

On 01/08/2005, at 1:44 PM, Jack Howarth wrote:


Geoff,
   What I don't understand is how Apple's compiler can parse the
-bundle as the first argument and the gnu gcc compiler can't.
Shouldn't the same mechanism Apple uses to allow this to work
be backportable into gnu gcc?


No.  There's lots of stuff in Apple's compiler that isn't written  
portably enough to work in GNU GCC.


My suggestion, if you're interested in fixing this, is to read

http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00736.html

and fix the problems I mentioned there in the patch that Devang  
submitted, and submit a fixed version.




smime.p7s
Description: S/MIME cryptographic signature

Re: -b vs -bundle

[Jack Howarth]

Geoff,
   The problem is that I haven't ever submitted any paperwork so
anything I touch will be tainted. If you could post a revised patch
that applies to gcc main trunk, I'll test it locally and confirm
that it works.
  Jack

i_am_not_a_leaf() and -fno-unit-at-a-time

[Dwayne Grant McConnell]

When I try to build recent glibc for ppc with gcc 4.1 I get a failure 
complaining about multiple definitions of dummy and _init plus an 
undefined reference to i_am_not_a_leaf. Searching on the web I see that 
others have seen this with previous versions of gcc and fixed it with 
-fno-unit-at-a-time. I tried this without success so far.

According to libc/sysdeps/generic/initfini.c the purpose of 
i_am_not_a_leaf() is to let gcc know that _fini is not a leaf routine. Is 
there something that has changed in gcc from 4.0 to 4.1 which would cause 
this technique to be invalid?

Is there another way to resolve the problem than -fno-unit-at-a-time?

Thanks,
Dwayne

-- 
Dwayne Grant McConnell <[EMAIL PROTECTED]>
Lotus Notes: Dwayne McConnell/Austin/[EMAIL PROTECTED]

Re: mudflap: compiler flags changed?

[Frank Ch. Eigler]

Hi -

Eyal wrote:

> [...]
> In the past -fmudflapth did the job. Something changed.
> The help suggests that the two options have a function but it
> is not clear (to me) what it is. [...]

This could be an unintended side-effect of rth's libmudflap pthreads
changes a week or two ago.

- FChE


pgpBPoW57cQu7.pgp
Description: PGP signature

debug info omitted for uninitialized variables

[Devang Patel]

This was discussed as part of bugzilla PR/21828. I have filed PR 23190.

$ cat t.c
static int foo;
int bar;
int main(void)
{
   foo += 3;
   bar *= 5;
   return 0;
}

$ xgcc -g  -O2 -o t t.c
$ cat gdbcmds
b main
ptype foo
ptype bar
p foo
p bar
$ gdb --batch -x gdbcmds t
Reading symbols for shared libraries ... done
Breakpoint 1 at 0x2d14: file t.c, line 6.
type = 
type = 
$1 = 
$2 = 

[ This was discussed in PR 21828 ]

>On Jul 22, 2005, at 4:43 PM, mark at codesourcery dot com wrote:
>
>First, your example was not the one in the original bug report.
>
>Second, you're using STABS, not DWARF-2.  I suspect the stabs debug
>generator, or the GDB stabs reader is not as good as DWARF.
>
>On GNU/Linux, GDB knows that "bar" has type "int".  It still doesn't
>know the type of "foo"; apparently too much of the debug  
information is

>optimized away.  But, that's some other problem -- perhaps in GDB
>itself.  The information is clearly there for it:
>
>.uleb128 0x2# (DIE (0x2d) DW_TAG_variable)
> .ascii "foo\0"  # DW_AT_name
> .byte   0x1 # DW_AT_decl_file
> .byte   0x1 # DW_AT_decl_line
> .long   0x38# DW_AT_type
> .uleb128 0x3# (DIE (0x38) DW_TAG_base_type)
> .ascii "int\0"  # DW_AT_name
> .byte   0x4 # DW_AT_byte_size
>.byte   0x5 # DW_AT_encoding


It seems this is related to order of cgraph_optimize() and writing  
globals. If globals are wrapped up  before emitting code then debug  
info. is not emitted for uninitialized globals, because DECL_RTL is  
not  set. C++ FE writes globals before doing cgraph_optimize(), but C  
FE optimizes first. This is why this is C specific only. This patch  
fixes this but it causes varpool-1.c test failure. With this patch,  
GDB know about foo as well as bar when DWARF is used.



Index: c-decl.c
===

RCS file: /cvs/gcc/gcc/gcc/c-decl.c,v
retrieving revision 1.677
diff -Idpatel.pbxuser -c -3 -p -r1.677 c-decl.c
*** c-decl.c19 Jul 2005 20:19:09 -  1.677
--- c-decl.c28 Jul 2005 19:22:47 -
*** tree c_cont_label;
*** 131,136 
--- 131,139 

  static GTY(()) tree all_translation_units;

+ /* Outermost block. */
+ static GTY(()) tree ext_block;
+
  /* A list of decls to be made automatically visible in each file  
scope.  */

  static GTY(()) tree visible_builtins;

*** c_write_global_declarations_1 (tree glob
*** 7570,7576 
  void
  c_write_global_declarations (void)
  {
!   tree ext_block, t;

/* We don't want to do this if generating a PCH.  */
if (pch_file)
--- 7573,7579 
  void
  c_write_global_declarations (void)
  {
!   tree t;

/* We don't want to do this if generating a PCH.  */
if (pch_file)
*** c_write_global_declarations (void)
*** 7586,7591 
--- 7589,7598 
external_scope = 0;
gcc_assert (!current_scope);

+   /* We're done parsing; proceed to optimize and emit assembly.
+  FIXME: shouldn't be the front end's responsibility to call  
this.  */

+   cgraph_optimize ();
+
/* Process all file scopes in this compilation, and the  
external_scope,
   through wrapup_global_declarations and  
check_global_declarations.  */

for (t = all_translation_units; t; t = TREE_CHAIN (t))
*** c_write_global_declarations (void)
*** 7608,7617 
   functions have magic names which are detected by collect2.  */
build_cdtor ('I', static_ctors); static_ctors = 0;
build_cdtor ('D', static_dtors); static_dtors = 0;
-
-   /* We're done parsing; proceed to optimize and emit assembly.
-  FIXME: shouldn't be the front end's responsibility to call  
this.  */

-   cgraph_optimize ();
  }

  #include "gt-c-decl.h"
--- 7615,7620 


-
Devang

LHS of assignment

[shreyas krishnan]

Hi every one, 
 Can some one please answer this.  How do I get a tree node from
an exisiting symbol for use in the LHS of a expression ? example a=10;

thanks
shrey

Re: i_am_not_a_leaf() and -fno-unit-at-a-time

[Roland McGrath]

initfini.c needs -fno-unit-at-a-time.  It's not a normal compilation, but a
special hack for generating assembly fragments.  The development libc uses
the flag for that file.

Re: More fun with aliasing - removing assignments?

[Ian Lance Taylor]

Harald van Dijk <[EMAIL PROTECTED]> writes:

> I finally managed to track down the problem I've been having to this
> short code:
> 
>   typedef struct {
>   unsigned car;
>   unsigned cdr;
>   } cons;
> 
>   void nconc (unsigned x, unsigned y) {
>   unsigned *ptr = &x;
>   while(!(*ptr & 3))
>   ptr = &((cons *)(*ptr))->cdr;
>   *ptr = y;
>   }
> 
> With gcc 4.0-20050728 on i686-pc-linux-gnu, compiling this with -O2
> appears to remove the assignment to *ptr. (I didn't prepare an example
> program, but it's verifiable with objdump.) Obviously, this code is
> non-portable, but still, I don't see why this can happen. Would anyone
> be kind enough to explain this to me? It works as expected with -O2
> -fno-strict-aliasing.

Well, I'd say it's a bug.  It works in 4.1.  The final assignment gets
removed by tree-ssa-dce.c because it looks like a useless store.  This
is because alias analysis thinks it knows what is going on, when it
clearly does not.

This patch happens to fix it in 4.0.  I doubt this is the right
approach, though.  It's a big hammer, which says that if you set a
pointer to the address of something, and you're not sure what that
thing is, then you have no idea what the pointer points to.

This code is completely different in 4.1.  In 4.1 the function
find_what_p_points_to is called, and it determines that it has no idea
what 'ptr' points to.

I think this should probably be fixed for 4.0.2, but I don't know if
this is the right patch at all.  It should at least be safe.

Ian

Index: tree-ssa-alias.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.71.2.2
diff -p -u -r2.71.2.2 tree-ssa-alias.c
--- tree-ssa-alias.c26 Jul 2005 20:54:21 -  2.71.2.2
+++ tree-ssa-alias.c2 Aug 2005 05:07:41 -
@@ -1901,6 +1901,8 @@ add_pointed_to_var (struct alias_info *a
   if (is_global_var (pt_var))
pi->pt_global_mem = 1;
 }
+  else
+set_pt_anything (ptr);
 }
 
 

Re: LHS of assignment

[James A. Morrison]

shreyas krishnan <[EMAIL PROTECTED]> writes:

> Hi every one, 
>  Can some one please answer this.  How do I get a tree node from
> an exisiting symbol for use in the LHS of a expression ? example a=10;
>
> thanks
> shrey

 I don't really know what your asking but in a =  is the the 1st operand
of a MODIFY_EXPR, i.e. TREE_OPERAND (modify_expr, 0).


-- 
Thanks,
Jim

http://www.csclub.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim