Re: G++ test suite picking up incorrect libstc++

2010-10-23 Thread Ralf Wildenhues 
Hello Michael,

* Michael Eager wrote on Fri, Oct 22, 2010 at 10:35:48PM CEST:
> Paolo Carlini wrote:
> >On 10/22/2010 08:43 PM, Michael Eager wrote:
> >>I'm seeing test suite failures in g++ caused by
> >>linking with the wrong libstdc++.so.
> >>
> >>It looks like g++.exp always appends the default
> >>directory
> >>  append flags -L${gccpath}/libstdc++-v3/src/.libs
> >>instead of
> >>  append flags -L${gccpath}//libstdc++-v3/src/.libs
> 
> >Without having looked into the issue in any detail, the issue seems
> >weird to me: for sure many people regularly build multilib (myself and
> >HJ on gcc-testresults included, for example) without any problem
> >whatsoever. I would suggest figuring out first what's special about your
> >setup.
> 
> I don't know that there's anything special about my setup.
> g++.exp is adding -L paths to the wrong libstdc++ directory.
> When running GCC tests, only the -B option is added.  The
> correct multilib directory is selected by the gcc driver.

Is this a recent regression, maybe since r165727?
Please show how your compiler was configured (.../g++ -v)?

Thanks,
Ralf

Re: G++ test suite picking up incorrect libstc++

2010-10-23 Thread Michael Eager 

Ralf Wildenhues wrote:

Hello Michael,

* Michael Eager wrote on Fri, Oct 22, 2010 at 10:35:48PM CEST:

Paolo Carlini wrote:

On 10/22/2010 08:43 PM, Michael Eager wrote:

I'm seeing test suite failures in g++ caused by
linking with the wrong libstdc++.so.

It looks like g++.exp always appends the default
directory
 append flags -L${gccpath}/libstdc++-v3/src/.libs
instead of
 append flags -L${gccpath}//libstdc++-v3/src/.libs

Without having looked into the issue in any detail, the issue seems
weird to me: for sure many people regularly build multilib (myself and
HJ on gcc-testresults included, for example) without any problem
whatsoever. I would suggest figuring out first what's special about your
setup.

I don't know that there's anything special about my setup.
g++.exp is adding -L paths to the wrong libstdc++ directory.
When running GCC tests, only the -B option is added.  The
correct multilib directory is selected by the gcc driver.


Is this a recent regression, maybe since r165727?
Please show how your compiler was configured (.../g++ -v)?


This in in an off-tree repository, based on gcc-4.4.1.

I'm going to try to duplicate HJ's test and see what
the differences area.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: peephole2: dead regs not marked as dead

2010-10-23 Thread Paolo Bonzini 

On 10/22/2010 01:16 PM, Georg Lay wrote:

Then the first insn gets split after reload and before peephole2:

(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
 (and:SI (reg:SI 4 d4 [ x ])
 (const_int -98305 [0xfffe7fff]))) 143 {*and3_zeroes.insert.{SI}.ic}
(nil))

(insn 23 22 21 2 peep2.c:5 (set (reg:SI 15 d15)
 (xor:SI (reg:SI 15 d15)
 (reg:SI 4 d4 [ x ]))) 39 {*xorsi3} (nil))

(insn 21 23 10 2 peep2.c:5 (set (reg:SI 4 d4)
 (reg:SI 15 d15)) 2 {*movsi_insn} (nil))

(call_insn/j 10 21 11 2 peep2.c:5 (parallel [
 (set (reg:SI 2 d2)
 (call (mem:HI (symbol_ref:SI ("f") [flags 0x41]) [0 S2 A16])
 (const_int 0 [0x0])))
 (use (const_int 1 [0x1]))
 ]) 92 {call_value_insn} (nil)
 (expr_list:REG_DEP_TRUE (use (reg:SI 4 d4))
 (nil)))
;; End of basic block 2 ->  ( 1)
;; lr  out   2 [d2] 26 [SP] 27 [a11]
;; live  out 2 [d2] 26 [SP] 27 [a11]
;; Succ edge  EXIT [100.0%]  (ab,sibcall)

(barrier 11 10 20)

D15, is not marked as dead


True.  It should have had a REG_DEAD note.  Are you using 4.6 (which 
scans forwards in peephole2 and requires REG_DEAD notes) or 4.5 (which 
scans backwards)?  If the latter, the absence of the note could be a red 
herring, because 4.5 didn't need REG_DEAD notes so it didn't compute them.


What's your definition of CALL_USED_REGISTERS, 
CALL_REALLY_USED_REGISTERS, EPILOGUE_USES?  Is d15 in any of them?


Paolo

gcc-4.6-20101023 is now available

2010-10-23 Thread gccadmin 
Snapshot gcc-4.6-20101023 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101023/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 165891

You'll find:

 gcc-4.6-20101023.tar.bz2 Complete GCC (includes all of below)

  MD5=f81eb262d611da87a0d0609f3ee321dc
  SHA1=7272459b573daead227216ca7a852c06a3898cfa

 gcc-core-4.6-20101023.tar.bz2C front end and core compiler

  MD5=ff8bb82f463e3add36d27bbcea28c519
  SHA1=7969f5fcd575fd6a163ff35da66e9e59b900de36

 gcc-ada-4.6-20101023.tar.bz2 Ada front end and runtime

  MD5=80d6a6ef187a2c47b1a6a082f93e2cd8
  SHA1=5a5e250fc3e8d92eff067a138d13a97f0bd891ad

 gcc-fortran-4.6-20101023.tar.bz2 Fortran front end and runtime

  MD5=567620e7942a0a001e472cb08fe51d79
  SHA1=9a30e1074efdedeaa5ba6e087e3d7b756272c745

 gcc-g++-4.6-20101023.tar.bz2 C++ front end and runtime

  MD5=53d7021bf1d3b077bb7f4b1b7c856ae2
  SHA1=262a15b5bcbde21ea289a8f5eee3ec409777bcd4

 gcc-java-4.6-20101023.tar.bz2Java front end and runtime

  MD5=5a66d9decf07141686c034098ca38752
  SHA1=2561d5d59bae3f598e917c0dfb59bd1bdbcda704

 gcc-objc-4.6-20101023.tar.bz2Objective-C front end and runtime

  MD5=1f45315a712919235e5f2396aead624c
  SHA1=92928b537599d0005e0d0f14e51a42d68ed273d9

 gcc-testsuite-4.6-20101023.tar.bz2   The GCC testsuite

  MD5=a312901483c38e6978febc6b1d1d2f77
  SHA1=48528992403956abdb244fb943530c3d871d8ec4

Diffs from 4.6-20101016 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.