[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

2010-08-02 Thread paolo dot carlini at oracle dot com


--- Comment #35 from paolo dot carlini at oracle dot com  2010-08-02 06:53 
---
Thanks a lot Armand (by the way, many thanks to Ralf too)


-- 


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



[Bug fortran/45161] ICE on gfortran.dg/typebound_proc_16.f03 with -std=f2003

2010-08-02 Thread janus at gcc dot gnu dot org


--- Comment #1 from janus at gcc dot gnu dot org  2010-08-02 06:56 ---
Probably related to PR 44584.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu dot org


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



[Bug tree-optimization/45144] SRA optimization issue of bit-field

2010-08-02 Thread ramana at gcc dot gnu dot org


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2010-08-02 07:54:22
   date||


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



[Bug middle-end/45098] Missed induction variable optimization

2010-08-02 Thread ramana at gcc dot gnu dot org


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2010-08-02 07:55:00
   date||


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



[Bug bootstrap/45162] New: [4.6 regression] ARM bootstrap comparison failures after stage 3

2010-08-02 Thread mikpe at it dot uu dot se
Attempting to bootstrap gcc-4.6-20100731 (r162788) on armv5tel-linux-gnueabi
fails due to bootstrap comparison failures after stage 3:

make[3]: Leaving directory `/home/mikpe/objdir46'
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/lto-cgraph.o differs
gcc/value-prof.o differs
gcc/tree-vect-data-refs.o differs
gcc/expr.o differs
gcc/tree-ssa-loop-ivopts.o differs
gcc/lto-streamer-out.o differs
gcc/stor-layout.o differs
gcc/tree-ssa-loop-ivcanon.o differs
gcc/loop-iv.o differs
gcc/double-int.o differs
gcc/expmed.o differs
gcc/dbxout.o differs
gcc/tree.o differs
gcc/sreal.o differs
gcc/cfgloopanal.o differs
gcc/explow.o differs
libcpp/expr.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/mikpe/objdir46'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/mikpe/objdir46'
make: *** [bootstrap] Error 2

Target: armv5tel-brewer-linux-gnueabi
Configured with: /home/mikpe/gcc-4.6-20100731/configure --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --disable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--disable-sjlj-exceptions --with-arch=armv5te --with-tune=xscale
--build=armv5tel-brewer-linux-gnueabi
--with-gmp=/home/mikpe/pkgs/linux-armv5l/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-armv5l/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-armv5l/mpc-0.8.2 --disable-plugin
--disable-lto --disable-libmudflap


-- 
   Summary: [4.6 regression] ARM bootstrap comparison failures after
stage 3
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
 GCC build triplet: armv5tel-unknown-linux-gnueabi
  GCC host triplet: armv5tel-unknown-linux-gnueabi
GCC target triplet: armv5tel-unknown-linux-gnueabi


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



[Bug driver/45163] New: -save-temps=obj does not work correctly

2010-08-02 Thread jiez at gcc dot gnu dot org
Assume there is a directory foo in the current directory and there is a foo.c
in ./foo , I saw this on 4.5.1

$ gcc-4.5 -fdump-tree-optimized -save-temps=obj foo/foo.c -S -o foo/foo.s
foo/foo.c: In function ‘foo’:
foo/foo.c:1:6: error: could not open dump file ‘foo/foo/foo.140t.optimized’: No
such file or directory


-- 
   Summary: -save-temps=obj does not work correctly
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jiez at gcc dot gnu dot org


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



[Bug driver/45163] -save-temps=obj does not work correctly with -fdum-tree- options

2010-08-02 Thread jiez at gcc dot gnu dot org


--- Comment #1 from jiez at gcc dot gnu dot org  2010-08-02 08:43 ---
Make the summary more specific.


-- 

jiez at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|-save-temps=obj does not|-save-temps=obj does not
   |work correctly  |work correctly with -fdum-
   ||tree- options


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



[Bug target/40457] use stm and ldm to access consecutive memory words

2010-08-02 Thread bernds at gcc dot gnu dot org


--- Comment #12 from bernds at gcc dot gnu dot org  2010-08-02 10:07 ---
Subject: Bug 40457

Author: bernds
Date: Mon Aug  2 10:06:47 2010
New Revision: 162815

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162815
Log:
PR target/40457
* config/arm/arm.h (arm_regs_in_sequence): Declare.
* config/arm/arm-protos.h (emit_ldm_seq, emit_stm_seq,
load_multiple_sequence, store_multiple_sequence): Delete
declarations.
(arm_gen_load_multiple, arm_gen_store_multiple): Adjust
declarations.
* config/arm/ldmstm.md: New file.
* config/arm/arm.c (arm_regs_in_sequence): New array.
(load_multiple_sequence): Now static.  New args SAVED_ORDER,
CHECK_REGS.  All callers changed.
If SAVED_ORDER is nonnull, copy the computed order into it.
If CHECK_REGS is false, don't sort REGS.  Handle Thumb mode.
(store_multiple_sequence): Now static.  New args NOPS_TOTAL,
SAVED_ORDER, REG_RTXS and CHECK_REGS.  All callers changed.
If SAVED_ORDER is nonnull, copy the computed order into it.
If CHECK_REGS is false, don't sort REGS.  Set up REG_RTXS just
like REGS.  Handle Thumb mode.
(arm_gen_load_multiple_1): New function, broken out of
arm_gen_load_multiple.
(arm_gen_store_multiple_1): New function, broken out of
arm_gen_store_multiple.
(arm_gen_multiple_op): New function, with code from
arm_gen_load_multiple and arm_gen_store_multiple moved here.
(arm_gen_load_multiple, arm_gen_store_multiple): Now just
wrappers around arm_gen_multiple_op.  Remove argument UP, all callers
changed.
(gen_ldm_seq, gen_stm_seq, gen_const_stm_seq): New functions.
* config/arm/predicates.md (commutative_binary_operator): New.
(load_multiple_operation, store_multiple_operation): Handle more
variants of these patterns with different starting offsets.  Handle
Thumb-1.
* config/arm/arm.md: Include ldmstm.md.
(ldmsi_postinc4, ldmsi_postinc4_thumb1, ldmsi_postinc3, ldmsi_postinc2,
ldmsi4, ldmsi3, ldmsi2, stmsi_postinc4, stmsi_postinc4_thumb1,
stmsi_postinc3, stmsi_postinc2, stmsi4, stmsi3, stmsi2 and related
peepholes): Delete.
* config/arm/ldmstm.md: New file.
* config/arm/arm-ldmstm.ml: New file.

testsuite/
PR target/40457
* gcc.target/arm/pr40457-1.c: New test.
* gcc.target/arm/pr40457-2.c: New test.


Added:
trunk/gcc/config/arm/arm-ldmstm.ml
trunk/gcc/config/arm/ldmstm.md
trunk/gcc/testsuite/gcc.target/arm/pr40457-1.c
trunk/gcc/testsuite/gcc.target/arm/pr40457-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h
trunk/gcc/config/arm/arm.md
trunk/gcc/config/arm/predicates.md
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug bootstrap/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

2010-08-02 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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



[Bug fortran/45159] Unneccessary temporaries

2010-08-02 Thread dominiq at lps dot ens dot fr


--- Comment #5 from dominiq at lps dot ens dot fr  2010-08-02 11:41 ---
 As pointed out by Dominique, one needs to be careful. I think one can 
 optimize:

   c = matmul(b, transpose(c))
   c = matmul(c,b)
 where c is a rank-2 matrix. I think one cannot optimize it if c is just a
 vector. (Add conj as you wish.) And check whether I have not confused 
 columns
 and rows

So far I have never seen a product matrix*matrix done in place and I
seriously doubt it can be done.
The best I can see is to have a temporary of rank 1 only instead of the full
matrix. In addition roughly speaking the matrix product is O(n**3) while the
cost of the temporary is O(n**2), probably negligible for large matrices (for
small matrices calling the present matmul is much slower than any other
possible algorithm).

Note also that the polyhedron test nf.f90 is compiled with unnecessary
temporaries:

[macbook] lin/test% gfc -Warray-temporaries nf.f90
nf.f90:293.30:

   if ( ii1 ) x(i:i+nxy-1) = x(i:i+nxy-1) - au3(i-nxy:i-1)*x(i-nxy:i-1)
  1
Warning: Creating array temporary at (1)
nf.f90:280.21:

  g(i:i+nxy-1) = g(i:i+nxy-1) - au3(i-nxy:i-1)*g(i-nxy:i-1)
 1
Warning: Creating array temporary at (1)
nf.f90:261.29:

   if ( ii1 ) x(i:i+nx-1) = x(i:i+nx-1) - au2(i-nx:i-1)*x(i-nx:i-1)
 1
Warning: Creating array temporary at (1)
nf.f90:248.20:

  g(i:i+nx-1) = g(i:i+nx-1) - au2(i-nx:i-1)*g(i-nx:i-1)
1
Warning: Creating array temporary at (1)

i.e., disjoint sections are not spotted.


-- 


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



[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

2010-08-02 Thread ian dot bolton at arm dot com


--- Comment #24 from ian dot bolton at arm dot com  2010-08-02 12:23 ---
(In reply to comment #23)
 I can confirm this fails with GCC 4.4.4 and that GCC 4.3.2 works.
 

I get no warning and correct code in latest 4.4 branch (4.4.5 - 20100727), but
I do get the warning and incorrect code in latest 4.5 branch (4.5.1 -
20100727).


-- 

ian dot bolton at arm dot com changed:

   What|Removed |Added

 CC||ian dot bolton at arm dot
   ||com


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



[Bug fortran/45159] Unneccessary temporaries

2010-08-02 Thread burnus at gcc dot gnu dot org


--- Comment #6 from burnus at gcc dot gnu dot org  2010-08-02 12:41 ---
(In reply to comment #5)
  As pointed out by Dominique, one needs to be careful. I think one can 
  optimize:
c = matmul(b, transpose(c))
c = matmul(c,b)
  where c is a rank-2 matrix. I think one cannot optimize it if c is just a
  vector. (Add conj as you wish.) And check whether I have not confused 
  columns
  and rows
 
 So far I have never seen a product matrix*matrix done in place and I
 seriously doubt it can be done.
 The best I can see is to have a temporary of rank 1

I fail to see why a scalar temporary is not enough:

do j = 1, N
  do i = 1, N
tmp = 0.0
do k = 1, N
  tmp = a(i,k)*b(k,j)
end do
a(i,j) = tmp
  end do
end do

Note: it won't work with a scalar if one reverses the i and the j loop.
[It would work with a rank-1 B argument, but then A = matmul(B,A) won't
work as the result is a rank-1 array ...]

 Note also that the polyhedron test nf.f90 is compiled with unnecessary
 temporaries:

My feeling is that ONE, THREE (of comment 0), FIVE (of comment 1), and your
example (comment 5) point all to the same dependency-analysis problem.


-- 


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



[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)

2010-08-02 Thread t dot artem at mailcity dot com


--- Comment #3 from t dot artem at mailcity dot com  2010-08-02 13:09 
---
I've just tested GCC 4.5.1 and it also miscompiles the source code.


-- 

t dot artem at mailcity dot com changed:

   What|Removed |Added

Summary|[GCC 4.4.x regression]  |[4.4.x/4.5.x regression]
   |Invalid assembly code is|Invalid assembly code is
   |generated for x86   |generated for x86
   |architecture for faad2  |architecture for faad2
   |library (AAC decode |library (AAC decode
   |algorithm)  |algorithm)


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



[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)

2010-08-02 Thread t dot artem at mailcity dot com


--- Comment #4 from t dot artem at mailcity dot com  2010-08-02 13:10 
---
Created an attachment (id=21369)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21369action=view)
faad2 2.7.0 complete sources with -save-temps for GCC 4.5.1


-- 


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



[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)

2010-08-02 Thread t dot artem at mailcity dot com


--- Comment #5 from t dot artem at mailcity dot com  2010-08-02 13:15 
---
I've found the culprit (or better say mplayer developer hinted), it is
-fstrict-aliasing optimization.

With -fno-strict-aliasing GCC 4.4.x and 4.5.x produce proper code.

Please, advise.


-- 


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



[Bug fortran/45131] [4.6 regression] New Fortran test failures

2010-08-02 Thread jvdelisle at gcc dot gnu dot org


--- Comment #14 from jvdelisle at gcc dot gnu dot org  2010-08-02 13:19 
---
Closing as fixed.  Regarding comment #7.  I do not see the problem on 4.5.  I
reran tests here on my machine that failed with 4.6 and there were no failures
on 4.5


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug tree-optimization/44914] [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:395 with -fipa-sra -fnon-call-exceptions

2010-08-02 Thread jamborm at gcc dot gnu dot org


--- Comment #7 from jamborm at gcc dot gnu dot org  2010-08-02 13:28 ---
(In reply to comment #6)
 Is there a patch for 4.5.1 for this somewhere? I'm hitting this issue at gcc
 4.5.1 java boostrap (#45154)
 

The patch is really the same.  I did not commit it because the branch
was frozen for the release of 4.5.1.  I'm re-testing it on the branch
now and hopefully will commit it today.


-- 


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



[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

2010-08-02 Thread ian dot bolton at arm dot com


--- Comment #25 from ian dot bolton at arm dot com  2010-08-02 13:33 ---
(In reply to comment #24)
 (In reply to comment #23)
  I can confirm this fails with GCC 4.4.4 and that GCC 4.3.2 works.
  
 
 I get no warning and correct code in latest 4.4 branch (4.4.5 - 20100727), but
 I do get the warning and incorrect code in latest 4.5 branch (4.5.1 -
 20100727).
 

And trunk, as of 20100727 (4.6.0), is also OK (no warning and correct code).

I am configuring with:

--target=arm-unknown-eabi --with-cpu=cortex-a9 --enable-languages=c,c++

And building with:

-c -O2 -mcpu=arm926ej-s -x c++ ~/pr44328.cpp -Wextra -save-temps -S


-- 


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



[Bug fortran/45159] Unneccessary temporaries

2010-08-02 Thread dominiq at lps dot ens dot fr


--- Comment #7 from dominiq at lps dot ens dot fr  2010-08-02 13:39 ---
 I fail to see why a scalar temporary is not enough:

 do j = 1, N
   do i = 1, N
 tmp = 0.0
 do k = 1, N
   tmp = a(i,k)*b(k,j)
 end do
 a(i,j) = tmp
   end do
 end do

 Note: it won't work with a scalar if one reverses the i and the j loop.

Well, try:


real :: a(3,3), b(3,3), c(3,3), tmp
integer :: i, j, k, N=3
a = reshape([(i,i=1,9)],[3,3])
b = reshape([(10-i,i=1,9)],[3,3])
c = matmul(a, b)
do j = 1, N
  do i = 1, N
tmp = 0.0
do k = 1, N
  tmp = tmp + a(i,k)*b(k,j)
end do
a(i,j) = tmp
  end do
end do
print *, a
print *, c
if(any(a/=c)) call abort()
print *, 'OK'
end

The problem is that in order to compute a(1,2) you need a(1,1)*b(1,2), so you
cannot have already written a(1,1). Note that the effective way to compute the
matrix product on modern CPUs is to exchange the i and k loops and use a rank 1
tmp:

real :: a(3,3), b(3,3), c(3,3), tmp(3)
integer :: i, j, k, N=3
a = reshape([(i,i=1,9)],[3,3])
b = reshape([(10-i,i=1,9)],[3,3])
c = matmul(a, b)
do j = 1, N
  tmp = 0.0
  do k = 1, N
do i = 1, N
  tmp(i) = tmp(i) + a(i,k)*b(k,j)
end do
  end do
  b(:,j) = tmp
end do
if(any(b/=c)) call abort()
print *, 'OK'
end

and this work with a rank 1 temporary.

If one want to enter this kind of reduced temporaries, another candidate is
a=transpose(a) which requires a scalar temporary only.


-- 


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



[Bug fortran/45159] Unnecessary temporaries

2010-08-02 Thread burnus at gcc dot gnu dot org


--- Comment #8 from burnus at gcc dot gnu dot org  2010-08-02 14:10 ---
(In reply to comment #7)
  I fail to see why a scalar temporary is not enough:
 Well, try:

I concede defeat.

 If one want to enter this kind of reduced temporaries, another candidate is
 a=transpose(a) which requires a scalar temporary only.

Well, with an array descriptor it one only changes the strides/bounds ...


-- 


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



[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)

2010-08-02 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2010-08-02 14:12 ---
Why CC me?  I have no clue about faad2, the strict-aliasing thing hints
at errors in faad2, not gcc.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|rguenth at gcc dot gnu dot  |
   |org |


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



[Bug fortran/45159] Unnecessary temporaries

2010-08-02 Thread dominiq at lps dot ens dot fr


--- Comment #9 from dominiq at lps dot ens dot fr  2010-08-02 14:36 ---
 Well, with an array descriptor it one only changes the strides/bounds ...

From polyhedron test induct.f90


[macbook] lin/test% gfc -Warray-temporaries induct.f90
induct.f90:1629.20:

  rotate_quad = transpose(rotate_quad)
1
Warning: Creating array temporary at (1)
induct.f90:1741.20:

  rotate_quad = transpose(rotate_quad)
1
Warning: Creating array temporary at (1)
induct.f90:2016.20:

  rotate_quad = transpose(rotate_quad)
1
Warning: Creating array temporary at (1)
induct.f90:2159.20:

  rotate_quad = transpose(rotate_quad)
1
Warning: Creating array temporary at (1)
induct.f90:2509.24:

  rotate1 = transpose(rotate1)
1
Warning: Creating array temporary at (1)
induct.f90:2560.24:

  rotate2 = transpose(rotate2)
1
Warning: Creating array temporary at (1)
induct.f90:2702.24:

  rotate2 = transpose(rotate2)
1
Warning: Creating array temporary at (1)
induct.f90:2845.24:

  rotate1 = transpose(rotate1)
1
Warning: Creating array temporary at (1)
induct.f90:2896.24:

  rotate2 = transpose(rotate2)
1
Warning: Creating array temporary at (1)
induct.f90:3038.24:

  rotate2 = transpose(rotate2)
1
Warning: Creating array temporary at (1)

The same trick can probably used for RESHAPE, from capacita.f90

...

Warning: Creating array temporary at (1)
capacita.f90:137.30:

  maxval(abs( reshape(Ar1,(/Ng1,Ng2/)) - Y ))
  1
Warning: Creating array temporary at (1)
capacita.f90:137.30:

  maxval(abs( reshape(Ar1,(/Ng1,Ng2/)) - Y ))
  1
Warning: Creating array temporary at (1)
capacita.f90:137.18:

  maxval(abs( reshape(Ar1,(/Ng1,Ng2/)) - Y ))
  1
Warning: Creating array temporary at (1)


-- 


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



[Bug bootstrap/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

2010-08-02 Thread ramana at gcc dot gnu dot org


--- Comment #1 from ramana at gcc dot gnu dot org  2010-08-02 14:55 ---
Confirmed. My bootstrap with thumb2 and armv7-a failed as well. Here's the
configuration line . I only see a comparison failure with tree-vect-data-refs.o
in this configuration.

Configured with: /home/ramrad01/sources//trunk/configure
--prefix=/home/ramrad01/install-nightlies/install-trunk-162814
--enable-languages=c,c++,fortran --enable-__cxa_atexit --disable-nls
--enable-threads=posix --disable-multilib --with-arch=armv7-a --with-mode=thumb
--with-float=softfp --with-fpu=vfpv3-d16


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-02 14:55:47
   date||


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



[Bug bootstrap/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

2010-08-02 Thread ramana at gcc dot gnu dot org


--- Comment #2 from ramana at gcc dot gnu dot org  2010-08-02 14:58 ---
Created an attachment (id=21370)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21370action=view)
Disassembly and object files that are different with the thumb2 bootstrap

Disassembly and object files in this case.


-- 


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



[Bug fortran/44064] [OOP] ICE with file containing two modules and one program

2010-08-02 Thread mikael at gcc dot gnu dot org


--- Comment #10 from mikael at gcc dot gnu dot org  2010-08-02 15:31 ---
Subject: Bug 44064

Author: mikael
Date: Mon Aug  2 15:30:47 2010
New Revision: 162821

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162821
Log:
2010-08-02  Mikael Morin  mik...@gcc.gnu.org
Janus Weil  ja...@gcc.gnu.org

PR fortran/42051
PR fortran/44064
PR fortran/45151
* intrinsic.c (gfc_get_intrinsic_sub_symbol): Commit changed symbol. 
* symbol.c (gen_cptr_param, gen_fptr_param, gen_shape_param,
gfc_copy_formal_args, gfc_copy_formal_args_intr,
gfc_copy_formal_args_ppc, generate_isocbinding_symbol): Ditto.
* parse.c (parse_derived_contains, parse_spec, parse_progunit): 
Call reject_statement in case of error. 
(match_deferred_characteritics): Call gfc_undo_symbols in case match
fails.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c


-- 


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



[Bug fortran/45151] [4.6 regression] New Fortran failuires

2010-08-02 Thread mikael at gcc dot gnu dot org


--- Comment #11 from mikael at gcc dot gnu dot org  2010-08-02 15:31 ---
Subject: Bug 45151

Author: mikael
Date: Mon Aug  2 15:30:47 2010
New Revision: 162821

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162821
Log:
2010-08-02  Mikael Morin  mik...@gcc.gnu.org
Janus Weil  ja...@gcc.gnu.org

PR fortran/42051
PR fortran/44064
PR fortran/45151
* intrinsic.c (gfc_get_intrinsic_sub_symbol): Commit changed symbol. 
* symbol.c (gen_cptr_param, gen_fptr_param, gen_shape_param,
gfc_copy_formal_args, gfc_copy_formal_args_intr,
gfc_copy_formal_args_ppc, generate_isocbinding_symbol): Ditto.
* parse.c (parse_derived_contains, parse_spec, parse_progunit): 
Call reject_statement in case of error. 
(match_deferred_characteritics): Call gfc_undo_symbols in case match
fails.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c


-- 


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



[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument

2010-08-02 Thread mikael at gcc dot gnu dot org


--- Comment #21 from mikael at gcc dot gnu dot org  2010-08-02 15:31 ---
Subject: Bug 42051

Author: mikael
Date: Mon Aug  2 15:30:47 2010
New Revision: 162821

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162821
Log:
2010-08-02  Mikael Morin  mik...@gcc.gnu.org
Janus Weil  ja...@gcc.gnu.org

PR fortran/42051
PR fortran/44064
PR fortran/45151
* intrinsic.c (gfc_get_intrinsic_sub_symbol): Commit changed symbol. 
* symbol.c (gen_cptr_param, gen_fptr_param, gen_shape_param,
gfc_copy_formal_args, gfc_copy_formal_args_intr,
gfc_copy_formal_args_ppc, generate_isocbinding_symbol): Ditto.
* parse.c (parse_derived_contains, parse_spec, parse_progunit): 
Call reject_statement in case of error. 
(match_deferred_characteritics): Call gfc_undo_symbols in case match
fails.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c


-- 


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



[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)

2010-08-02 Thread t dot artem at mailcity dot com


--- Comment #7 from t dot artem at mailcity dot com  2010-08-02 15:49 
---
(In reply to comment #6)
 Why CC me?  I have no clue about faad2, the strict-aliasing thing hints
 at errors in faad2, not gcc.
 

Richard, I don't know who is who amongst GCC developers, but you are a
prominent person, so I thought you know someone who can help shed light on this
issue.

Like I said GCC 4.2.x has no problems compiling this library, so I have no idea
who to blame and who else I should get in touch with.


-- 


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



[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)

2010-08-02 Thread pinskia at gcc dot gnu dot org


--- Comment #8 from pinskia at gcc dot gnu dot org  2010-08-02 16:21 ---
 Like I said GCC 4.2.x has no problems compiling this library, so I have no 
 idea
 who to blame and who else I should get in touch with.

I would get into contact with the developers of the library first.  Yes GCC has
some bugs but the library could have a bug still.  Since the problem disappreas
with -fno-strict-aliasing that normally points at a bug in the library.  In
that it does not follow the C/C++ alisaing rules.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug bootstrap/45118] No rule to make target `.deps/affinity.Plo'

2010-08-02 Thread rwild at gcc dot gnu dot org


--- Comment #1 from rwild at gcc dot gnu dot org  2010-08-02 16:40 ---
Is this a transient failure with parallel make, i.e., are you using parallel
make, and does the failure go away with a serial make or another parallel make
invocation?  Which -jN option do you pass?  Have you seen this failure happen
more than once, and if yes, how likely can you reproduce it?

Please also show how you configured your build, and please also post the exact
error lines spewed out by 'make' that you trimmed from the end.  They can give
valuable clues as to whether some serialization is missing in the toplevel
Makefile (should all-target-libgfortran depend on all-target-libgomp?)


-- 


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



[Bug c/45164] New: -O3 optimization problematic on long long types near 64 bit wraparound

2010-08-02 Thread robots at marcabel dot com
Here is a small test case, with output and version information in the comments.

There are enough ways of stating this problem that it was not evident to me
within the existing bug list.  One skilled in the art would know if this is a
duplicate.

I'm not sure where to upload my .i file, so I will try to attach it a few
minutes after I post this.

---

/*
 *  Illustration of GCC bug
 *  Marc W. Abel, August 2, 2010
 *
 *  gcc version information follows
 *  
 *  Using built-in specs.
 *  Target: x86_64-linux-gnu
 *  Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
 *  Thread model: posix
 *  gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) 
 *  
 *
 *  Invocation and correct output (using -O2):
 *
 *  $ gcc -O2 o3bug.c  ./a.out | head -n 6
 *  7ffd fd7f
 *  7ffe fe7f
 *  7fff ff7f
 *  8000 0080
 *  8001 0180
 *  8002 0280
 *
 *  Invocation and incorrect output (using -O3):
 *
 *  $ gcc -O3 o3bug.c  ./a.out | head -n 6
 *  7ffd fd7f
 *  7ffe fe7f
 *  7fff ff7f
 *  8000 1007f
 *  8001 1017f
 *  8002 1027f
 */

#include stdio.h

/*
 *  Convert an integer into an eight-byte format for persistance, LSB first.
 */
static void int_to_persist(unsigned char *eight_bytes, long long n)
{
int i;

for (i=0; i8; i++, n = 8)
eight_bytes[i] = n  255u;
}

int main(int argc, char *argv[])
{
unsigned char bytes[8];
int i;
long long m;

for (m = 0x7ffdLL; ; ++m) {
printf(%llx , m);

int_to_persist(bytes, m);
for (i=0; i8; i++)
printf(%02x, bytes[i]);
printf(\n);
}
}


-- 
   Summary: -O3 optimization problematic on long long types near
64 bit wraparound
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: robots at marcabel dot com


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



[Bug c/45164] -O3 optimization problematic on long long types near 64 bit wraparound

2010-08-02 Thread robots at marcabel dot com


--- Comment #1 from robots at marcabel dot com  2010-08-02 16:47 ---
Created an attachment (id=21371)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21371action=view)
Preprocessor output / compiler input


-- 


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



[Bug c/45164] -O3 optimization problematic on long long types near 64 bit wraparound

2010-08-02 Thread robots at marcabel dot com


--- Comment #2 from robots at marcabel dot com  2010-08-02 16:48 ---
Created an attachment (id=21372)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21372action=view)
Source code to produce

in case it doesn't paste well from my initial report.


-- 


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



[Bug c/45164] -O3 optimization problematic on long long types near 64 bit wraparound

2010-08-02 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2010-08-02 16:48 ---
Signed overflow is undefined; use either unsigned or -fwrapv to get the
behavior you want.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug fortran/36854] [meta] fortran front-end optimization

2010-08-02 Thread tkoenig at gcc dot gnu dot org


--- Comment #5 from tkoenig at gcc dot gnu dot org  2010-08-02 16:54 ---
Subject: Bug 36854

Author: tkoenig
Date: Mon Aug  2 16:53:51 2010
New Revision: 162824

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162824
Log:
2010-08-02  Thomas Koenig  tkoe...@gcc.gnu.org

PR fortran/36854
* dependency.h:  Add prototype for gfc_are_identical_variables.
* frontend-passes.c:  Include depencency.h.
(optimimize_equality):  Use gfc_are_identical_variables.
* dependency.c (identical_array_ref): New function.
(gfc_are_identical_variables):  New function.
(gfc_deb_compare_expr):  Use gfc_are_identical_variables.
* dependency.c (gfc_check_section_vs_section).  Rename gfc_
prefix from statc function.
(check_section_vs_section): Change arguments to gfc_array_ref,
adjust function body accordingly.

2010-08-02  Thomas Koenig  tkoe...@gcc.gnu.org

PR fortran/36854
* gfortran.dg/character_comparison_2.f90:  New test.
* gfortran.dg/character_comparison_3.f90:  New test.
* gfortran.dg/dependency_28.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/character_comparison_2.f90
trunk/gcc/testsuite/gfortran.dg/character_comparison_3.f90
trunk/gcc/testsuite/gfortran.dg/dependency_28.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/dependency.h
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c/45164] -O3 optimization problematic on long long types near 64 bit wraparound

2010-08-02 Thread robots at marcabel dot com


--- Comment #4 from robots at marcabel dot com  2010-08-02 16:54 ---
Confirmed resolved invalid.  Thank you!


-- 


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



[Bug libfortran/45165] New: unix.c:fallback_access() leaks file descriptors

2010-08-02 Thread jb at gcc dot gnu dot org
fd's are opened but never closed.


-- 
   Summary: unix.c:fallback_access() leaks file descriptors
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org


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



[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

2010-08-02 Thread ubizjak at gmail dot com


--- Comment #48 from ubizjak at gmail dot com  2010-08-02 17:12 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00021.html.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||08/msg00021.html


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



[Bug driver/45166] New: gcc -MD misses multiple command line source files

2010-08-02 Thread wsnyder at wsnyder dot org
When multiple .c (.cpp?) files are mentioned on the command line, GCC places
only a single one in the MD output:

$ echo int main() { return 0; }  a.c
$ echo int foo() { return 0; }  b.c
$ gcc -MD a.c b.c
$ cat a.d
a.o: a.c

b.c was lost, but should be listed.


-- 
   Summary: gcc -MD misses multiple command line source files
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wsnyder at wsnyder dot org


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



[Bug bootstrap/45118] No rule to make target `.deps/affinity.Plo'

2010-08-02 Thread dave at hiauly1 dot hia dot nrc dot ca


--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2010-08-02 
17:18 ---
Subject: Re:  No rule to make target
`.deps/affinity.Plo'

On Mon, 02 Aug 2010, rwild at gcc dot gnu dot org wrote:

 Please also show how you configured your build, and please also post the exact
 error lines spewed out by 'make' that you trimmed from the end.  They can give
 valuable clues as to whether some serialization is missing in the toplevel
 Makefile (should all-target-libgfortran depend on all-target-libgomp?)

../gcc/configure --build=i686-apple-darwin9 --host=i686-apple-darwin9
--target=i
686-apple-darwin9 --with-tune=generic --prefix=/opt/gnu/gcc/gcc-4.6.0
--with-gmp
=/opt/gnu/gcc/gcc-4.6.0 --enable-debug=no --disable-nls
--enable-languages=c,c+
+,objc,fortran,obj-c++,java,ada --enable-threads=posix --enable-__cxa_atexit
--
enable-java-gc=boehm

make -j 4 bootstrap 

Trying to repeat.

Dave


-- 


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



[Bug tree-optimization/41089] [4.5/4.6 Regression] stdarg pass produces wrong code

2010-08-02 Thread ubizjak at gmail dot com


--- Comment #49 from ubizjak at gmail dot com  2010-08-02 17:33 ---
Author: uros
Date: Mon Aug  2 17:26:40 2010
New Revision: 162826

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162826
Log:
target/41089
* config/alpha/alpha.c (alpha_build_builtin_va_list): Mark __offset
as volatile.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/alpha/alpha.c


-- 


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



[Bug tree-optimization/44914] [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:395 with -fipa-sra -fnon-call-exceptions

2010-08-02 Thread jamborm at gcc dot gnu dot org


--- Comment #8 from jamborm at gcc dot gnu dot org  2010-08-02 17:40 ---
(In reply to comment #7)
 
 The patch is really the same.  I did not commit it because the branch
 was frozen for the release of 4.5.1.  I'm re-testing it on the branch
 now and hopefully will commit it today.
 

Actually no, the patch must be slightly different because
scan_function() is not split into multiple functions in 4.5... but
along the same lines.  I'll prepare it, hopefully today.


-- 


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



[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables

2010-08-02 Thread pj dot pandit at yahoo dot co dot in


--- Comment #1 from pj dot pandit at yahoo dot co dot in  2010-08-02 18:38 
---
The following patch to gcc-4.4.4 seems to fix the issue for DW_AT_subprogram
DIEs.


$ diff -Naurp gcc-4.4.4/gcc/dwarf2out.c gcc-4.4.4.1/gcc/dwarf2out.c 


--- gcc-4.4.4/gcc/dwarf2out.c   2010-02-10 20:39:06.0 +0530
+++ gcc-4.4.4.1/gcc/dwarf2out.c 2010-08-02 15:16:17.495688080 +0530
@@ -13712,7 +13712,7 @@ gen_subprogram_die (tree decl, dw_die_re
 {
   subr_die = new_die (DW_TAG_subprogram, context_die, decl);

-  if (TREE_PUBLIC (decl))
+  if (TREE_PUBLIC (decl)  !DECL_EXTERNAL (decl))
add_AT_flag (subr_die, DW_AT_external, 1);

   add_name_and_src_coords_attributes (subr_die, decl);
@@ -14163,7 +14163,7 @@ gen_variable_die (tree decl, tree origin
add_type_attribute (var_die, type, TREE_READONLY (decl),
TREE_THIS_VOLATILE (decl), context_die);

-  if (TREE_PUBLIC (decl))
+  if (TREE_PUBLIC (decl)  !DECL_EXTERNAL (decl))
add_AT_flag (var_die, DW_AT_external, 1);

   if (DECL_ARTIFICIAL (decl))


-- 


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



[Bug c++/45167] New: lambda+template=Internal error: Segmentation fault (program cc1plus)

2010-08-02 Thread wb at fnal dot gov
build environment: gcc 4.5.0 on MacBook Pro running OS X 10.6.4
execution environment: same as build environment
command:  g++ --std=c++0x filename


auto at_or_above = [] ( int threshhold )
{
  return [threshhold] (int x)
{ return x = threshhold; };
};


template class Pred 
int zero( Pred ) { return 0; }

int main() { return zero( at_or_above(0) ); }


-- 
   Summary: lambda+template=Internal error: Segmentation fault
(program cc1plus)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wb at fnal dot gov


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



[Bug fortran/45159] Unnecessary temporaries

2010-08-02 Thread tkoenig at gcc dot gnu dot org


--- Comment #10 from tkoenig at gcc dot gnu dot org  2010-08-02 19:00 
---
This fixes the test case from comment #0, and looks much more sane.

Let's see if this survives regression-testing...

Index: dependency.c
===
--- dependency.c(Revision 162824)
+++ dependency.c(Arbeitskopie)
@@ -1716,8 +1716,8 @@ gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gf

  /* If no intention of reversing or reversing is explicitly
 inhibited, convert backward dependence to overlap.  */
- if ((reverse == NULL  this_dep == GFC_DEP_BACKWARD)
-   || (reverse  reverse[n] == GFC_CANNOT_REVERSE))
+ if (this_dep == GFC_DEP_BACKWARD
+  (reverse == NULL || reverse[n] == GFC_CANNOT_REVERSE))
this_dep = GFC_DEP_OVERLAP;
}


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-08-01 17:37:25 |2010-08-02 19:00:32
   date||


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



[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

2010-08-02 Thread uweigand at gcc dot gnu dot org


--- Comment #18 from uweigand at gcc dot gnu dot org  2010-08-02 19:25 
---
(In reply to comment #17)
 Someone might want to try this again after the fix for PR 38582.

It's a lot better, but still not real good.  I'm now seeing on a QS22 (ppu -
spu cross compiler):

-O0:  0m9.983s
-O1:  4m7.801s
-O2: 35m10.236s
-O3: 36m7.059s

However, the culprit clearly is no longer register renaming, which is now down
to 5 seconds in the worst case.  For -O1, the by far slowest pass is dead store
elimination:
 dead store elim1  : 101.02 (41%) usr   0.62 (35%) sys 101.65 (41%) wall   
4307 kB ( 7%) ggc
 dead store elim2  : 105.03 (43%) usr   0.65 (37%) sys 105.69 (43%) wall   
3028 kB ( 5%) ggc

For -O2 and -O3, the by far slowest pass is register allocation:
 integrated RA :1485.83 (71%) usr  15.86 (68%) sys1501.87 (71%) wall   
2486 kB ( 2%) ggc
 reload: 157.93 ( 8%) usr   1.97 ( 8%) sys 159.92 ( 8%) wall  
30178 kB (19%) ggc
 reload CSE regs   : 100.05 ( 5%) usr   1.45 ( 6%) sys 101.51 ( 5%) wall  
12556 kB ( 8%) ggc

Scheduling only takes about 2 min in either case.


-- 


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



[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

2010-08-02 Thread pinskia at gcc dot gnu dot org


--- Comment #19 from pinskia at gcc dot gnu dot org  2010-08-02 20:16 
---
 reload CSE regs

Will most likely be helped by:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02397.html


-- 


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



[Bug target/45063] [4.6 Regression] ICE: Segmentation fault (cc1) compiling matmul_i1.c

2010-08-02 Thread bernds at gcc dot gnu dot org


--- Comment #18 from bernds at gcc dot gnu dot org  2010-08-02 20:18 ---
Subject: Bug 45063

Author: bernds
Date: Mon Aug  2 20:17:59 2010
New Revision: 162828

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162828
Log:
PR target/45063
* caller-save.c (save_call_clobbered_regs): Remove regs from
hard_regs_saved when they are set.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/caller-save.c


-- 


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



[Bug inline-asm/45160] [4.4.x/4.5.x regression] Invalid assembly code is generated for x86 architecture for faad2 library (AAC decode algorithm)

2010-08-02 Thread t dot artem at mailcity dot com


--- Comment #9 from t dot artem at mailcity dot com  2010-08-02 20:27 
---
The culprit is the ic_predict.c file. When I compile it with
-fno-strict-aliasing (while everything else is being compiled with
-fstrict-aliasing) libfaad works correctly.

These are the warnings which I get from GCC:

ic_predict.c: In function 'flt_round':
ic_predict.c:58: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ic_predict.c:58: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ic_predict.c:58: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ic_predict.c:60: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ic_predict.c: In function 'ic_prediction':
ic_predict.c:78: warning: dereferencing pointer 'tmp' does break
strict-aliasing rules
ic_predict.c:77: note: initialized from here
ic_predict.c:78: warning: dereferencing pointer 'tmp' does break
strict-aliasing rules
ic_predict.c:77: note: initialized from here
ic_predict.c:78: warning: dereferencing pointer 'tmp' does break
strict-aliasing rules
ic_predict.c:77: note: initialized from here
ic_predict.c:78: warning: dereferencing pointer 'tmp' does break
strict-aliasing rules
ic_predict.c:77: note: initialized from here
ic_predict.c:78: warning: dereferencing pointer 'tmp' does break
strict-aliasing rules
ic_predict.c:77: note: initialized from here
ic_predict.c:78: warning: dereferencing pointer 'tmp' does break
strict-aliasing rules
ic_predict.c:77: note: initialized from here

Maybe GCC developers could devise a patch for this file because
http://www.audiocoding.com/faad2.html site seems to be dead.


-- 


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



[Bug fortran/45161] ICE on gfortran.dg/typebound_proc_16.f03 with -std=f2003

2010-08-02 Thread janus at gcc dot gnu dot org


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-02 20:53:04
   date||


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



[Bug c/45168] New: There should be a way to mark specific enum members as deprecated

2010-08-02 Thread joseph dot h dot garvin at gmail dot com
It's fairly common in C and C++ libraries to have an enum with each element
representing an aspect of a request. In these situations it would be nice to be
able to deprecate specific enum members. For example the user wants to retrieve
a Foo from a server, and Foo's have 3 parts, they might make a request using an
API like this:

enum FooRequest {
WANT_FIZZ = 1  0,
WANT_BUZZ = 1  1,
WANT_BEEZLE = 1  2
};

make_request(WANT_FIZZ | WANT_BUZZ, callback);

And perhaps WANT_BUZZ should be deprecated because now Foo's have some other,
better thing to request instead that should be transitioned to. It'd be nice to
write:

enum FooRequest {
WANT_FIZZ = 1  0,
WANT_BUZZ = 1  1 __attribute__((deprecated)),
WANT_BEEZLE = 1  2,
WANT_SUPERIOR_BUZZ = 1  3
};

So that at compile time users would be notified that WANT_BUZZ is no longer the
way to go.


-- 
   Summary: There should be a way to mark specific enum members as
deprecated
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joseph dot h dot garvin at gmail dot com


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



[Bug fortran/45159] Unnecessary temporaries

2010-08-02 Thread tkoenig at gcc dot gnu dot org


--- Comment #11 from tkoenig at gcc dot gnu dot org  2010-08-02 22:04 
---
Subject: Bug 45159

Author: tkoenig
Date: Mon Aug  2 22:04:36 2010
New Revision: 162829

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162829
Log:

2010-08-02  Thomas Koenig  tkoe...@gcc.gnu.org

PR fortran/45159
* depencency.c (gfc_dep_resolver):  Fix logic for when a loop
can be reversed.

2010-08-02  Thomas Koenig  tkoe...@gcc.gnu.org

PR fortran/45159

* gfortran.dg/dependency_29.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/dependency_29.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/45159] Unnecessary temporaries

2010-08-02 Thread tkoenig at gcc dot gnu dot org


--- Comment #12 from tkoenig at gcc dot gnu dot org  2010-08-02 22:16 
---
(In reply to comment #5)

 [macbook] lin/test% gfc -Warray-temporaries nf.f90
 nf.f90:293.30:
 
if ( ii1 ) x(i:i+nxy-1) = x(i:i+nxy-1) - au3(i-nxy:i-1)*x(i-nxy:i-1)
   1
 Warning: Creating array temporary at (1)
 nf.f90:280.21:
 
   g(i:i+nxy-1) = g(i:i+nxy-1) - au3(i-nxy:i-1)*g(i-nxy:i-1)
  1
 Warning: Creating array temporary at (1)
 nf.f90:261.29:
 
if ( ii1 ) x(i:i+nx-1) = x(i:i+nx-1) - au2(i-nx:i-1)*x(i-nx:i-1)
  1
 Warning: Creating array temporary at (1)
 nf.f90:248.20:
 
   g(i:i+nx-1) = g(i:i+nx-1) - au2(i-nx:i-1)*g(i-nx:i-1)
 1
 Warning: Creating array temporary at (1)
 
 i.e., disjoint sections are not spotted.

This vanishes with -m32.

The reason is that we, for some strange reason, convert the upper
bound to the pointer width on a particular platform.  For 64-bit, this
results in

subroutine foo(a,b,i,j,k,n)   
  implicit none   
  integer, intent(in) :: i, j, k, n   
  real, dimension(n) :: a,b   
  a(k:i-1) = a(i:j)  
end subroutine foo

ending up with -fdump-parse-treee as

ASSIGN foo:a(foo:k:__convert_i4_i8[[(((- foo:i 1)))]])
foo:a(foo:i:__convert_i4_i8[[((foo:j))]])

which confuses gfc_dep_compare_expr, which is too stupid to see through the
type conversion.

I know where to start, but it is late in the evening ;-)


-- 


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



[Bug c++/45169] New: C++ Hello World mudflap violations

2010-08-02 Thread bryanr81 at gmail dot com
A trivial C++ 'hello world' produces mudflap violations w/ -O2, but not w/ -O0:

---
#include iostream
int main() {
std::cout  hello  std::endl;
}
---
/opt/gcc-4.5.1/bin/gcc -Wall -O2 -fmudflap -o test test.cc -lmudflap -lstdc++
./test
***
mudflap violation 1 (check/read): time=1280788265.017031 ptr=0x7f1d214b79e0
size=8
pc=0x7f1d214dbd31
location=`/opt/gcc-4.5.1/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/ostream:542:46
(main)'
  /opt/gcc-4.5.1/lib64/libmudflap.so.0(__mf_check+0x41) [0x7f1d214dbd31]
  ./test(main+0x23b) [0x400ebb]
  /lib/libc.so.6(__libc_start_main+0xfd) [0x7f1d20e6cc4d]
number of nearby objects: 0
***
mudflap violation 2 (check/read): time=1280788265.017175 ptr=0x7f1d214bdec0
size=57
pc=0x7f1d214dbd31
location=`/opt/gcc-4.5.1/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/bits/locale_facets.h:866:2
(main)'
  /opt/gcc-4.5.1/lib64/libmudflap.so.0(__mf_check+0x41) [0x7f1d214dbd31]
  ./test(main+0x1ee) [0x400e6e]
  /lib/libc.so.6(__libc_start_main+0xfd) [0x7f1d20e6cc4d]
number of nearby objects: 0
***
mudflap violation 3 (check/read): time=1280788265.017233 ptr=0x7f1d214bdec0
size=8
pc=0x7f1d214dbd31
location=`/opt/gcc-4.5.1/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/bits/locale_facets.h:869:27
(main)'
  /opt/gcc-4.5.1/lib64/libmudflap.so.0(__mf_check+0x41) [0x7f1d214dbd31]
  ./test(main+0x27c) [0x400efc]
  /lib/libc.so.6(__libc_start_main+0xfd) [0x7f1d20e6cc4d]
number of nearby objects: 0
***
mudflap violation 4 (check/read): time=1280788265.017289 ptr=0x7f1d214b4de0
size=8
pc=0x7f1d214dbd31
location=`/opt/gcc-4.5.1/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/bits/locale_facets.h:869:27
(main)'
  /opt/gcc-4.5.1/lib64/libmudflap.so.0(__mf_check+0x41) [0x7f1d214dbd31]
  ./test(main+0x2a3) [0x400f23]
  /lib/libc.so.6(__libc_start_main+0xfd) [0x7f1d20e6cc4d]
number of nearby objects: 0
hello
---
/opt/gcc-4.5.1/bin/gcc -Wall -O0 -fmudflap -o test test.cc -lmudflap -lstdc++
./test
hello
---

Expected Behavior: No mudflap violations with -O2

gcc -v:
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.5.1/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.1/libexec/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5.1/configure --prefix=/opt/gcc-4.5.1
--disable-bootstrap --enable-languages=c,c++
Thread model: posix
gcc version 4.5.1 (GCC) 


Also fails with ubuntu 10.04's:

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)


-- 
   Summary: C++ Hello World mudflap violations
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bryanr81 at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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



[Bug fortran/45170] New: suspected bug in error generated by allocatable character array

2010-08-02 Thread clerman at fuse dot net
gfortran tech support,

  When I attempt to compile the program listed below, the following error
messages are printed:

n...@oxford:~/Elements/AllocChar$ more alloccharP.xyz 
alloccharP.f90:6.12:

  character(:), allocatable :: c_Char(:)
1
Error: Syntax error in CHARACTER declaration at (1)
alloccharP.f90:7.12:

  character(:), allocatable :: io_message
1
Error: Syntax error in CHARACTER declaration at (1)

  I searched the bug database but could not find this bug listed.

 I am attempting to declare an array of allocatable characters, which I believe
is legal. The Intel 12.0 beta compiler and version 5.2 of the nag compiler both
compile this routine. (The routine, as written, is not correct: the variable
io_message needs to be allocated before it is used in the open statement.)

  Thank you for your attention.

Yours truly,

Norm

Norman S. Clerman

program AllocChar

  integer, parameter :: CHAR_ELEMENTS = 5, FILE_UNIT = 11
  integer :: io_stat
!  character(:), allocatable :: c_Char(CHAR_ELEMENTS)
  character(:), allocatable :: c_Char(:)
  character(:), allocatable :: io_message
  character (*), parameter :: FILE_NAME = no_file.dat

!  io_message = no errors
!  print *, io_message
!  c_Char =  
!  c_Char(1: 2) = [Hello ,  everyone!]
!  c_Char(1) = Hello
!  c_Char(2) = everyone
!  print *, c_Char (1: 2)

  open (unit = FILE_UNIT, file = FILE_NAME, iostat = io_stat, iomsg =
io_message, status = old)

  print *, io_message

end program AllocChar


-- 
   Summary: suspected bug in error generated by allocatable
character array
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: clerman at fuse dot net


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



[Bug fortran/45170] suspected bug in error generated by allocatable character array

2010-08-02 Thread kargl at gcc dot gnu dot org


--- Comment #1 from kargl at gcc dot gnu dot org  2010-08-03 02:31 ---
This statement:

character(:), allocatable :: io_message

uses a deferred type parameter (a F2003
feature), which is not supported by gfortran
at this time.


-- 


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



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

2010-08-02 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2010-08-03 05:43 ---
By the way, gfortran's Fortran 2003 implementation status can be found at
http://gcc.gnu.org/wiki/Fortran2003Status


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||20585
  nThis||
Summary|suspected bug in error  |[F2003] allocatable
   |generated by allocatable|character lengths
   |character array |


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