[Bug target/49688] [alpha]: Many execution test failures

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49688

--- Comment #15 from Uros Bizjak  2011-07-15 07:08:46 
UTC ---
Results with a patched compiler [1], no regressions.

[1] http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01678.html

[Bug ada/48711] [4.6/4.7 regression] failure to bootstrap or build ada for mingw (value not in range of type "Interfaces.C.unsigned" in g-socthi.adb)

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48711

Eric Botcazou  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #15 from Eric Botcazou  2011-07-15 
07:21:09 UTC ---
For real.

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #4 from H.Merijn Brand  2011-07-15 
07:39:01 UTC ---
On Thu, 14 Jul 2011 20:34:46 +, "sje at cup dot hp.com"
 wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
> 
> Steve Ellcey  changed:
> 
> --- Comment #2 from Steve Ellcey  2011-07-14 20:34:28 
> UTC ---
> Are you trying to use a 32 bit GCC to bootstrap a 64 bit GCC?

No, a full 64bit gcc-3.4.6

> I see you have CC set to gcc64 which makes me think that you are using

gcc32 is a symlink to /usr/local/pa20_32/bin/gcc
gcc64 is a symlink to /usr/local/pa20_64/bin/gcc

While building gcc-4.6.1, I made sure /usr/local/pa20_64/bin is in the
front of my $PATH

> a 64 bit GCC to do the bootstrap but you have -mpa-risc-2-0 in CFLAGS,

I do so because I know some configurations store the flags to be used
later by other applications. If this is a problem, I'll leave it off.

> which I think means the 32 bit 2.0 instruction set and I don't think it
> should be used for 64 bit builds.
> 
> Can you bootstrap if you leave off the -mpa-risc-2-0 flag?

I'll try

[Bug fortran/49755] New: ALLOCATE with STAT= produces invalid code for already allocated vars

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49755

   Summary: ALLOCATE with STAT= produces invalid code for already
allocated vars
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: dcarr...@gcc.gnu.org
Blocks: 32834


The Fortran standard states that ALLOCATEing an already allocated variable is
an error.

gfortran nicely aborts with a run-time error if there is no STAT= variable.
However, if there is STAT= variable, instead of just setting it and stopping,
gfortran deallocates the variable and then tries the new allocation.


There are several issues with that:

(a) It's invalid according to the Fortran standard, which states in
"6.7.4 STAT= specifier":
"* each allocate-object that was not successfully allocated or
   deallocated shall retain its previous allocation status
   or pointer association status."

(b) It adds lots of code, which should be most of the time not used,
increasing the code size and making optimizations more difficult,
especially for derived types with allocatable components

(c) With coarrays, there are even more issues - one shall not simply
free a coarray unilaterally!



Test case (except for the "abort" function, valid Fortran 2008):


integer, allocatable :: A(:, :)
integer :: stat

allocate(A(20,20))
A = 42

! Allocate of already allocated variable
allocate (A(5,5), stat=stat)

! Expected: Error stat and previous allocation status

if (stat == 0) call abort ()
if (any (shape (A) /= [20, 20])) call abort ()
if (any (A /= 42)) call abort ()
end

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #5 from H.Merijn Brand  2011-07-15 
08:34:49 UTC ---
On Thu, 14 Jul 2011 22:07:10 +, "dave.anglin at bell dot net"
 wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
> 
> --- Comment #3 from dave.anglin at bell dot net 2011-07-14 22:06:49 UTC ---
> On 7/14/2011 4:35 PM, sje at cup dot hp.com wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
> >
> > --- Comment #2 from Steve Ellcey  2011-07-14 
> > 20:34:28 UTC ---
> > Are you trying to use a 32 bit GCC to bootstrap a 64 bit GCC?  I see you 
> > have
> > CC set to gcc64 which makes me think that you are using a 64 bit GCC to do 
> > the
> > bootstrap but you have -mpa-risc-2-0 in CFLAGS, which I think means the 32 
> > bit
> > 2.0 instruction set and I don't think it should be used for 64 bit builds.
> >
> > Can you bootstrap if you leave off the -mpa-risc-2-0 flag
>
> The flag shouldn't matter.  hppa64 is always PA 2.0.  hppa64 is also 
> always PIC, so -fPIC is also redundant.
> 
> The issue is with the bootstrap compiler gcc64.  Is it actually 3.4.6 
> (gcc64 -v)?

Yes, as I said in my OP

$ gcc64 -v
Reading specs from
/wrk/pa20_64-4.6.1/bin/../lib/gcc/hppa64-hp-hpux11.11/3.4.6/specs
Configured with: ../src/configure --enable-languages=c,c++
--prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
--with-gnu-as --with-as=/usr/local/pa20_64/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --disable-shared --disable-nls
--host=hppa64-hp-hpux11.11
Thread model: single
gcc version 3.4.6

> Did gmp and mpfr compile and check ok with it?

Yes, as I said in my OP

> These need to be 64-bit.

They are

$ file /usr/local/pa20_64/lib/libmpfr.sl
/usr/local/pa20_64/lib/libmpfr.sl:  ELF-64 shared object file - PA-RISC 2.0
(LP64)
$ file /usr/local/pa20_64/lib/libmpc.sl
/usr/local/pa20_64/lib/libmpc.sl:   ELF-64 shared object file - PA-RISC 2.0
(LP64)
$ file /usr/local/pa20_64/lib/libgmp.sl
/usr/local/pa20_64/lib/libgmp.sl:   ELF-64 shared object file - PA-RISC 2.0
(LP64)

> The 64-bit 3.X versions of hppa64 were somewhat buggy and there were 
> also some buggy distributions.

I build it myself from scratch. I never managed to build a gcc-4.x.x on
PA-RISC: All 64bit versions did not pass the perl compile test

> If your gcc64 compiled gmp and mpfr ok, I would suggest trying to build 
> a early 4.X release, then jump to 4.6.

I've tried and tried but always failed to get a reliable working 4.x

> This may avoid the out of range field.

So in fact you suggest to build an unreliable 4.x, then use it to build
4.6.1 hoping *that* would be reliable?

> I think that you also need a separate 64-bit version of gas.  I'm not 
> sure SOM and ELF can be supported with a single gas binary.

All binaries in /usr/local/pa20_64/bin are 64bit:

$ file /usr/local/pa20_64/bin/*as
/usr/local/pa20_64/bin/as:  ELF-64 executable object file - PA-RISC 2.0
(LP64)
/usr/local/pa20_64/bin/gas: ELF-64 executable object file - PA-RISC 2.0
(LP64)

> HP uses a wrapper.  I always compiler two separate versions of binutils.

I do so too

> GCC on PA-RISC can't easily support both 32 and 64-bit targets because 
> of the differences between SOM and ELF.

I know

> This is not a blocker since the bug is in the bootstrap compiler.
> 
> If you add -save-temps to the failing compile, this will save the 
> assembler output.  This will allow inspection of the problematic
> instructions.  I would guess we are dealing with a bl or b instruction.
> A b,l instruction would have a 21-bit range.
> 
> Dave

[Bug c/49754] Let gcc warn about all uninitialized variables

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754

--- Comment #1 from Jonathan Wakely  2011-07-15 
08:36:30 UTC ---
(In reply to comment #0)
> == Expected Results ==  
> foo.c: In function ‘foo’:
> foo.c:2:?: warning: ‘x’ is used uninitialized in this function

It should really warn if 'x.i' is used uninitialized, not 'x'

[Bug testsuite/49643] FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49643

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #8 from Mikael Pettersson  2011-07-15 
09:09:42 UTC ---
(In reply to comment #7)
> Fixed.

Almost, the test case was added to gcc-4_5-branch too, but the fix hasn't been
applied there yet.  It's failing on arm-linux-gnueabi because of that.

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541

--- Comment #12 from Eric Botcazou  2011-07-15 
09:31:05 UTC ---
> Here's the libgomp testsuite part of the patch. It should apply to both
> mainline and 4.6 branch.  I've lightly tested the approach by checking one of 
> the testcases on sparc-sun-solaris2.8, but on Solaris 8 bare metal the libgomp
> testsuite should now be failure free.

Confirmed.

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541

--- Comment #11 from Eric Botcazou  2011-07-15 
09:30:09 UTC ---
> Here's the 4.6 backport of the sol2.h patch.  Could you please give it a try 
> on
> Solaris 8 on bare metal?  I've bootstrapped it without regressions on
> sparc-sun-solaris2.8 and i386-pc-solaris2.8.

Works for me, thanks.

[Bug c/49754] Let gcc warn about all uninitialized variables

[giecrilj at stegny dot 2a.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754

--- Comment #2 from Christopher Yeleighton  
2011-07-15 09:35:42 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > == Expected Results ==  
> > foo.c: In function ‘foo’:
> > foo.c:2:?: warning: ‘x’ is used uninitialized in this function
> 
> It should really warn if 'x.i' is used uninitialized, not 'x'

Since (x) is uninitialized, so is (x.i).  It is impossible to recognize the
problem when (x.i) is eventually accessed by a client of foo:

{
struct i x = foo (); 
printf ("%i", +x.i);
}

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541

--- Comment #13 from Rainer Orth  2011-07-15 09:39:43 
UTC ---
Author: ro
Date: Fri Jul 15 09:39:41 2011
New Revision: 176309

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176309
Log:
Backport from mainline:
2011-07-13  Rainer Orth  

PR target/49541
* config/sol2.h (LIB_SPEC): Simplify.
Move LIB_THREAD_LDFLAGS_SPEC ...
(LINK_SPEC): ... here.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/sol2.h

[Bug c/49754] Let gcc warn about all uninitialized variables

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754

--- Comment #3 from Jonathan Wakely  2011-07-15 
09:56:49 UTC ---
(In reply to comment #2)
> Since (x) is uninitialized, so is (x.i).

But what if x.i gets initialized, is x still uninitialized?


struct X { int i; };
struct Y { int i; int j; };

int main()
{
  X x;
  x.i = 0;   // is 'x' initialized now?
  Y y;
  y.i = 0;   // is 'y' initialized now?
  y.j = 0;   // is 'y' initialized now?
}


It would be possible to track the initialization of each subobject *and* the
aggregate, but it would be more overhead

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835

--- Comment #24 from Mikael Pettersson  2011-07-15 
10:11:45 UTC ---
I've uploaded gcc-4.5.3 bootstrap binaries and my gcc-4.5.3 m68k patches to
.

A gcc-4.6.1 bootstrap is in progress.

[Bug c/49754] Let gcc warn about all uninitialized variables

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754

--- Comment #4 from Jonathan Wakely  2011-07-15 
10:16:12 UTC ---
Just to be clear - I completely agree that uninit'd warnings need improving,
I'm not objecting to that.  But in my experience (mostly C++) I'd prefer to
have it tracked at the more fine-grained level of sub-objects.

[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745

--- Comment #15 from Paolo Carlini  2011-07-15 
10:24:15 UTC ---
By the way, Jakub, correct me if I'm wrong and/or remember incorrectly what we
decided here at the time, but as far as I can see there is no risk with
__gthread_mutex_timedlock, because if it's unavailable, _GLIBCXX_HAS_GTHREADS
is undefined and the entire  ins't available. It can be argued that we
should do this in a finer grained way, but that's another issue...

[Bug tree-optimization/49756] New: g++ ICE

[doko at ubuntu dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49756

   Summary: g++ ICE
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@ubuntu.com


Created attachment 24773
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24773
preprocessed source

[forwarded from http://launchpad.net/bugs/721378]

might related to PR48766, although I don't see the recursion in
fold_binary_loc(). seen with current 4.4, 4.5, 4.6 branches and trunk.

$ g++ -c testcase.ii 
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.

Program received signal SIGSEGV, Segmentation fault.
0x008046dc in fold_binary_loc ()
(gdb) bt
#0  0x008046dc in fold_binary_loc ()
#1  0x008905e2 in gimplify_expr ()
#2  0x00895269 in ?? ()
#3  0x0089067e in gimplify_expr ()
#4  0x0089f7a2 in ?? ()
#5  0x00891188 in gimplify_expr ()
#6  0x008a22f9 in ?? ()
#7  0x0088fd3e in gimplify_expr ()
#8  0x00898367 in gimplify_stmt ()
#9  0x0089f41d in ?? ()
#10 0x008916f0 in gimplify_expr ()
#11 0x008961b3 in ?? ()
#12 0x0088fcd5 in gimplify_expr ()
#13 0x00898367 in gimplify_stmt ()
#14 0x00890b9e in gimplify_expr ()
#15 0x00898367 in gimplify_stmt ()
#16 0x00898d5c in ?? ()
#17 0x00891414 in gimplify_expr ()
#18 0x00898367 in gimplify_stmt ()
#19 0x008908a9 in gimplify_expr ()
#20 0x00898367 in gimplify_stmt ()
#21 0x00898d5c in ?? ()
#22 0x00891414 in gimplify_expr ()
#23 0x00898367 in gimplify_stmt ()
#24 0x008908a9 in gimplify_expr ()
#25 0x00898367 in gimplify_stmt ()
[...]

bug submitter writes:

- if you comment out the ~Base destructor, the ICE goes away.

- The ICE also goes away if you significantly reduce the number of Child
members in the Container class.

[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745

--- Comment #16 from Jakub Jelinek  2011-07-15 
10:47:46 UTC ---
Then you probably could use _GLIBCXX_HAS_GTHREADS as the macro to avoid
including unistd.h and assuming that _POSIX_TIMEOUT is defined.
Though perhaps better would be to call it _GTHREADS_ASSUME_POSIX_TIMEOUTS or
similar and define it in some libstdc++ headers before including gthr.h.

[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745

--- Comment #17 from Paolo Carlini  2011-07-15 
10:53:11 UTC ---
Indeed, I was having the same thought... _GLIBCXX_HAS_GTHREADS is a bit
stricter though (doesn't allow 0), but would do. And I agree that in that case
we should use another name. Essentially, about the ordering, just double check
that, as should normally be, c++config.h is included before anything else.

[Bug testsuite/49741] make -k check-c++0x not multilib aware

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49741

--- Comment #6 from Jack Howarth  2011-07-15 
10:55:21 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > Created attachment 24772 [details]
> > Patch to use --zadditional_options instead of --tool_opts
> > 
> > Does this work better?
> 
> Yes. This eliminates the failures at -m32 for the x86_64-apple-darwin11
> multilib build. Thanks.

Results with patch are at
http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01684.html.

[Bug c/49754] Let gcc warn about all uninitialized variables

[giecrilj at stegny dot 2a.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754

--- Comment #5 from Christopher Yeleighton  
2011-07-15 11:00:28 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Since (x) is uninitialized, so is (x.i).
> 
> But what if x.i gets initialized, is x still uninitialized?

If (x.i) denotes an object type and the initial value means "x is empty" then x
is initialized.

> 
> struct X { int i; };
> struct Y { int i; int j; };
> 
> int main()
> {
>   X x;
>   x.i = 0;   // is 'x' initialized now?
>   Y y;
>   y.i = 0;   // is 'y' initialized now?
>   y.j = 0;   // is 'y' initialized now?
> }
> 
> 
> It would be possible to track the initialization of each subobject *and* the
> aggregate, but it would be more overhead

I have already bumped into this using arrays, where GCC does emit a warning
although it should not:

int a [02]; 
for (a [0] = 0;;) if (a [0]) printf ("%d", +a [1]); else a [0] = a [1] = 01;

[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot |
   |com |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.7.0

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-15 12:01:02 UTC ---
> The problem is that the testsuite (lib/libgomp.exp) unconditionally
> links with -lgomp even for the -fno-openmp testcases.  I'd argue that
> this is a testsuite-only problem (pilot error, actually) and can be
> worked around by use of dg-add-options tls.

On second thought, it seems better to just remove the explicit -lgomp.

The following patch worked for me on sparc-pc-solaris2.8,
i386-pc-solaris2.10, and x86_64-unknown-linux-gnu:

diff --git a/libgomp/testsuite/lib/libgomp.exp
b/libgomp/testsuite/lib/libgomp.exp
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -137,7 +137,6 @@ proc libgomp_init { args } {
 lappend ALWAYS_CFLAGS "ldflags=-L${blddir}/.libs"
 }
 lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/.."
-lappend ALWAYS_CFLAGS "ldflags=-lgomp"

 # We use atomic operations in the testcases to validate results.
 if { ([istarget i?86-*-*] || [istarget x86_64-*-*])

Rainer

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541

Rainer Orth  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Rainer Orth  2011-07-15 12:04:20 
UTC ---
Jakub, do you see a reason to explicitly add -lgomp to ldflags in the libgomp
testsuite?  According to my testing, -fopenmp should take care of that, as my
testing confirms.

Thanks.
  Rainer

[Bug testsuite/49757] New: FAIL: gcc.target/tic6x/*.c

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49757

   Summary: FAIL: gcc.target/tic6x/*.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ber...@codesourcery.com


On Linux/x86, revision 176310 gave:

FAIL: gcc.target/tic6x/builtins/extclr.c  -O0  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/extclr.c  -O1  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/extclr.c  -O2  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/extclr.c  -O2 -flto  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/extclr.c  -O2 -flto -flto-partition=none  (test
for excess errors)
FAIL: gcc.target/tic6x/builtins/extclr.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.target/tic6x/builtins/extclr.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/extclr.c  -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/extclr.c  -O3 -g  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/extclr.c  -Os  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/sarith1.c  -O0  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/sarith1.c  -O1  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/sarith1.c  -O2  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/sarith1.c  -O2 -flto  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/sarith1.c  -O2 -flto -flto-partition=none 
(test for excess errors)
FAIL: gcc.target/tic6x/builtins/sarith1.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.target/tic6x/builtins/sarith1.c  -O3 -g  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/sarith1.c  -Os  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpy.c  -O0  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpy.c  -O1  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpy.c  -O2  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpy.c  -O2 -flto  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpy.c  -O2 -flto -flto-partition=none  (test
for excess errors)
FAIL: gcc.target/tic6x/builtins/smpy.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.target/tic6x/builtins/smpy.c  -O3 -g  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpy.c  -Os  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpyh.c  -O0  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpyh.c  -O1  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpyh.c  -O2  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpyh.c  -O2 -flto  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpyh.c  -O2 -flto -flto-partition=none  (test
for excess errors)
FAIL: gcc.target/tic6x/builtins/smpyh.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.target/tic6x/builtins/smpyh.c  -O3 -g  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpyh.c  -Os  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpylh.c  -O0  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpylh.c  -O1  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpylh.c  -O2  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpylh.c  -O2 -flto  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpylh.c  -O2 -flto -flto-partition=none  (test
for excess errors)
FAIL: gcc.target/tic6x/builtins/smpylh.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.target/tic6x/builtins/smpylh.c  -O3 -g  (test for excess errors)
FAIL: gcc.target/tic6x/builtins/smpylh.c  -Os  (test for excess errors)

Why do we run TIC6X tests on Linux/x86?

[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745

Paolo Carlini  changed:

   What|Removed |Added

 CC||igodard at pacbell dot net

--- Comment #18 from Paolo Carlini  2011-07-15 
12:09:04 UTC ---
*** Bug 36231 has been marked as a duplicate of this bug. ***

[Bug libstdc++/36231] ostream includes unistd.h outside namespace std, polluting

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #20 from Paolo Carlini  2011-07-15 
12:09:04 UTC ---
49745 has a specific testcase

*** This bug has been marked as a duplicate of bug 49745 ***

[Bug testsuite/49757] FAIL: gcc.target/tic6x/*.c

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49757

--- Comment #1 from Bernd Schmidt  2011-07-15 
12:11:05 UTC ---
Author: bernds
Date: Fri Jul 15 12:11:00 2011
New Revision: 176313

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176313
Log:
PR testsuite/49757
* gcc/testsuite/gcc.target/tic6x/builtins/c6x-builtins.exp: Return if
not testing tic6x-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/tic6x/builtins/c6x-builtins.exp

[Bug middle-end/49545] [4.7 Regression] New C++ test failures

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49545

Ulrich Weigand  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #7 from Ulrich Weigand  2011-07-15 
12:51:20 UTC ---
I'm now seeing
FAIL: g++.dg/tree-ssa/fwprop-align.C scan-tree-dump-times forwprop2 "& 1" 0
on the 4.6 branch for spu-elf ...

Could this be the same problem?

[Bug testsuite/49753] [4.6/4.7 Regression] FAIL: g++.dg/torture/pr49309.C

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49753

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.6.2
Summary|FAIL:   |[4.6/4.7 Regression] FAIL:
   |g++.dg/torture/pr49309.C|g++.dg/torture/pr49309.C

--- Comment #1 from Jakub Jelinek  2011-07-15 
13:19:44 UTC ---
Ugh, mudflap tests never belong into gcc/testsuite/, they need to go into
libmudflap/ testsuite.

[Bug rtl-optimization/11320] [3.3 regression] Scheduler bug

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11320

--- Comment #11 from Bernd Schmidt  2011-07-15 
13:20:17 UTC ---
Author: bernds
Date: Fri Jul 15 13:20:10 2011
New Revision: 176315

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176315
Log:
Revert
2003-07-10  Eric Botcazou  
PR rtl-optimization/11320
* sched-int.h (struct deps) [reg_conditional_sets]: New field.
(struct sched_info) [compute_jump_reg_dependencies]: New prototype.
* sched-deps.c (sched_analyze_insn) [JUMP_INSN]: Update call to
current_sched_info->compute_jump_reg_dependencies. Record which
registers are used and which registers are set by the jump.
Clear deps->reg_conditional_sets after a barrier.
Set deps->reg_conditional_sets if the insn is a COND_EXEC.
Clear deps->reg_conditional_sets if the insn is not a COND_EXEC.
(init_deps): Initialize reg_conditional_sets.
(free_deps): Clear reg_conditional_sets.
* sched-ebb.c (compute_jump_reg_dependencies): New prototype.
Mark registers live on entry of the fallthrough block and conditionally
set as set by the jump. Mark registers live on entry of non-fallthrough
blocks as used by the jump.
* sched-rgn.c (compute_jump_reg_dependencies): New prototype.
Mark new parameters as unused.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/modulo-sched.c
trunk/gcc/sched-deps.c
trunk/gcc/sched-ebb.c
trunk/gcc/sched-int.h
trunk/gcc/sched-rgn.c

[Bug testsuite/49643] FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49643

--- Comment #9 from Jason Merrill  2011-07-15 
13:40:15 UTC ---
Author: jason
Date: Fri Jul 15 13:40:09 2011
New Revision: 176316

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176316
Log:
PR testsuite/49643
* g++.dg/rtti/anon-ns1.C: Allow for null-termination.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/rtti/anon-ns1.C

[Bug fortran/45170] [F2003] allocatable character lengths

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170

--- Comment #18 from Tobias Burnus  2011-07-15 
14:02:45 UTC ---
(In reply to comment #16)
>   Error: Variable 'length' cannot appear in the expression at (1)
> That comes from the specification expression check.

If one removes the check, it works, i.e. it is just a resolution (resolve.c)
problem and not a code generation one.


(In reply to comment #17)
>   subroutine hello (n,string)
> character(:),allocatable,intent(out)::string
> integer,intent(in)::n
> string=helloworld(:n)

That one seems to be a very subtle issue, depending on the modifications (e.g.
allocate(character(len=)) instead of alloc on assignment), one might get the
correct string length - or even the correct string. Looking at the (original)
dump, the string length should be always correct, hence, I think we generate a
slightly wrong tree. The next step would be to look at -fdump-tree-optimized
and then work backwards.

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #6 from dave.anglin at bell dot net 2011-07-15 14:41:19 UTC ---
On 7/15/2011 4:37 AM, h.m.brand at xs4all dot nl wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
>
> --- Comment #5 from H.Merijn Brand  2011-07-15 
> 08:34:49 UTC ---
> On Thu, 14 Jul 2011 22:07:10 +, "dave.anglin at bell dot net"
>   wrote:
>
> $ gcc64 -v
> Reading specs from
> /wrk/pa20_64-4.6.1/bin/../lib/gcc/hppa64-hp-hpux11.11/3.4.6/specs
> Configured with: ../src/configure --enable-languages=c,c++
> --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
> --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --without-gnu-ld
> --with-ld=/usr/ccs/bin/ld --disable-shared --disable-nls
> --host=hppa64-hp-hpux11.11
> Thread model: single
> gcc version 3.4.6
>
This looks ok.

>> If you add -save-temps to the failing compile, this will save the
>> assembler output.  This will allow inspection of the problematic
>> instructions.  I would guess we are dealing with a bl or b instruction.
>> A b,l instruction would have a 21-bit range.
To see what's wrong, the assembly code needs to be looked at.  The range 
that you
showed is characteristic of a 17-bit pc-relative branch.  In PA 2.0, 
calls use 21-bit
pc-relative branches.  If the .level directive is correct for the file, 
then the problem must
be due to an unconditional jump with an incorrect branch distance 
calculation.  I don't
believe there are any major problems with the branch distance 
calculations in 4.3 and
latter (last releases).

You might try working around this problem as follows:

1) Manually compile object that's failing with -O2.  This will reduce 
function sizes and
probably avoid the out of range error.  Then, restart bootstrap.  If 
build suceeds, install
new compiler and recheck that you can sucessfully bootstrap.  I suggest 
-O2 since
various reorg bugs appear at -O1.  This is simplest work around.

2) The other alternative is to abandon your gcc64 and build a new 
boostrap compiler
with HP aCC or C (ANSI).  I haven't tried this in some time.

3) I could provide you with a working bootstrap compiler. 
  Unfortunately, I can't make the file
publicly available.

If you get a working compiler going, it would be great if you could post 
it on the net as
you have done for some other builds.  Option 2 isn't that easy.

Dave

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #7 from H.Merijn Brand  2011-07-15 
15:17:38 UTC ---
On Fri, 15 Jul 2011 14:41:23 +, "dave.anglin at bell dot net"
 wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
> 
> --- Comment #6 from dave.anglin at bell dot net 2011-07-15 14:41:19 UTC ---
> On 7/15/2011 4:37 AM, h.m.brand at xs4all dot nl wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
> >
> > --- Comment #5 from H.Merijn Brand  2011-07-15 
> > 08:34:49 UTC ---
> > On Thu, 14 Jul 2011 22:07:10 +, "dave.anglin at bell dot net"
> >   wrote:
> >
> > $ gcc64 -v
> > Reading specs from
> > /wrk/pa20_64-4.6.1/bin/../lib/gcc/hppa64-hp-hpux11.11/3.4.6/specs
> > Configured with: ../src/configure --enable-languages=c,c++
> > --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
> > --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --without-gnu-ld
> > --with-ld=/usr/ccs/bin/ld --disable-shared --disable-nls
> > --host=hppa64-hp-hpux11.11
> > Thread model: single
> > gcc version 3.4.6
>
> This looks ok.
> 
> >> If you add -save-temps to the failing compile, this will save the
> >> assembler output.  This will allow inspection of the problematic
> >> instructions.  I would guess we are dealing with a bl or b instruction.
> >> A b,l instruction would have a 21-bit range.
>
> To see what's wrong, the assembly code needs to be looked at. The
> range that you showed is characteristic of a 17-bit pc-relative
> branch. In PA 2.0, calls use 21-bit pc-relative branches.  If the
> .level directive is correct for the file, then the problem must
> be due to an unconditional jump with an incorrect branch distance 
> calculation.  I don't believe there are any major problems with
> the branch distance calculations in 4.3 and latter (last releases).

I'm currently building with the 4.2.4 build I had lying around that
does not pass perl build/test. So far it goes much further. It is
already running (building) for over 4 hours now. The older the
architecture, the slower the machine :)

> You might try working around this problem as follows:
> 
> 1) Manually compile object that's failing with -O2.  This will
> reduce function sizes and probably avoid the out of range error.
> Then, restart bootstrap.  If build suceeds, install new compiler
> and recheck that you can sucessfully bootstrap.  I suggest 
> -O2 since various reorg bugs appear at -O1.  This is simplest
> work around.
> 
> 2) The other alternative is to abandon your gcc64 and build a new 
> boostrap compiler with HP aCC or C (ANSI).  I haven't tried this
> in some time.

I did. It seems to be more work that I like to spend on it

> 3) I could provide you with a working bootstrap compiler. 
> Unfortunately, I can't make the file publicly available.
> 
> If you get a working compiler going, it would be great if you
> could post it on the net as you have done for some other builds.

That is my plan, but I'll have most likely no internet access
shortly for two weeks, so don't hold your breath ...

I will make it available when it is done, but I'll still advice against
using it when it doesn't pass the perl blead tests (where 3.4.6 passes)

> Option 2 isn't that easy.

I'm not even considering that option yet.

> Dave

[Bug fortran/49624] ICE with pointer-bound remapping

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49624

--- Comment #1 from Tobias Burnus  2011-07-15 
15:31:05 UTC ---
(In reply to comment #0)
>   p(10,1:) => A

The problem is that "10" is parsed as DIMEN_ELEMENT such that ar.start is set
and ar.end is not. Thus, for the resolver, it is regarded as (10:,1:).


Patch:

--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3286,7 +3286,7 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue)
 upper bounds are present, we may do rank remapping.  */
  for (dim = 0; dim < ref->u.ar.dimen; ++dim)
{
- if (!ref->u.ar.start[dim])
+ if (!ref->u.ar.start[dim]
  || ref->u.ar.dimen_type[dim] != DIMEN_RANGE)
{
  gfc_error ("Lower bound has to be present at %L",
 &lvalue->where);

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #8 from H.Merijn Brand  2011-07-15 
15:50:12 UTC ---
On Thu, 14 Jul 2011 20:34:46 +, "sje at cup dot hp.com"
 wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
> 
> Steve Ellcey  changed:
> 
>What|Removed |Added
> 
>  CC||dave.anglin at bell dot
>||net, sje at cup dot hp.com
> 
> --- Comment #2 from Steve Ellcey  2011-07-14 20:34:28 
> UTC ---
> Are you trying to use a 32 bit GCC to bootstrap a 64 bit GCC?  I see you have
> CC set to gcc64 which makes me think that you are using a 64 bit GCC to do the
> bootstrap but you have -mpa-risc-2-0 in CFLAGS, which I think means the 32 bit
> 2.0 instruction set and I don't think it should be used for 64 bit builds.
> 
> Can you bootstrap if you leave off the -mpa-risc-2-0 flag?

Using the 4.2.4 I had available, I got gcc-4.6.1 installed.

Still doesn't pass perl build:

  CCCMD =  gcc64 -DPERL_CORE -c -mpa-risc-2-0 -DDEBUGGING
-D_HPUX_SOURCE -fno-strict-aliasing -pipe -I/usr/local/pa20_64/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -g -O  -Wall -W -Wextra
-Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings
{standard input}: Assembler messages:
{standard input}:35254: Error: Invalid operands
make: *** [pp.o] Error 1

Would it help to re-build binutils with gcc-4.6.1?

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[sje at cup dot hp.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #9 from Steve Ellcey  2011-07-15 16:03:16 
UTC ---
(In reply to comment #8)

> Using the 4.2.4 I had available, I got gcc-4.6.1 installed.
> 
> Still doesn't pass perl build:
> 
>   CCCMD =  gcc64 -DPERL_CORE -c -mpa-risc-2-0 -DDEBUGGING
> -D_HPUX_SOURCE -fno-strict-aliasing -pipe -I/usr/local/pa20_64/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -g -O  -Wall -W -Wextra
> -Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings
> {standard input}: Assembler messages:
> {standard input}:35254: Error: Invalid operands
> make: *** [pp.o] Error 1
> 
> Would it help to re-build binutils with gcc-4.6.1?

I don't know if rebuilding binutils would help or not.  Can you rerun
the above compile with -save-temps or something so we can see what is on line
35254 of the assembly file?  A preprocessed source file might be helpful too to
see if David or I can reproduce the problem.

Steve Ellcey

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #11 from H.Merijn Brand  2011-07-15 
16:09:42 UTC ---
On Fri, 15 Jul 2011 14:41:23 +, "dave.anglin at bell dot net"
 wrote:

> If you get a working compiler going, it would be great if you could post 
> it on the net as you have done for some other builds.

Not a "depot" (yet) for 2 reasons

1. No 32bit build available yet to include
2. It doesn't pass the perl build test

(Temporary) available here:
http://ftp.procura.nl/gcc-4.6.1-pa20_64-11.11.tbz

includes binutils-2.21.1 built with gcc-3.4.6/64

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #10 from dave.anglin at bell dot net 2011-07-15 16:09:28 UTC ---
On 7/15/2011 11:18 AM, h.m.brand at xs4all dot nl wrote:
> I will make it available when it is done, but I'll still advice against
> using it when it doesn't pass the perl blead tests (where 3.4.6 passes)
>

One issue may be thread support.  I always configure with 
--enable-threads=posix.

There was an issue with thread detection in gthr-posix.h that caused 
problems for
perl.  It was fixed a few months ago.  This fixed perl for me with the 
32-bit compiler.

Dave

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #13 from dave.anglin at bell dot net 2011-07-15 16:18:11 UTC ---
On 7/15/2011 11:51 AM, h.m.brand at xs4all dot nl wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
>
> --- Comment #8 from H.Merijn Brand  2011-07-15 
> 15:50:12 UTC ---
> On Thu, 14 Jul 2011 20:34:46 +, "sje at cup dot hp.com"
>   wrote:
>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
>>
>> Steve Ellcey  changed:
>>
>> What|Removed |Added
>> 
>>   CC||dave.anglin at bell dot
>> ||net, sje at cup dot hp.com
>>
>> --- Comment #2 from Steve Ellcey  2011-07-14 20:34:28 
>> UTC ---
>> Are you trying to use a 32 bit GCC to bootstrap a 64 bit GCC?  I see you have
>> CC set to gcc64 which makes me think that you are using a 64 bit GCC to do 
>> the
>> bootstrap but you have -mpa-risc-2-0 in CFLAGS, which I think means the 32 
>> bit
>> 2.0 instruction set and I don't think it should be used for 64 bit builds.
>>
>> Can you bootstrap if you leave off the -mpa-risc-2-0 flag?
> Using the 4.2.4 I had available, I got gcc-4.6.1 installed.
>
> Still doesn't pass perl build:
>
>CCCMD =  gcc64 -DPERL_CORE -c -mpa-risc-2-0 -DDEBUGGING
> -D_HPUX_SOURCE -fno-strict-aliasing -pipe -I/usr/local/pa20_64/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -g -O  -Wall -W -Wextra
> -Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings
> {standard input}: Assembler messages:
> {standard input}:35254: Error: Invalid operands
> make: *** [pp.o] Error 1
>
This is a separate issue.  It should have its own PR with preprocessed 
source, etc.

> Would it help to re-build binutils with gcc-4.6.1?
>
There is always a possibility it has been miscompiled.  It might also 
help to run
the GCC testsuite to gain confidence that your new build is working ok.  
It would
also be useful to see that the bootstrap issue is resolved.

Dave

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #12 from H.Merijn Brand  2011-07-15 
16:17:40 UTC ---
On Fri, 15 Jul 2011 16:10:35 +, "dave.anglin at bell dot net"
 wrote:

> One issue may be thread support.  I always configure with 
> --enable-threads=posix.

I don't run with threads enabled. I don't like threaded builds. So if
64bit non-threaded passes, I'm happy. I can (very easily) live without
threads.

> There was an issue with thread detection in gthr-posix.h that caused 
> problems for perl.  It was fixed a few months ago.

Then I should have no problems, because I'm running the build on blead,
not on released perl.

> This fixed perl for me with the 32-bit compiler.
> 
> Dave

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #14 from H.Merijn Brand  2011-07-15 
16:26:49 UTC ---
On Fri, 15 Jul 2011 16:04:04 +, "sje at cup dot hp.com"
 wrote:

> > Would it help to re-build binutils with gcc-4.6.1?  
> 
> I don't know if rebuilding binutils would help or not.  Can you rerun
> the above compile with -save-temps or something so we can see what is on line
> 35254 of the assembly file?  A preprocessed source file might be helpful too 
> to
> see if David or I can reproduce the problem.

http://www.xs4all.nl/~prosup/pp.s

> Steve Ellcey

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #15 from H.Merijn Brand  2011-07-15 
16:29:50 UTC ---
On Fri, 15 Jul 2011 16:18:57 +, "dave.anglin at bell dot net"
 wrote:

> > Would it help to re-build binutils with gcc-4.6.1?
>
> There is always a possibility it has been miscompiled.  It might also 
> help to run the GCC testsuite to gain confidence that your new build
> is working ok.  It would also be useful to see that the bootstrap
> issue is resolved.

I cannot run the testsuite:

$ make check
make[1]: Entering directory `/pro/3gl/GNU/gcc/obj-64'
make[2]: Entering directory `/pro/3gl/GNU/gcc/obj-64/fixincludes'
autogen -T ../../src/fixincludes/check.tpl ../../src/fixincludes/inclhack.def
make[2]: autogen: Command not found
make[2]: *** [check] Error 127
make[2]: Leaving directory `/pro/3gl/GNU/gcc/obj-64/fixincludes'
make[1]: *** [check-fixincludes] Error 2
make[1]: Leaving directory `/pro/3gl/GNU/gcc/obj-64'
make: *** [do-check] Error 2

At this point I neither have time nor tuits to build autogen
(I will be without internet for two weeks at any moment from now.
 I work on while I still can)

[Bug testsuite/49753] [4.6/4.7 Regression] FAIL: g++.dg/torture/pr49309.C

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49753

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.15 16:45:57
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2011-07-15 
16:45:57 UTC ---
Created attachment 24774
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24774
gcc47-pr49753.patch

Patch I'm going to regtest.

[Bug debug/48220] DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs register window

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48220

--- Comment #10 from Eric Botcazou  2011-07-15 
17:10:00 UTC ---
Author: ebotcazou
Date: Fri Jul 15 17:09:56 2011
New Revision: 176318

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176318
Log:
PR target/48220
* doc/md.texi (Standard Names): Document window_save.
* cfgexpand.c (expand_debug_parm_decl): New function extracted from
expand_debug_expr and expand_debug_source_expr.  If the target has
a window_save instruction, adjust the ENTRY_VALUE_EXP.
(expand_debug_expr) : Call expand_debug_parm_decl if the
SSA_NAME_VAR is a parameter.
(expand_debug_source_expr) : Call expand_debug_parm_decl.
* var-tracking.c (parm_reg_t): New type and associated vector type.
(windowed_parm_regs): New variable.
(adjust_insn): If the target has a window_save instruction and this
is the instruction, make its effect on parameter registers explicit.
(next_non_note_insn_var_location): New function.
(emit_notes_in_bb): Use it instead of NEXT_INSN throughout.
(vt_add_function_parameter): If the target has a window_save insn,
adjust the incoming RTL and record that in windowed_parm_regs.
(vt_finalize): Free windowed_parm_regs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/doc/md.texi
trunk/gcc/var-tracking.c

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #16 from dave.anglin at bell dot net 2011-07-15 17:15:17 UTC ---
On 7/15/2011 12:27 PM, h.m.brand at xs4all dot nl wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
>
> --- Comment #14 from H.Merijn Brand  2011-07-15 
> 16:26:49 UTC ---
> On Fri, 15 Jul 2011 16:04:04 +, "sje at cup dot hp.com"
>   wrote:
>
>>> Would it help to re-build binutils with gcc-4.6.1?
>> I don't know if rebuilding binutils would help or not.  Can you rerun
>> the above compile with -save-temps or something so we can see what is on line
>> 35254 of the assembly file?  A preprocessed source file might be helpful too 
>> to
>> see if David or I can reproduce the problem.
> http://www.xs4all.nl/~prosup/pp.s
Would you please preprocessed source?  It looks like a code generation bug.

Thanks,
Dave

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #17 from H.Merijn Brand  2011-07-15 
17:36:59 UTC ---
On Fri, 15 Jul 2011 17:16:14 +, "dave.anglin at bell dot net"
 wrote:

> > http://www.xs4all.nl/~prosup/pp.s  
> Would you please preprocessed source?  It looks like a code generation bug.

$ make pp.o
`sh  cflags "optimize='-g -O'" pp.o`  pp.c
  CCCMD =  gcc64 -DPERL_CORE -c -mpa-risc-2-0 -DDEBUGGING
-D_HPUX_SOURCE -fno-strict-aliasing -pipe -I/usr/local/pa20_64/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -save-temps -P  -g -O  -Wall -W
-Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat
-Wwrite-strings
gcc64: warning: -pipe ignored because -save-temps specified
pp.i:1570:0: warning: ignoring #pragma NO_SIDE_EFFECTS fabs [-Wunknown-pragmas]
pp.i:1594:0: warning: ignoring #pragma NO_SIDE_EFFECTS isnan
[-Wunknown-pragmas]
pp.i:1621:0: warning: ignoring #pragma NO_SIDE_EFFECTS copysign
[-Wunknown-pragmas]
pp.i:1622:0: warning: ignoring #pragma NO_SIDE_EFFECTS _Fpclassify
[-Wunknown-pragmas]
pp.i:1623:0: warning: ignoring #pragma NO_SIDE_EFFECTS _Isunordered
[-Wunknown-pragmas]
pp.i:1624:0: warning: ignoring #pragma NO_SIDE_EFFECTS _Signbit
[-Wunknown-pragmas]
pp.i:1625:0: warning: ignoring #pragma NO_SIDE_EFFECTS _Isfinite
[-Wunknown-pragmas]
pp.s: Assembler messages:
pp.s:35254: Error: Invalid operands
make: *** [pp.o] Error 1

 http://www.xs4all.nl/~prosup/pp.i

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #18 from dave.anglin at bell dot net 2011-07-15 17:42:45 UTC ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
>
> --- Comment #17 from H.Merijn Brand  2011-07-15 
> 17:36:59 UTC ---
> On Fri, 15 Jul 2011 17:16:14 +, "dave.anglin at bell dot net"
>   wrote:
>
>>> http://www.xs4all.nl/~prosup/pp.s
>> Would you please preprocessed source?  It looks like a code generation bug.
> $ make pp.o
> `sh  cflags "optimize='-g -O'" pp.o`  pp.c
>CCCMD =  gcc64 -DPERL_CORE -c -mpa-risc-2-0 -DDEBUGGING
> -D_HPUX_SOURCE -fno-strict-aliasing -pipe -I/usr/local/pa20_64/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -save-temps -P  -g -O  -Wall -W
> -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat
> -Wwrite-strings
> gcc64: warning: -pipe ignored because -save-temps specified
> pp.i:1570:0: warning: ignoring #pragma NO_SIDE_EFFECTS fabs 
> [-Wunknown-pragmas]
> pp.i:1594:0: warning: ignoring #pragma NO_SIDE_EFFECTS isnan
> [-Wunknown-pragmas]
> pp.i:1621:0: warning: ignoring #pragma NO_SIDE_EFFECTS copysign
> [-Wunknown-pragmas]
> pp.i:1622:0: warning: ignoring #pragma NO_SIDE_EFFECTS _Fpclassify
> [-Wunknown-pragmas]
> pp.i:1623:0: warning: ignoring #pragma NO_SIDE_EFFECTS _Isunordered
> [-Wunknown-pragmas]
> pp.i:1624:0: warning: ignoring #pragma NO_SIDE_EFFECTS _Signbit
> [-Wunknown-pragmas]
> pp.i:1625:0: warning: ignoring #pragma NO_SIDE_EFFECTS _Isfinite
> [-Wunknown-pragmas]
> pp.s: Assembler messages:
> pp.s:35254: Error: Invalid operands
> make: *** [pp.o] Error 1
>
>   http://www.xs4all.nl/~prosup/pp.i
>
Thanks, I see bug.

[Bug target/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723

--- Comment #7 from John David Anglin  2011-07-15 
18:11:23 UTC ---
Author: danglin
Date: Fri Jul 15 18:11:18 2011
New Revision: 176319

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176319
Log:
PR target/49723
* config/pa/pa.md (casesi): Use gen_int_mode instead of GEN_INT.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.md

[Bug target/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723

--- Comment #8 from John David Anglin  2011-07-15 
18:13:16 UTC ---
Author: danglin
Date: Fri Jul 15 18:13:13 2011
New Revision: 176320

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176320
Log:
PR target/49723
* config/pa/pa.md (casesi): Use gen_int_mode instead of GEN_INT.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/pa/pa.md

[Bug target/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723

--- Comment #9 from John David Anglin  2011-07-15 
18:15:19 UTC ---
Author: danglin
Date: Fri Jul 15 18:15:16 2011
New Revision: 176321

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176321
Log:
PR target/49723
* config/pa/pa.md (casesi): Use gen_int_mode instead of GEN_INT.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/pa/pa.md

[Bug c/35634] [4.4/4.5/4.6/4.7 Regression] operand of pre-/postin-/decrement not promoted

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||
  Known to fail||

--- Comment #30 from Andrew Pinski  2011-07-15 
18:55:41 UTC ---
Any news on this bug?

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #19 from dave.anglin at bell dot net 2011-07-15 19:15:06 UTC ---
I think the attached change will fix the bug.

Dave

[Bug tree-optimization/49309] [4.6 Regression] ICE with -fmudflap: verify_stmts failed: type mismatch in pointer plus expression

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49309

--- Comment #8 from Jakub Jelinek  2011-07-15 
19:48:50 UTC ---
Author: jakub
Date: Fri Jul 15 19:48:46 2011
New Revision: 176327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176327
Log:
PR testsuite/49753
PR tree-optimization/49309
* testsuite/libmudflap.c++/pass68-frag.cxx: New test.

* g++.dg/torture/pr49309.C: Remove.

Added:
trunk/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Removed:
trunk/gcc/testsuite/g++.dg/torture/pr49309.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libmudflap/ChangeLog

[Bug testsuite/49753] [4.6/4.7 Regression] FAIL: g++.dg/torture/pr49309.C

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49753

--- Comment #3 from Jakub Jelinek  2011-07-15 
19:48:51 UTC ---
Author: jakub
Date: Fri Jul 15 19:48:46 2011
New Revision: 176327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176327
Log:
PR testsuite/49753
PR tree-optimization/49309
* testsuite/libmudflap.c++/pass68-frag.cxx: New test.

* g++.dg/torture/pr49309.C: Remove.

Added:
trunk/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Removed:
trunk/gcc/testsuite/g++.dg/torture/pr49309.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libmudflap/ChangeLog

[Bug testsuite/49753] [4.6/4.7 Regression] FAIL: g++.dg/torture/pr49309.C

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49753

--- Comment #4 from Jakub Jelinek  2011-07-15 
19:54:01 UTC ---
Author: jakub
Date: Fri Jul 15 19:53:58 2011
New Revision: 176328

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176328
Log:
PR testsuite/49753
PR tree-optimization/49309
* testsuite/libmudflap.c++/pass68-frag.cxx: New test.

* g++.dg/torture/pr49309.C: Remove.

Added:
branches/gcc-4_6-branch/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Removed:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr49309.C
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/libmudflap/ChangeLog

[Bug tree-optimization/49309] [4.6 Regression] ICE with -fmudflap: verify_stmts failed: type mismatch in pointer plus expression

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49309

--- Comment #9 from Jakub Jelinek  2011-07-15 
19:54:01 UTC ---
Author: jakub
Date: Fri Jul 15 19:53:58 2011
New Revision: 176328

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176328
Log:
PR testsuite/49753
PR tree-optimization/49309
* testsuite/libmudflap.c++/pass68-frag.cxx: New test.

* g++.dg/torture/pr49309.C: Remove.

Added:
branches/gcc-4_6-branch/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Removed:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr49309.C
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/libmudflap/ChangeLog

[Bug tree-optimization/49749] Reassociation rank algorithm does not include all non-NULL operands

[wschmidt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749

--- Comment #6 from William J. Schmidt  2011-07-15 
20:15:09 UTC ---
We ran some experiments attempting to restore the r161839 behavior, either by
lowering the rank of memory references or raising the rank of phi references. 
Although both experiments restored bwaves code generation to respectability,
several other benchmarks suffered, so this is not a general answer.  Any
thoughts on more limited heuristics that might help the bwaves scenario?

It seems that copyrename needs help from reassoc to find the opportunity;
perhaps reassoc can be tweaked to recognize situations that will help
copyrename downstream?

[Bug tree-optimization/49749] Reassociation rank algorithm does not include all non-NULL operands

[wschmidt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749

--- Comment #7 from William J. Schmidt  2011-07-15 
20:19:21 UTC ---
Our experiments didn't distinguish between loop-carried PHIs and other join
points, so that might be another avenue of attack.

[Bug testsuite/49741] make -k check-c++0x not multilib aware

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49741

--- Comment #7 from Jason Merrill  2011-07-15 
21:30:00 UTC ---
Author: jason
Date: Fri Jul 15 21:29:57 2011
New Revision: 176332

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176332
Log:
PR testsuite/49741
gcc/
* Makefile.in ($(lang_checks_parallelized)): Allow --extra_opts
rather than --tool_opts.
gcc/cp/
* Make-lang.in (check-c++0x): Use --extra_opts instead of--tool_opts.
gcc/testsuite/
* lib/g++.exp (${tool}_option_help, ${tool}_option_proc): Restore.
Use --extra_opts instead of --additional_options.

* Makefile.in (check-c++): Move check-gcc-c++0x after
check-target-libstdc++-v3.

Modified:
trunk/ChangeLog
trunk/Makefile.in
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/Make-lang.in
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/g++.exp

[Bug testsuite/49753] [4.6/4.7 Regression] FAIL: g++.dg/torture/pr49309.C

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49753

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek  2011-07-15 
21:51:20 UTC ---
Fixed now.

[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745

--- Comment #19 from paolo at gcc dot gnu.org  
2011-07-15 21:52:14 UTC ---
Author: paolo
Date: Fri Jul 15 21:52:06 2011
New Revision: 176335

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176335
Log:
/gcc
2011-07-15  Paolo Carlini  
Jakub Jelinek  
Jonathan Wakely  

PR libstdc++/49745
* gthr-posix.h: Do not include  unconditionally; use
_GTHREADS_USE_MUTEX_TIMEDLOCK instead of _POSIX_TIMEOUTS.

/libstdc++-v3
2011-07-15  Paolo Carlini  
Jakub Jelinek  

PR libstdc++/49745
* acinclude.m4 ([GLIBCXX_CHECK_GTHREADS]): Check separately for
_POSIX_TIMEOUTS and define _GTHREADS_USE_MUTEX_TIMEDLOCK.
* libstdc++-v3/libsupc++/guard.cc: Include .
* testsuite/17_intro/headers/c++1998/49745.cc: New.
* configure: Regenerate.
* config.h.in: Likewise.

Added:
trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gthr-posix.h
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/libsupc++/guard.cc

[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.7.0
 Resolution||FIXED

--- Comment #20 from Paolo Carlini  2011-07-15 
21:55:38 UTC ---
Fixed for 4.7.0.

[Bug target/49743] -g enables var_tracking on -O0 - causes long compilations

[nenadv at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49743

--- Comment #2 from nenadv at gcc dot gnu.org 2011-07-16 01:06:53 UTC ---
Author: nenadv
Date: Sat Jul 16 01:06:51 2011
New Revision: 176348

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176348
Log:
2011-07-15  Nenad Vukicevic 

* config/darwin.c: Disable var_tracking option
  on -O0 as it is supposed to run only when optimization
  is applied. See GCC bug 49743. 'upcfish' test was
  taking to long to compile.

Modified:
branches/gupc/gcc/ChangeLog.upc
branches/gupc/gcc/config/darwin.c

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #20 from H.Merijn Brand  2011-07-16 
03:59:31 UTC ---
On Fri, 15 Jul 2011 19:15:28 +, "dave.anglin at bell dot net"
 wrote:

> I think the attached change will fix the bug.

Apparently it did! Dave++

I guess this will be in 4.6.2

For 64bit perl:

Test Summary Report
---
re/reg_eval.t   (Wstat: 0
Tests: 7 Failed: 3)
  Failed tests:  4-6
../cpan/CGI/t/tmpdir.t  (Wstat: 0
Tests: 9 Failed: 0)
  TODO passed:   3-9
../dist/IO/t/io_multihomed.t(Wstat: 7424
Tests: 1 Failed: 0)
  Non-zero exit status: 29
  Parse errors: Bad plan.  You planned 8 tests but ran 1.
../dist/IO/t/io_sock.t  (Wstat: 7424
Tests: 1 Failed: 0)
  Non-zero exit status: 29
  Parse errors: Bad plan.  You planned 26 tests but ran 1.
../dist/IO/t/io_udp.t   (Wstat: 9
Tests: 0 Failed: 0)
  Non-zero wait status: 9
  Parse errors: Bad plan.  You planned 7 tests but ran 0.
../dist/Net-Ping/t/450_service.t(Wstat: 7424
Tests: 3 Failed: 0)
  Non-zero exit status: 29
  Parse errors: Bad plan.  You planned 26 tests but ran 3.
../dist/Net-Ping/t/510_ping_udp.t   (Wstat: 65280
Tests: 1 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 2 tests but ran 1.
../ext/Socket/t/Socket.t(Wstat: 7424
Tests: 2 Failed: 0)
  Non-zero exit status: 29
  Parse errors: Bad plan.  You planned 26 tests but ran 2.
Files=2144, Tests=465226, 1241 wallclock secs (272.44 usr 30.32 sys + 1799.09
cusr 204.72 csys = 2306.57 CPU)
Result: FAIL

So gcc-4 still fails the socket stuff

[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

[h.m.brand at xs4all dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #21 from H.Merijn Brand  2011-07-16 
04:05:53 UTC ---
On Sat, 16 Jul 2011 04:00:16 +, "h.m.brand at xs4all dot nl"
 wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
> 
> --- Comment #20 from H.Merijn Brand  2011-07-16 
> 03:59:31 UTC ---
> On Fri, 15 Jul 2011 19:15:28 +, "dave.anglin at bell dot net"
>  wrote:
> 
> > I think the attached change will fix the bug.
> 
> Apparently it did! Dave++

You can re-fetch the (patched) compiler at

http://ftp.procura.nl/gcc-4.6.1-pa20_64-11.11.tbz

[Bug target/49758] New: -O2 incorrectly swaps overlapping memory accesses

[arthur.j.odwyer at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49758

   Summary: -O2 incorrectly swaps overlapping memory accesses
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com


Created attachment 24776
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24776
Output of "ajo-gcc -w -O1 test.c -v"

This failure reproduces for me with svn revision 176128 (2011-07-10). I'm on
Ubuntu 10.10, x86-64. It looks like bug 36043 may be related.

cat >test.c 

[Bug target/49758] -O2 incorrectly swaps overlapping memory accesses

[arthur.j.odwyer at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49758

--- Comment #1 from Arthur O'Dwyer  
2011-07-16 06:46:24 UTC ---
Created attachment 24777
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24777
Output of "ajo-gcc -w -O2 test.c -v"