Re: Clarification request for ipa/cgraph code

[Paolo Bonzini]

Mike Stump wrote:

In ipa-type-escape.c we have:

  /* Return either TYPE if this is first time TYPE has been seen an
 compatible TYPE that has already been processed.  */

I'd fix it, if I knew I knew what it meant.  either, an and that are
the things that are confusing to me.


Return TYPE if no type compatible with TYPE has been seen so far, 
otherwise return a type compatible with TYPE that has already been 
processed.


Or,

Find a type compatible with TYPE among those that have been processed, 
and return it.  If none can be found, register and return TYPE.


(It took me two/three iterations to read your message too.  You want to 
quote "either", "an" and "that" probably...).


Paolo

Re: Clarification request for ipa/cgraph code

[Brooks Moses]

Steven Bosscher wrote:

On 5/9/07, Mike Stump <[EMAIL PROTECTED]> wrote:

In ipa-type-escape.c we have:

  /* Return either TYPE if this is first time TYPE has been seen an
 compatible TYPE that has already been processed.  */

I'd fix it, if I knew I knew what it meant.  either, an and that are
the things that are confusing to me.


Your message is itself also a bit confusing. Fix what? What did you
mean in the "an and" sentence?


Fix the incomprehensible pre-existing comment he quoted by converting it 
to a comprehensible one, I suppose.  The words "either", "an", and 
"that" in the comment in question are things he finds particularly 
confusing about the sentence.


- Brooks

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

Aaron Gray wrote:

One issue that might affect many some is that COM doesn't work. 
 has a patch that is 
pending review I guess, but probably won't go into 4.2.



Does this effect XPCOM meaning Mozilla and friends will not compile ?


It is triggered anywhere multiple inheritance is combined with stdcall. 
Since I believe XPCOM uses stdcall on Windows (but "cdecl" on other 
targets), I believe the answer here is 'Yes, Mozilla will not compile.'


Mozilla is built using Microsoft cl on Windows. And if 'cdecl' is used on 
Unix then there is no problem with XPCOM and GCC 4.2.0 RC3.


Aaron

Re: Clarification request for ipa/cgraph code

[Mike Stump]

On May 9, 2007, at 2:33 PM, Steven Bosscher wrote:

On 5/9/07, Mike Stump <[EMAIL PROTECTED]> wrote:

In ipa-type-escape.c we have:

 /* Return either TYPE if this is first time TYPE has been seen an
compatible TYPE that has already been processed.  */

I'd fix it, if I knew I knew what it meant.  either, an and that are
the things that are confusing to me.


Your message is itself also a bit confusing.


You find the sentence well written and understandable?  That utterance  
isn't part of the standard language gcc is written in.  Maybe a short  
video will help you understand at least one aspect that is wrong:


  http://tinyurl.com/2zgrch

:-)  Another thing that appears wrong is:

  compatible TYPE

it should be:

  compatible type

as near as I can tell.

   a type compatible with TYPE

might be yet another way to express it.

Re: Clarification request for ipa/cgraph code

[Steven Bosscher]

On 5/9/07, Mike Stump <[EMAIL PROTECTED]> wrote:

In ipa-type-escape.c we have:

  /* Return either TYPE if this is first time TYPE has been seen an
 compatible TYPE that has already been processed.  */

I'd fix it, if I knew I knew what it meant.  either, an and that are
the things that are confusing to me.


Your message is itself also a bit confusing. Fix what? What did you
mean in the "an and" sentence?

Gr.
Steven

Clarification request for ipa/cgraph code

[Mike Stump]

In ipa-type-escape.c we have:

  /* Return either TYPE if this is first time TYPE has been seen an
 compatible TYPE that has already been processed.  */

I'd fix it, if I knew I knew what it meant.  either, an and that are
the things that are confusing to me.

RE: MinGW, GCC Vista,

[Eric Weddington]

 

> -Original Message-
> From: Brian Dessent [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, May 08, 2007 3:21 PM
> To: Mark Mitchell
> Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]
> Subject: Re: MinGW, GCC Vista,
> 
> Mark Mitchell wrote:
> 
> > In my opinion, this is a GCC bug: there's no such thing as X_OK on
> > Windows (it's not in the Microsoft headers, or documented 
> by Microsoft
> > as part of the API), and so GCC shouldn't be using it.  The Vista
> > runtime library chooses to issue an error when you set 
> random bits in
> > the mode provided to access, which is its privilege.
> > 
> > There's a simple GCC change to fix this: have libiberty 
> wrap the access
> > function and mask out X_OK on non-Cygwin Windows.  It's 
> reasonable to
> > put this change in libiberty, since it's job is to provide 
> portability
> > between systems.
> 
> This is also true, so I suppose it's not entirely correct to say that
> this is not a gcc issue in the slightest.  This above should indeed go
> into libiberty as the long term solution.

I would have thought that too.

For reference, there is this GCC bug report:


Eric Weddington

Re: MinGW, GCC Vista,

[Ross Ridge]

Mark Mitchell writes:
>(Again, I'm not trying to be critical: I like MinGW, and it's not my
>place to say what it ought to be.  I'm just giving feedback as a user.)

Well, it's no more my place to say what it ought to be.  I'm basically
just describing what MinGW is, a Win32 compiler like Borland C++, not
a drop-in Visual C++ replacement like Intel's Win32 compiler.

>To me, the fact that it uses the MSVCRT runtime library is very
>important, and the Visual C++ interoperability is important. 

Using MSVCRT.DLL only makes MinGW's runtime mostly compatible with Visual
C++ 6.0 (and I think 5.0).  Newer versions of Visual C++ use different
runtime libraries, so that interoperability is becoming less relevent
over time.

Ross Ridge

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

Aaron Gray wrote:

One issue that might affect many some is that COM doesn't work. 
 has a patch that 
is pending review I guess, but probably won't go into 4.2.



Does this effect XPCOM meaning Mozilla and friends will not compile ?


It is triggered anywhere multiple inheritance is combined with stdcall. 
 Since I believe XPCOM uses stdcall on Windows (but "cdecl" on other 
targets), I believe the answer here is 'Yes, Mozilla will not compile.'


But its fine on Unix platforms, that is good.

I am not sure if MinGW will/is used to compile Mozilla on Windows anyway.

I think it's likely that mingw.org will include this fix in their own 
releases of 4.2, which is probably a bad thing, as it makes the need to 
get this fix into official GCC sources seem less urgent.  A lot of GCC 
patches for Windows-related issues tend to stall for a long time in this 
state; I'm not really sure why.


Yes, this is perplexing.

Aaron

Re: live insns deleted by delete_trivially_dead_insns()

[Rask Ingemann Lambertsen]

On Tue, May 08, 2007 at 07:41:55AM -0700, Ian Lance Taylor wrote:
 
> The issue here is that we have a libcall without the REG_EQUAL note.
> That is sensible for a REG_NO_CONFLICT block.  Normally gcc will only
> build REG_NO_CONFLICT blocks for code which lower-subreg can't pick
> apart anyhow.  Your backend appears to be an exception.

   The way the alignment check in the memcmp() function is coded might make
a difference: (((long) s1 | (long) s2) & 3) != 0 with char *s1, s2 because
the sign extension of s1 and s2 is not decomposable.

> This may be the right patch.  I have no good way to test it.
> 
> Ian
> 
> Index: lower-subreg.c
> ===
> --- lower-subreg.c(revision 124389)
> +++ lower-subreg.c(working copy)
> @@ -1128,6 +1128,8 @@ decompose_multiword_subregs (bool update
>   {
> changed = true;
>  
> +   remove_retval_note (insn);
> +
> recog_memoized (insn);
> extract_insn (insn);
>  
> @@ -1157,6 +1159,8 @@ decompose_multiword_subregs (bool update
> i = apply_change_group ();
> gcc_assert (i);
>  
> +   remove_retval_note (insn);
> +
> changed = true;
>   }
>   }
> 

   Your patch seems to work fine. After jump, we have:

(insn 51 50 52 3 memcmp.c:81 (set (reg/f:HI 70 [ s2 ])
(reg/v/f:HI 59 [ s2 ])) 24 {*movhi} (nil)
(nil))

(insn 52 51 53 3 memcmp.c:81 (set (reg:SI 69 [ s2 ])
(sign_extend:SI (reg/f:HI 70 [ s2 ]))) 508 {*extendhisi2} (nil)
(expr_list:REG_EQUAL (sign_extend:SI (reg/v/f:HI 59 [ s2 ]))
(nil)))

(insn 53 52 54 3 memcmp.c:81 (set (reg/f:HI 72 [ s1 ])
(reg/v/f:HI 60 [ s1 ])) 24 {*movhi} (nil)
(nil))

(insn 54 53 57 3 memcmp.c:81 (set (reg:SI 71 [ s1 ])
(sign_extend:SI (reg/f:HI 72 [ s1 ]))) 508 {*extendhisi2} (nil)
(expr_list:REG_EQUAL (sign_extend:SI (reg/v/f:HI 60 [ s1 ]))
(nil)))

(insn 57 54 55 3 memcmp.c:81 (clobber (reg:SI 73)) -1 (nil)
(insn_list:REG_LIBCALL 56 (nil)))

(insn 55 57 56 3 memcmp.c:81 (parallel [
(set (subreg:HI (reg:SI 73) 0)
(ior:HI (subreg:HI (reg:SI 69 [ s2 ]) 0)
(subreg:HI (reg:SI 71 [ s1 ]) 0)))
(clobber (reg:CC 13 cc))
]) 123 {*iorhi3} (nil)
(expr_list:REG_NO_CONFLICT (reg:SI 69 [ s2 ])
(expr_list:REG_NO_CONFLICT (reg:SI 71 [ s1 ])
(nil

(insn 56 55 60 3 memcmp.c:81 (parallel [
(set (subreg:HI (reg:SI 73) 2)
(ior:HI (subreg:HI (reg:SI 69 [ s2 ]) 2)
(subreg:HI (reg:SI 71 [ s1 ]) 2)))
(clobber (reg:CC 13 cc))
]) 123 {*iorhi3} (nil)
(insn_list:REG_RETVAL 57 (expr_list:REG_NO_CONFLICT (reg:SI 69 [ s2 ])
(expr_list:REG_NO_CONFLICT (reg:SI 71 [ s1 ])
(nil)

(insn 60 56 58 3 memcmp.c:81 (clobber (reg:SI 74)) -1 (nil)
(nil))

(insn 58 60 59 3 memcmp.c:81 (set (subreg:HI (reg:SI 74) 0)
(const_int 3 [0x3])) 24 {*movhi} (nil)
(nil))

(insn 59 58 63 3 memcmp.c:81 (set (subreg:HI (reg:SI 74) 2)
(const_int 0 [0x0])) 24 {*movhi} (nil)
(nil))

(insn 63 59 61 3 memcmp.c:81 (clobber (reg:SI 75)) -1 (nil)
(insn_list:REG_LIBCALL 62 (nil)))

(insn 61 63 62 3 memcmp.c:81 (parallel [
(set (subreg:HI (reg:SI 75) 0)
(and:HI (subreg:HI (reg:SI 73) 0)
(subreg:HI (reg:SI 74) 0)))
(clobber (reg:CC 13 cc))
]) 121 {*andhi3} (nil)
(expr_list:REG_NO_CONFLICT (reg:SI 73)
(expr_list:REG_NO_CONFLICT (reg:SI 74)
(nil

(insn 62 61 64 3 memcmp.c:81 (parallel [
(set (subreg:HI (reg:SI 75) 2)
(and:HI (subreg:HI (reg:SI 73) 2)
(subreg:HI (reg:SI 74) 2)))
(clobber (reg:CC 13 cc))
]) 121 {*andhi3} (nil)
(insn_list:REG_RETVAL 63 (expr_list:REG_NO_CONFLICT (reg:SI 73)
(expr_list:REG_NO_CONFLICT (reg:SI 74)
(nil)

(insn 64 62 65 3 memcmp.c:81 (set (reg:HI 76)
(subreg:HI (reg:SI 75) 0)) 24 {*movhi} (nil)
(nil))

(insn 65 64 66 3 memcmp.c:81 (parallel [
(set (reg:HI 76)
(ior:HI (reg:HI 76)
(subreg:HI (reg:SI 75) 2)))
(clobber (reg:CC 13 cc))
]) 123 {*iorhi3} (nil)
(nil))

(insn 66 65 67 3 memcmp.c:81 (set (reg:CC 13 cc)
(compare:CC (reg:HI 76)
(const_int 0 [0x0]))) 482 {*cmphi_const0_cc} (nil)
(nil))

(jump_insn 67 66 68 3 memcmp.c:81 (set (pc)
(if_then_else (ne (reg:CC 13 cc)
(const_int 0 [0x0]))
(label_ref 93)
(pc))) 562 {*bne_cc} (nil)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)))

   After subreg:

;; Function memcmp (memcmp)

; Splitting reg 73 -> 89 90
;

Re: live insns deleted by delete_trivially_dead_insns()

[Rask Ingemann Lambertsen]

On Mon, May 07, 2007 at 10:12:21PM +0200, Paolo Bonzini wrote:
> 
> Can you also check -fno-forward-propagate?

   With plain -O2, insn 61 disappears in the fwprop1 dump. With -O2
-fno-forward-propagate, insn 61 disappears in the gcse1 dump instead.

-- 
Rask Ingemann Lambertsen

Re: 2nd quarter of 2007 and no GPL code of Java from Sun.

[Andrew Haley]

J.C. Pizarro writes:

 > there are any news from JavaOne?

Yes, there is.

You are *way* off-topic.  Please desist from spamming this list with
questions about non-GNU code.  Go to http://openjdk.java.net/ and
pester them instead.

Andrew.

Re: Mercurial repository set up for GCC that mirrors SVN

[Paolo Bonzini]

Ollie Wild wrote:

Just another data point, my git-svn clone of trunk comes in at 414MB,
excluding the size of checked out files.  I'm assuming the public svn
is the complete history.


I'm about 35% through the process of cloning the entire gcc repository
via git-svnimport, and the .git directory is 5.0GB.  This includes all
branches.


Running git-gc more often during the first 60-7 revisions will help 
a lot as far as disk space is concerned.  git is killed by the same 
branches that killed cvs2svn in the first place.


Paolo

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron W. LaFramboise]

Aaron Gray wrote:

One issue that might affect many some is that COM doesn't work. 
 has a patch that 
is pending review I guess, but probably won't go into 4.2.



Does this effect XPCOM meaning Mozilla and friends will not compile ?


It is triggered anywhere multiple inheritance is combined with stdcall. 
 Since I believe XPCOM uses stdcall on Windows (but "cdecl" on other 
targets), I believe the answer here is 'Yes, Mozilla will not compile.'


I think it's likely that mingw.org will include this fix in their own 
releases of 4.2, which is probably a bad thing, as it makes the need to 
get this fix into official GCC sources seem less urgent.  A lot of GCC 
patches for Windows-related issues tend to stall for a long time in this 
state; I'm not really sure why.