[Bug treelang/23072] multiple runs of treelang testsuite does not work...
--- Additional Comments From christian dot joensson at gmail dot com 2005-08-13 07:41 --- So, this is what it looks like now: Test Run By chj on Sat Aug 13 09:36:47 2005 Native configuration is sparc64-unknown-linux-gnu === treelang tests === Schedule of variations: unix/-m64 unix Running target unix/-m64 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /usr/local/src/branch/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/compile.exp ... Running /usr/local/src/branch/gcc/gcc/testsuite/treelang/execute/execute.exp ... Running /usr/local/src/branch/gcc/gcc/testsuite/treelang/output/output.exp ... === treelang Summary for unix/-m64 === # of expected passes48 Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /usr/local/src/branch/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/compile.exp ... Running /usr/local/src/branch/gcc/gcc/testsuite/treelang/execute/execute.exp ... Running /usr/local/src/branch/gcc/gcc/testsuite/treelang/output/output.exp ... === treelang Summary for unix === # of expected passes48 === treelang Summary === # of expected passes96 This is with http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00661.html (and the rest of removal and addition of files from your mainline patch here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23072#c7) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23072
[Bug c++/23372] New: Temporary aggregate copy not elided when passing parameters by value
This bug is similar to bug 16405, but although 16405 was fixed in 4.0, this one
is still present and is a regression from GCC 3.4 (not from 3.3 as was the
previous one). So I prefer opening a new bug-report.
The testcase simply calls a function f by passing the parameter by value:
struct A {
int a[1000];
//A(A const &);
};
void f(A);
void g(A *a) { f(*a); }
When compiled with gcc 3.3 and 3.4, the generated code for g is optimal: the
value *a is directly copied in the stack frame that will be used by f. With gcc
4.0, there is first a temporary copy in the stack frame of g, before copying the
value in the stack frame of f (two memcpys instead of one).
When putting a dummy copy constructor, both memcpys disappear: the code is
optimal. So the problem seems to be with the default trivial copy constructor.
The testcase is compiled with "g++-4.0 -O3", Debian package:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.2 20050806 (prerelease) (Debian 4.0.1-4)
--
Summary: Temporary aggregate copy not elided when passing
parameters by value
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug tree-optimization/23048] [4.1 Regression] ICE in get_loop_body with -O1 -ftree-vectorize on 4.1.x
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-08-13 08:09 --- (In reply to comment #12) > Patch: > http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00612.html Works for me. Tested on both i686-pc-linux-gnu and x86_64-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048
[Bug fortran/23373] New: Functions returning pointers with pointer argument
There is a bad case of aliasing here:
$ cat pointer_function.f90
program Realloc
IMPLICIT NONE
REAL, DIMENSION(:), POINTER :: x
INTEGER :: i
x => NULL()
x => myallocate(x)
contains
FUNCTION myallocate(p)
REAL, DIMENSION(:), POINTER :: p, myallocate
INTEGER :: nold,ierr
if (associated(p)) then
print *,"p is associated"
else
print *,"p is not associated"
end if
allocate(myallocate(20))
if (associated(p)) then
print *,"p is associated"
else
print *,"p is not associated"
end if
END FUNCTION myallocate
end program Realloc
$ gfortran -fdump-tree-original pointer_function.f90
$ ./a.out
p is not associated
p is associated
$ tail -10 pointer_function.f90.t02.original
{
struct array1_real4 x;
static void myallocate (struct array1_real4 &, struct array1_real4 &);
x.data = 0B;
x.data = 0B;
myallocate (&x, &x);
}
The two arguments to myallocate are bogus - they alias each other,
and they shouldn't. A tempoaray array descriptor is needed here.
--
Summary: Functions returning pointers with pointer argument
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-13 09:31
---
(In reply to comment #0)
Edmund,
>
> professional. Is there a workaround or is this a bug which must be fixed?
>
>
Thomas beat you to it!
In the mean time, the following works:
program Realloc
USE nrtype; USE nrutil
IMPLICIT NONE
REAL(SP), DIMENSION(:), POINTER :: x, y
INTEGER(I4B) :: i
allocate(x(10))
forall(i=1:ubound(x,1)) x(i)=i
write(*,"(10F6.2)") x
y => reallocate(x,20) ! Use y...
x => y! ...and then point x to y
forall(i=1:ubound(x,1)) x(i)=2*i
write(*,"(20F6.2)") x
end program Realloc
For some reason, the compiler is not detecting the dependency and putting the
result of reallocate in a temporary. What happens is that reallocate does all
the right things, up until the deallocate. which it does to the lhs, being
the same as the result, ie to x! An alternative fix is to comment out the
deallocate.
I'll take a look see over the next few days. It's a bit of code that I need to
revisit for another reason.
Best regards
Paul T
> FUNCTION myallocate(p)
> REAL, DIMENSION(:), POINTER :: p, myallocate
> INTEGER :: nold,ierr
> if (associated(p)) then
>print *,"p is associated"
> else
>print *,"p is not associated"
> end if
> allocate(myallocate(20))
> if (associated(p)) then
>print *,"p is associated"
> else
>print *,"p is not associated"
> end if
> END FUNCTION myallocate
> end program Realloc
> $ gfortran -fdump-tree-original pointer_function.f90
> $ ./a.out
> p is not associated
> p is associated
> $ tail -10 pointer_function.f90.t02.original
> {
> struct array1_real4 x;
> static void myallocate (struct array1_real4 &, struct array1_real4 &);
>
> x.data = 0B;
> x.data = 0B;
> myallocate (&x, &x);
> }
>
> The two arguments to myallocate are bogus - they alias each other,
> and they shouldn't. A tempoaray array descriptor is needed here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug tree-optimization/23361] Can't eliminate empty loops with power of two step and variable bounds
--- Additional Comments From giovannibajo at libero dot it 2005-08-13 10:01 --- One thing is that if 'a' and 'b' are originally pointers of the same type, it should be clear the the loop can be removed. When they are lowered to integers, instead, we lose the precious alignment information. Can't the empty loop be removed before the pointers are lowered? Or am I missing something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23361
[Bug tree-optimization/21574] store_ccp doesn't see through a store.
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-13
10:09 ---
My .vars dump:
foo (p)
{
:
*p = 0;
return 0;
}
--
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21574
[Bug tree-optimization/21574] store_ccp doesn't see through a store.
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-13 10:12 --- Whoops, didn't want to close it!! Wanted to say that the patch from Bug 23094 fixes this for me. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21574
[Bug tree-optimization/23094] store ccp misses an optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-13 10:30 --- Hmm, can someone explain where in store_ccp we stuff constants into the mem_ref field of lattice values? There are a few places where simple_cst_equal is used to compare a constant to mem_ref but AFAICT mem_ref is always the lhs of an expression?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23094
[Bug fortran/23374] New: Reallocate problem (Numerical Recipes fortran source)
I have downloaded "Native Windows build: download the latest installer
(2005-08-06)" from http://gcc.gnu.org/wiki/GFortranBinaries.
I have a problem with the attached code from Numerical Recipes; ifort
(Intel) and LF95 Ver. 5.7 (Lahey) produce executables which work fine, but
the gfortran compiled code fails at run time. I am using Windows XP
professional.
My compile command is:
gfortran test_reallocate.f90 -O2 -malign-double -march=pentium3 -ffast-math -
funroll-loops -o test_reallocate.exe
Source code that demos the problem is as follows:-
! NRTYPE.F90
MODULE nrtype
INTEGER, PARAMETER :: I4B = SELECTED_INT_KIND(9)
INTEGER, PARAMETER :: I2B = SELECTED_INT_KIND(4)
INTEGER, PARAMETER :: I1B = SELECTED_INT_KIND(2)
INTEGER, PARAMETER :: SP = KIND(1.0)
INTEGER, PARAMETER :: DP = KIND(1.0D0)
INTEGER, PARAMETER :: SPC = KIND((1.0,1.0))
INTEGER, PARAMETER :: DPC = KIND((1.0D0,1.0D0))
INTEGER, PARAMETER :: LGT = KIND(.true.)
REAL(SP), PARAMETER :: PI=3.141592653589793238462643383279502884197_sp
REAL(SP), PARAMETER ::
PIO2=1.57079632679489661923132169163975144209858_sp
REAL(SP), PARAMETER ::
TWOPI=6.283185307179586476925286766559005768394_sp
REAL(SP), PARAMETER ::
SQRT2=1.41421356237309504880168872420969807856967_sp
REAL(SP), PARAMETER ::
EULER=0.5772156649015328606065120900824024310422_sp
REAL(DP), PARAMETER ::
PI_D=3.141592653589793238462643383279502884197_dp
REAL(DP), PARAMETER ::
PIO2_D=1.57079632679489661923132169163975144209858_dp
REAL(DP), PARAMETER ::
TWOPI_D=6.283185307179586476925286766559005768394_dp
TYPE sprs2_sp
INTEGER(I4B) :: n,len
REAL(SP), DIMENSION(:), POINTER :: val
INTEGER(I4B), DIMENSION(:), POINTER :: irow
INTEGER(I4B), DIMENSION(:), POINTER :: jcol
END TYPE sprs2_sp
TYPE sprs2_dp
INTEGER(I4B) :: n,len
REAL(DP), DIMENSION(:), POINTER :: val
INTEGER(I4B), DIMENSION(:), POINTER :: irow
INTEGER(I4B), DIMENSION(:), POINTER :: jcol
END TYPE sprs2_dp
END MODULE nrtype
! NRUTIL.F90
MODULE nrutil
USE nrtype
IMPLICIT NONE
INTERFACE reallocate
MODULE PROCEDURE reallocate_rv,reallocate_rm,&
reallocate_iv,reallocate_im,reallocate_hv
END INTERFACE
CONTAINS
!BL
SUBROUTINE nrerror(string)
CHARACTER(LEN=*), INTENT(IN) :: string
write (*,*) 'nrerror: ',string
STOP 'program terminated by nrerror'
END SUBROUTINE nrerror
!BL
FUNCTION reallocate_rv(p,n)
REAL(SP), DIMENSION(:), POINTER :: p, reallocate_rv
INTEGER(I4B), INTENT(IN) :: n
INTEGER(I4B) :: nold,ierr
allocate(reallocate_rv(n),stat=ierr)
if (ierr /= 0) call &
nrerror('reallocate_rv: problem in attempt to allocate memory')
if (.not. associated(p)) RETURN
nold=size(p)
reallocate_rv(1:min(nold,n))=p(1:min(nold,n))
deallocate(p)
END FUNCTION reallocate_rv
!BL
FUNCTION reallocate_iv(p,n)
INTEGER(I4B), DIMENSION(:), POINTER :: p, reallocate_iv
INTEGER(I4B), INTENT(IN) :: n
INTEGER(I4B) :: nold,ierr
allocate(reallocate_iv(n),stat=ierr)
if (ierr /= 0) call &
nrerror('reallocate_iv: problem in attempt to allocate memory')
if (.not. associated(p)) RETURN
nold=size(p)
reallocate_iv(1:min(nold,n))=p(1:min(nold,n))
deallocate(p)
END FUNCTION reallocate_iv
!BL
FUNCTION reallocate_hv(p,n)
CHARACTER(1), DIMENSION(:), POINTER :: p, reallocate_hv
INTEGER(I4B), INTENT(IN) :: n
INTEGER(I4B) :: nold,ierr
allocate(reallocate_hv(n),stat=ierr)
if (ierr /= 0) call &
nrerror('reallocate_hv: problem in attempt to allocate memory')
if (.not. associated(p)) RETURN
nold=size(p)
reallocate_hv(1:min(nold,n))=p(1:min(nold,n))
deallocate(p)
END FUNCTION reallocate_hv
!BL
FUNCTION reallocate_rm(p,n,m)
REAL(SP), DIMENSION(:,:), POINTER :: p, reallocate_rm
INTEGER(I4B), INTENT(IN) :: n,m
INTEGER(I4B) :: nold,mold,ierr
allocate(reallocate_rm(n,m),stat=ierr)
if (ierr /= 0) call &
nrerror('reallocate_rm: problem in attempt to allocate memory')
if (.not. associated(p)) RETURN
nold=size(p,1)
mold=size(p,2)
reallocate_rm(1:min(nold,n),1:min(mold,m))=&
p(1:min(nold,n),1:min(mold,m))
deallocate(p)
END FUNCTION reallocate_rm
!BL
FUNCTION reallocate_im(p,n,m)
INTEGER(I4B), DIMENSION(:,:), POINTER :: p, reallocate_im
INTEGER(I4B), INTENT(IN) :: n,m
INTEGER(I4B) :: nold,mold,ierr
allocate(reallocate_im(n,m),stat=ierr)
[Bug fortran/23374] Reallocate problem (Numerical Recipes fortran source)
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-13 11:47 --- *** This bug has been marked as a duplicate of 23373 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23374
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-13 11:47 --- *** Bug 23374 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||edunlop at utvinternet dot ||ie http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug fortran/23373] Functions returning pointers with pointer argument
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-13 11:47:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug fortran/20663] Generic function is not resolved
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-13 11:54 --- This has been fixed with Paul T's patch for generic name resolution. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20663
[Bug fortran/23375] New: show location for runtime errors
For runtime errors like bounds checking violations, we display Fortran runtime error: Array reference out of bounds without an indication of where the error occurs. There is some support in runtime/error.c (with the GFC_SHOW_LOCUS environment variable), but it is unsupported by the front end at the moment. -- Summary: show location for runtime errors Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug fortran/23368] internal compiler error with NAG routines
--- Additional Comments From haefele at mpi-magdeburg dot mpg dot de 2005-08-13 13:18 --- (In reply to comment #4) > How old is your version of gfortran? I can compile your example with lion:[~]> gfortran --version GNU Fortran 95 (GCC 4.0.1 (Debian 4.0.1-2)) Copyright (C) 2005 Free Software Foundation, Inc. It's the version in Debian-Testing. So maybe upgrading helps, I'll try it. > troutmask:sgk[220] gfc41 --version > GNU Fortran 95 (GCC 4.1.0 20050811 (experimental)) > > troutmask:sgk[221] gfc --version > GNU Fortran 95 (GCC 4.0.2 20050719 (prerelease)) > > But it fails with a segfault with > > GNU Fortran 95 (GCC 4.0.1 20050527 (prerelease)) > Copyright (C) 2005 Free Software Foundation, Inc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23368
[Bug c++/23372] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-08-13 14:17 ---
The problem is, we end up with
void g(A*) (a)
{
struct A D.1608;
:
D.1608 = *a;
f (D.1608) [tail call];
return;
}
after the tree optimizers. f (*a) would not be gimple, so we create
the temporary in the first place. TER does not remove this wart,
neither does expand - so we start with two memcpys after RTL expansion.
This is definitively different from PR16405.
--
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug tree-optimization/23376] New: ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
The example (attached below), when compiled by following gcc --- $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../../gcc-CVS-20050812/gcc-CVS-20050812/configure --host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1 --exec-prefix=/usr/local/opt/gcc-4.1 --sysconfdir=/etc --libdir=/usr/local/opt/gcc-4.1/lib --libexecdir=/usr/local/opt/gcc-4.1/libexec --sharedstatedir=/var --localstatedir=/var --program-suffix=-4.1 --with-x-includes=/usr/X11R6/include --with-x-libraries=/usr/X11R6/lib --enable-shared --enable-static --with-gnu-as --with-gnu-ld --with-stabs --enable-threads=posix --enable-version-specific-runtime-libs --disable-coverage --disable-libgcj --disable-checking --enable-multilib --with-x --enable-cmath --enable-libstdcxx-debug --enable-fast-character --enable-hash-synchronization --with-system-zlib --with-libbanshee --with-demangler-in-ld --with-arch=athlon-xp --enable-libada --enable-languages=c,c++,f95,objc,ada Thread model: posix gcc version 4.1.0 20050812 (experimental) - with - g++ -O1 -funroll-loops -fvariable-expansion-in-unroller -c me_utils_mmx.cpp -o me_utils_mmx.o - results in this: - me_utils_mmx.cpp: In function âdirac::CalcValueType dirac::simple_block_diff_up_mmx_4(const dirac::PicArray&, const dirac::PicArray&, const dirac::ImageCoords&, const dirac::ImageCoords&, const dirac::ImageCoords&, const dirac::ValueType*)â: me_utils_mmx.cpp:23841: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. - Tested on i686-pc-linux-gnu. gcc version 4.0.2 20050804 (prerelease) fails the same way. gcc version 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk) doesn't compile this at all because of errors (should be because the included headers are from 4.1), perhaps after reduction it might. For x86_64 it fails as well, though it requires a patch (also attached) to compile, again due to the includes from i686 GCC this time. -- Summary: ICE on GCC 4.x with -O1 -funroll-loops -fvariable- expansion-in-unroller Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drab at kepler dot fjfi dot cvut dot cz CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug tree-optimization/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-08-13 14:49 --- Created an attachment (id=9491) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9491&action=view) Triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug tree-optimization/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-08-13 14:51 --- Created an attachment (id=9492) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9492&action=view) Patch to the original example to compile (and also trigger the bug) for x86_64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug treelang/23072] multiple runs of treelang testsuite does not work...
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-13 16:32 --- Don't bother with treelang on the 3.4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23072
[Bug c++/23372] Temporary aggregate copy not elided when passing parameters by value
-- What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-13 17:28 --- Subject: Bug 22236 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-13 17:28:43 Modified files: gcc: ChangeLog tree-cfg.c tree-chrec.c tree-data-ref.c tree-data-ref.h tree-flow-inline.h tree-flow.h tree-scalar-evolution.c tree-ssa-loop-ivcanon.c tree-ssa-loop-ivopts.c tree-ssa-loop-niter.c tree-vect-analyze.c tree-vrp.c Added files: gcc/testsuite/gcc.dg/tree-ssa: pr22236.c Log message: PR tree-optimization/22236 * tree-cfg.c (print_pred_bbs, print_succ_bbs): Correctly print successors and predecessors. * tree-chrec.c (chrec_convert): Before converting, check that sequences don't wrap. * tree-data-ref.c (compute_estimated_nb_iterations): Moved ... (analyze_array): Extern. (find_data_references_in_loop): Remove call to compute_estimated_nb_iterations. * tree-data-ref.h (analyze_array): Declared. * tree-flow-inline.h (single_ssa_tree_operand, single_ssa_use_operand, single_ssa_def_operand, zero_ssa_operands): Fix documentation. * tree-flow.h (scev_probably_wraps_p): Declare with an extra parameter. * tree-scalar-evolution.c (instantiate_parameters_1): Factor entry condition. * tree-ssa-loop-ivcanon.c: Fix documentation. * tree-ssa-loop-ivopts.c (idx_find_step): Add a fixme note. * tree-ssa-loop-niter.c (compute_estimated_nb_iterations): ... here. (infer_loop_bounds_from_undefined): New. (estimate_numbers_of_iterations_loop): Use infer_loop_bounds_from_undefined. (used_in_pointer_arithmetic_p): New. (scev_probably_wraps_p): Pass an extra parameter. Call used_in_pointer_arithmetic_p. Check that AT_STMT is not null. (convert_step): Fix documentation. * tree-vrp.c (adjust_range_with_scev): Call instantiate_parameters. Use initial_condition_in_loop_num and evolution_part_in_loop_num instead of CHREC_LEFT and CHREC_RIGHT. Adjust the call to scev_probably_wraps_p. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9720&r2=2.9721 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.215&r2=2.216 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gcc&r1=2.22&r2=2.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-data-ref.c.diff?cvsroot=gcc&r1=2.35&r2=2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-data-ref.h.diff?cvsroot=gcc&r1=2.10&r2=2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow-inline.h.diff?cvsroot=gcc&r1=2.55&r2=2.56 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gcc&r1=2.131&r2=2.132 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.c.diff?cvsroot=gcc&r1=2.34&r2=2.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivcanon.c.diff?cvsroot=gcc&r1=2.19&r2=2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.86&r2=2.87 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-niter.c.diff?cvsroot=gcc&r1=2.35&r2=2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vect-analyze.c.diff?cvsroot=gcc&r1=2.34&r2=2.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.51&r2=2.52 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr22236.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22236
[Bug fortran/21253] Bounds Check
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 17:49 --- (In reply to comment #2) > Subject: Re: Bounds Check > > Sorry, I do not have a simple test case, but might be able to construct > one if part 1 is solved. A debugger can help. Anyways PR 23375 was filed for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21253
[Bug fortran/23375] show location for runtime errors
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 17:50 --- Confirmed. Though sometimes I wonder if this is an over use of printf style debugging. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-13 17:50:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 17:56 --- Confirmed. (In reply to comment #1) > after the tree optimizers. f (*a) would not be gimple, so we create > the temporary in the first place. TER does not remove this wart, > neither does expand - so we start with two memcpys after RTL expansion. TER only works on scalars so it cannot work. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Known to fail||4.0.0 4.1.0 Known to work||3.4.0 3.3.3 3.2.3 3.0.4 ||2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-08-13 17:56:39 date|| Summary|Temporary aggregate copy not|[4.0/4.1 Regression] |elided when passing |Temporary aggregate copy not |parameters by value |elided when passing ||parameters by value Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From giovannibajo at libero dot it 2005-08-13 18:00 --- Why doesn't this happen with the copy constructor, then? there we should be calling the copyctor with *a, which would have the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug tree-optimization/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
-- What|Removed |Added GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug pending/23378] New: code quality regression for complicated loop
A code quality regression was introduced into CVS between the timestamps "-D 20050729 22:00:00 UT" and "-D 20050729 23:00:00 UT". It appears that it iss caused by Jan Hubicka's patch from http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02021.html If the attached testcase is compiled with the newer compiler, the runtime of the generated executable is more than 50 per cent higher: old compiler: ~/tmp/tmp2>g++ -O3 -march=pentium4 -mfpmath=sse testcase.cc ~/tmp/tmp2>time ./a.out 14.250u 0.020s 0:14.27 100.0% 0+0k 0+0io 205pf+0w new compiler: ~/tmp/tmp2>g++ -O3 -march=pentium4 -mfpmath=sse testcase.cc ~/tmp/tmp2>time ./a.out 22.430u 0.030s 0:22.46 100.0% 0+0k 0+0io 205pf+0w Both compilers have the same "g++ -v" output: ~/tmp/tmp2>g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /scratch/gcc/configure --quiet --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++ --enable-mapped-location --disable-checking Thread model: posix gcc version 4.1.0 20050729 (experimental) The hot spot of the code is the strange "loop" in lines 134-139 of alm_map_tools_orig.cc. -- Summary: code quality regression for complicated loop Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: pending AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de CC: gcc-bugs at gcc dot gnu dot org,martin at mpa-garching dot mpg dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
[Bug rtl-optimization/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 18:04 --- Reducing, this is not a regression as variable-expansion-in-unroller is new in 4.0.0. This is also a rtl issue and not a tree issue. -- What|Removed |Added Component|tree-optimization |rtl-optimization Keywords||ice-on-valid-code Known to fail||4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug pending/23378] code quality regression for complicated loop
--- Additional Comments From martin at mpa-garching dot mpg dot de 2005-08-13 18:05 --- Created an attachment (id=9494) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9494&action=view) A testcase for the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
[Bug target/23378] [4.1 Regression] code quality regression for complicated loop
-- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|pending |target Summary|code quality regression for |[4.1 Regression] code |complicated loop|quality regression for ||complicated loop Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-08-13 18:11 ---
With the copy ctor we end up with
void g(A*) (a)
{
struct A D.1603;
:
__comp_ctor (&D.1603, a);
f (&D.1603);
return;
}
which confuses me a bit, because here the prototype of f looks like
effectively
void f(A*);
do we use ABI information here, but not in the other case? The C++
frontend in this case presents us with
{
<
D.1603 >>>
>) >>>
>>;
}
where in the case w/o the copy ctor we have
<>) >>>
>>;
is there some different wording about by-value parameter passing
with or without explicit copy ctor in the C++ standard?! I.e., why
isn't the above
<>) >>>
>>;
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 18:12 --- (In reply to comment #4) > which confuses me a bit, because here the prototype of f looks like > effectively > > void f(A*); No that is correct as it turns the class into a non pod and non pods are always passed via reference and not via value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-08-13 18:16 --- Indeed - adding a destructor (or anything else that makes it a non-POD) "fixes" the problem, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug target/23355] size optimizer did not eliminateing useless Push and pop instructions at ARM/Thumb machine
--- Additional Comments From th dot r dot klein at web dot de 2005-08-13
18:27 ---
I've reduced the function to a useless, but bug still remains.
(sorry: I've forgotten to tar the files so I'm attaching those manualy.)
###
~/work/bugreport$ arm-elf-gcc-3.4.4 -v -save-temps -g -Os -fPIC -mthumb
-mlittle-endian -mapcs -march=armv4t-mcallee-super-interworking -c
example_3_4_4.c -o 3_4_4_thumb.o
Reading specs from /usr/local/lib/gcc/arm-elf/3.4.4/specs
Configured with: ../../gcc-3.4.4/configure --target=arm-elf --disable-threads
--disable-nls --without-headers --without-libs --enable-languages=c
Thread model: single
gcc version 3.4.4
/usr/local/libexec/gcc/arm-elf/3.4.4/cc1 -E -quiet -v -D__ARM_ARCH_4T__
-D__USES_INITFINI__ example_3_4_4.c -mthumb -mlittle-endian -mapcs -march=armv4t
-mcallee-super-interworking -fPIC -fworking-directory -Os -o example_3_4_4.i
ignoring nonexistent directory
"/usr/local/lib/gcc/arm-elf/3.4.4/../../../../arm-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/arm-elf/3.4.4/include
/usr/local/lib/gcc/arm-elf/3.4.4/../../../../arm-elf/include
End of search list.
/usr/local/libexec/gcc/arm-elf/3.4.4/cc1 -fpreprocessed example_3_4_4.i -quiet
-dumpbase example_3_4_4.c -mthumb-mlittle-endian -mapcs -march=armv4t
-mcallee-super-interworking -auxbase-strip 3_4_4_thumb.o -g -Os -version -fPIC
-o example_3_4_4.s
GNU C version 3.4.4 (arm-elf)
compiled by GNU C version 3.4.2 [FreeBSD] 20040728.
GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=65536
/usr/local/lib/gcc/arm-elf/3.4.4/../../../../arm-elf/bin/as -EL -march=armv4t
-o 3_4_4_thumb.o example_3_4_4.s
###
file example_3_4_4.i
###
# 1 "example_3_4_4.c"
# 1 "/home/thomas/work/bugreport//"
# 1 ""
# 1 ""
# 1 "example_3_4_4.c"
typedef char int8_t;
typedef short int16_t;
typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;
typedef int __attribute__((__mode__(__DI__))) int64_t;
typedef unsigned int __attribute__((__mode__(__DI__))) uint64_t;
# 34 "example_3_4_4.c"
int progWord(uint32_t base_address,uint32_t address,uint32_t data)
{
volatile uint32_t *dataPtr;
uint32_t rd_data;
*((volatile uint32_t *)(base_address + (0x555uL<<2))) = 0x;
dataPtr = (uint32_t *)address;
*dataPtr = data;
return 0;
}
###
file example_3_4_4.s
###
.code 16
.file "example_3_4_4.c"
.section.debug_abbrev,"",%progbits
.Ldebug_abbrev0:
.section.debug_info,"",%progbits
.Ldebug_info0:
.section.debug_line,"",%progbits
.Ldebug_line0:
.text
.Ltext0:
.align 2
.global progWord
.code 32
.type progWord, %function
progWord:
.LFB2:
.file 1 "example_3_4_4.c"
.loc 1 35 0
orr ip, pc, #1
bx ip
.code 16
.globl .real_start_ofprogWord
.thumb_func
.real_start_ofprogWord:
.loc 1 40 0
ldr r3, .L2
add r0, r0, r3
ldr r3, .L2+4
str r3, [r0]
.loc 1 46 0
mov r0, #0
.loc 1 43 0
str r2, [r1]
.loc 1 46 0
@ sp needed for prologue
bx lr
.L3:
.align 2
.L2:
.word 5460
.word -1431655766
.LFE2:
.size progWord, .-progWord
.section.debug_frame,"",%progbits
.Lframe0:
.4byte .LECIE0-.LSCIE0
.LSCIE0:
.4byte 0x
.byte 0x1
.ascii "\000"
.uleb128 0x1
.sleb128 -4
.byte 0xe
.byte 0xc
.uleb128 0xd
.uleb128 0x0
.align 2
.LECIE0:
.LSFDE0:
.4byte .LEFDE0-.LASFDE0
.LASFDE0:
.4byte .Lframe0
.4byte .LFB2
.4byte .LFE2-.LFB2
.align 2
.LEFDE0:
.text
.Letext0:
.section.debug_info
.4byte 0xc9
.2byte 0x2
.4byte .Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.4byte .Ldebug_line0
.4byte .Letext0
.4byte .Ltext0
.4byte .LASF12
.byte 0x1
.4byte .LASF13
.4byte .LASF14
.uleb128 0x2
.4byte .LASF0
.byte 0x1
.byte 0x8
.uleb128 0x2
.4byte .LASF1
.byte 0x2
.byte 0x5
.uleb128 0x3
.ascii "int\000"
.byte 0x4
.byte 0x5
.uleb128 0x2
.4byte .LASF2
.byte 0x1
.byte 0x8
.uleb128 0x2
.4byte .LASF3
.byte 0x2
.byte
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From tobi at gcc dot gnu dot org 2005-08-13 18:43 --- Looks like dependency checking is not strict enough. -- What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From tobi at gcc dot gnu dot org 2005-08-13 18:51
---
Interestingly, for characters we do the correct copying:
[EMAIL PROTECTED]:~/src/tests> cat test2.f90
program ac
character*10 a
a = "abc"
a = f(a)
contains
function f(b) result(x)
character*10 b, x
x = "falsch"
b = b//"richtig"
end function
end program
[EMAIL PROTECTED]:~/src/tests> ../gcc/build/gcc/f951 test2.f90
-fdump-tree-original -quiet
[EMAIL PROTECTED]:~/src/tests> tail -15 test2.f90.t02.original
MAIN__ ()
{
char a[1:10];
static void f (char[1:10] &, int4, char[1:10] &, int4);
_gfortran_copy_string (10, &a, 3, "abc");
{
char str.1[10];
f ((char[1:10] *) &str.1, 10, &a, 10);
_gfortran_copy_string (10, &a, 10, (char[1:10] *) &str.1);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug rtl-optimization/23376] ICE on GCC 4.x with -O1 -funroll-loops -fvariable-expansion-in-unroller
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13
19:18 ---
Confirmed, reduced testcase:
typedef int __m64 __attribute__ ((__vector_size__ (8)));
typedef int __v2si __attribute__ ((__vector_size__ (8)));
static __inline __m64 __attribute__((__always_inline__)) _mm_add_pi32 (__m64
__m1, __m64 __m2) {
return (__m64) __builtin_ia32_paddd ((__v2si)__m1, (__v2si)__m2);
};
__m64 simple_block_diff_up_mmx_4( const int width ,__m64 ref1 ) {
__m64 sum;
int count = width >>1;
while (count--)
sum = _mm_add_pi32 (sum, ref1);
return sum;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-13 19:18:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23376
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
-- What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug testsuite/23348] objc testsuite should run over both GNU and NeXT runtimes if supported
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-13 21:16 --- Subject: Bug 23348 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-13 21:16:04 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/lib: objc-torture.exp Added files: gcc/testsuite/objc/compile: trivial.m Log message: 2005-08-13 Andrew Pinski <[EMAIL PROTECTED]> part of PR testsuite/23348 * lib/objc-torture.exp: Add -fgnu-runtime and/or -fnext-runtime to each of the torture options. * objc/compile/trivial.m: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5914&r2=1.5915 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/lib/objc-torture.exp.diff?cvsroot=gcc&r1=1.9&r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/objc/compile/trivial.m.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23348
[Bug testsuite/23348] objc testsuite should run over both GNU and NeXT runtimes if supported
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 21:18 --- objc/ turture is done but objc.dg needs to be done but it is much harder. many of the tests in objc.dg can be moved over to objc so they can be tested on both runtimes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23348
[Bug testsuite/23348] objc testsuite should run over both GNU and NeXT runtimes if supported
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 21:21 --- for the exceptions testcase, we need to add a new directory which would be useful anyways as it shows tests which fail at higher optimizations and such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23348
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-13 21:21 --- The best place to fix this is probably still the expander or TER. Or out-of-ssa, where the necessary information is best present. Or fix gimple and gimplification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug libfortran/23364] missing format reversion for internal write
-- What|Removed |Added OtherBugsDependingO||23379 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23364
[Bug fortran/23379] New: compiler segfault with internal write
$ cat internal-write.f90 character(len=20), dimension(2) :: line(2) write (unit=line(1:2),fmt='(A/A)') '1', '2' end $ gdb ~/libexec/gcc/i686-pc-linux-gnu/4.1.0/f951 GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r internal-write.f90 Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.1.0/f951 internal-write.f90 MAIN__ Program received signal SIGSEGV, Segmentation fault. 0x0809c830 in gfc_conv_scalarized_array_ref (se=0xb334, ar=0x8689fe4) at ../../gcc-4.1/gcc/fortran/trans-array.c:1618 1618n = se->loop->order[0]; (gdb) p se->loop $1 = (struct gfc_loopinfo *) 0x0 (gdb) bt #0 0x0809c830 in gfc_conv_scalarized_array_ref (se=0xb334, ar=0x8689fe4) at ../../gcc-4.1/gcc/fortran/trans-array.c:1618 #1 0x0809d16d in gfc_conv_array_ref (se=0xb334, ar=0x8689fe4) at ../../gcc-4.1/gcc/fortran/trans-array.c:1662 #2 0x080a9578 in gfc_conv_expr (se=0xb334, expr=0x8689f88) at ../../gcc-4.1/gcc/fortran/trans-expr.c:420 #3 0x080b3bf8 in set_string (block=0xb394, postblock=0xb38c, var=Variable "var" is not available. ) at ../../gcc-4.1/gcc/fortran/trans-io.c:400 #4 0x080b4aed in build_dt (function=0x85d1f18, code=0x868a328) at ../../gcc-4.1/gcc/fortran/trans-io.c:1155 #5 0x080981ba in gfc_trans_code (code=0x868a328) at ../../gcc-4.1/gcc/fortran/trans.c:593 #6 0x080a751e in gfc_generate_function_code (ns=0x86894a8) at ../../gcc-4.1/gcc/fortran/trans-decl.c:2397 #7 0x08097834 in gfc_generate_code (ns=0x86894a8) at ../../gcc-4.1/gcc/fortran/trans.c:683 #8 0x0807da01 in gfc_parse_file () at ../../gcc-4.1/gcc/fortran/parse.c:2639 #9 0x080971e5 in gfc_be_parse_file (set_yydebug=0) at ../../gcc-4.1/gcc/fortran/f95-lang.c:256 #10 0x0836d250 in toplev_main (argc=2, argv=0xb5f4) at ../../gcc-4.1/gcc/toplev.c:971 #11 0x40076974 in __libc_start_main () from /lib/tls/libc.so.6 #12 0x0804adb1 in _start () at ../sysdeps/i386/elf/start.S:102 $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050811 (experimental) -- Summary: compiler segfault with internal write Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org BugsThisDependsOn: 23364 OtherBugsDependingO 19274 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23379
[Bug target/19274] temporary not eliminated in composite _mm_set_ps1
-- What|Removed |Added BugsThisDependsOn||23379 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19274
[Bug fortran/23379] compiler segfault with internal write
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-13 21:25 --- Sorry, wrong bug number. -- What|Removed |Added OtherBugsDependingO|19274 |19276 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23379
[Bug fortran/23379] compiler segfault with internal write
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 21:26 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-13 21:26:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23379
[Bug middle-end/23369] [4.0.x regression] Generates wrong code for funcptr comparison
--- Additional Comments From danglin at gcc dot gnu dot org 2005-08-13
21:42 ---
Bah, while this is probably going to happen for hppa-linux, it'snever going to
happen for hppa-hpux. GCC's treatment of functionpointers here is just
WRONG.There are a couple of issues. The most serious is the following:We have
the following code from __pthread_sigaction in the .i file: if (old ==
((__sighandler_t) 1) || old == ((__sighandler_t) 0) || old == ((__sighandler_t)
-1)) __sighandler[sig].old = (arch_sighandler_t)
act->__sigaction_handler.sa_handler;This is what the above turns into in the
tree dump filebug321785.c.t02.original: if ((void (*) (int)) old
- 2B > -4B){ __sighandler[sig].old = (void (*)
(int, struct sigcontext *)) act->__sigaction_handler.sa_handler;}I
don't believe that the transformation is valid. Also, it not validC to do
relational comparisons where one of the operands is a functionpointer. See
6.5.8 (2).do_compare_and_jump doesn't check code before canonicalizing
functionpointers. I think we need an assert in do_compare_and_jump to
catchinvalid function pointer comparisons.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
Re: [Bug middle-end/23369] [4.0.x regression] Generates wrong code for funcptr comparison
On Aug 13, 2005, at 5:42 PM, danglin at gcc dot gnu dot org wrote:
--- Additional Comments From danglin at gcc dot gnu dot org
2005-08-13 21:42 ---
Bah, while this is probably going to happen for hppa-linux, it'snever
going to happen for hppa-hpux. GCC's treatment of functionpointers
here is just WRONG.There are a couple of issues. The most serious is
the following:We have the following code from __pthread_sigaction in
the .i file: if (old == ((__sighandler_t) 1) || old ==
((__sighandler_t) 0) || old == ((__sighandler_t) -1))
__sighandler[sig].old = (arch_sighandler_t)
act->__sigaction_handler.sa_handler;This is what the above turns into
in the tree dump filebug321785.c.t02.original: if ((void
(*) (int)) old - 2B > -4B){
__sighandler[sig].old = (void (*) (int, struct sigcontext *))
act->__sigaction_handler.sa_handler;}I don't believe that
the transformation is valid.
hmm, looks like another build_range_test bug.
-- Pinski
[Bug middle-end/23369] [4.0.x regression] Generates wrong code for funcptr comparison
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-13
21:44 ---
Subject: Re: [4.0.x regression] Generates wrong code for funcptr comparison
On Aug 13, 2005, at 5:42 PM, danglin at gcc dot gnu dot org wrote:
>
> --- Additional Comments From danglin at gcc dot gnu dot org
> 2005-08-13 21:42 ---
> Bah, while this is probably going to happen for hppa-linux, it'snever
> going to happen for hppa-hpux. GCC's treatment of functionpointers
> here is just WRONG.There are a couple of issues. The most serious is
> the following:We have the following code from __pthread_sigaction in
> the .i file: if (old == ((__sighandler_t) 1) || old ==
> ((__sighandler_t) 0) || old == ((__sighandler_t) -1))
> __sighandler[sig].old = (arch_sighandler_t)
> act->__sigaction_handler.sa_handler;This is what the above turns into
> in the tree dump filebug321785.c.t02.original: if ((void
> (*) (int)) old - 2B > -4B){
> __sighandler[sig].old = (void (*) (int, struct sigcontext *))
> act->__sigaction_handler.sa_handler;}I don't believe that
> the transformation is valid.
hmm, looks like another build_range_test bug.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug middle-end/23369] [4.0.x regression] Generates wrong code for funcptr comparison
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-08-13 21:46 ---
Subject: Re: [4.0.x regression] Generates wrong code for funcptr comparison
> Bah, while this is probably going to happen for hppa-linux, it'snever going
> to happen for hppa-hpux. GCC's treatment of functionpointers here is just
> WRONG.There are a couple of issues. The most serious is the following:We
> have the following code from __pthread_sigaction in the .i file: if (old ==
> ((__sighandler_t) 1) || old == ((__sighandler_t) 0) || old ==
> ((__sighandler_t) -1)) __sighandler[sig].old = (arch_sighandler_t)
> act->__sigaction_handler.sa_handler;This is what the above turns into in the
> tree dump filebug321785.c.t02.original: if ((void (*) (int))
> old - 2B > -4B){ __sighandler[sig].old = (void
> (*) (int, struct sigcontext *)) act->__sigaction_handler.sa_handler;
> }I don't believe that the transformation is valid. Also, it not
> validC to do relational comparisons where one of the operands is a
> functionpointer. See 6.5.8 (2).do_compare_and_jump doesn't check code before
> canonicalizing functionpointer!
s.!
>I think we need an assert in do_compare_and_jump to catchinvalid function
> pointer comparisons.
Yuck. I used Konqueror to add this comment and it totally botched up
the white space ;(
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug fortran/23380] New: cpu_time intrinsic malfunction
The gfortran intrinsic function cpu_time(x) does not measure cpu time - it always produces 0.0 (zero) as the result. I am using "Native Windows build: download the latest installer (2005-08-06)" from http://gcc.gnu.org/wiki/GFortranBinaries, and am running under Windows XP Professional. -- Summary: cpu_time intrinsic malfunction Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edunlop at utvinternet dot ie CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23380
[Bug middle-end/23369] [4.0/4.1 regression] build_range_test generates wrong code for funcptr comparison
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13
21:52 ---
Confirmed,
A small testcase:
typedef void(*func_type) (void);
void g(void);
void f(func_type a)
{
if (a == (func_type) 1 || a == (func_type)0 || a == (func_type) -1)
g();
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail|4.0.1 |4.0.1 4.1.0
Last reconfirmed|-00-00 00:00:00 |2005-08-13 21:52:19
date||
Summary|[4.0.x regression] Generates|[4.0/4.1 regression]
|wrong code for funcptr |build_range_test generates
|comparison |wrong code for funcptr
||comparison
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
Re: bug in "pure virtual" templates ?
Dennis Lubert wrote: 37 template T get( void ) = 0; This looks like a legitimate bug. However, bugs should be reported into our bugzilla bug database. We don't track bugs mailed to the gcc-bugs address. See http://gcc.gnu.org/bugs.html -- Jim Wilson, GNU Tools Support, http://www.specifix.com
[Bug libfortran/23380] [mingw32] cpu_time intrinsic malfunction
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 21:55 --- This is a mingw32 specific issue. The implemention for mingw32 is not complete. intrinsics/cpu_time.c is where it is implemented, we only check for HAVE_GETRUSAGE and HAVE_TIMES. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-13 21:55:29 date|| Summary|cpu_time intrinsic |[mingw32] cpu_time intrinsic |malfunction |malfunction http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23380
[Bug libobjc/22492] [PATCH] Abort after @finally: libobjc passing exception value instead of exception.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 22:05 --- Woops I forgot to look at this that weekend, will look into it tomorrow. -- What|Removed |Added GCC build triplet|4.1.0 20050709 | GCC host triplet|i386-portbld-freebsd5.4 | GCC target triplet||i386-portbld-freebsd5.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22492
[Bug middle-end/23369] [4.0/4.1 regression] build_range_test generates wrong code for funcptr comparison
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-13 22:12 --- Subject: Re: [4.0/4.1 regression] build_range_test generates wrong code for funcptr comparison >|wrong code for funcptr |build_range_test generates >|comparison |wrong code for funcptr >||comparison build_range_test? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug middle-end/23369] [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 22:14 --- (In reply to comment #11) > build_range_test? woops, I mean build_range_check. -- What|Removed |Added Summary|[4.0/4.1 regression]|[4.0/4.1 regression] |build_range_test generates |build_range_check generates |wrong code for funcptr |wrong code for funcptr |comparison |comparison http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug objc/23381] New: [4.1 Regression] Next runtime objc exceptions are broken
Take the following test (which I am about to commit to the testsuite, it is
from PR 22492), we should
not abort:
#include
#include
#include
static int made_try = 0;
int
thrower_try_body()
{
made_try++;
return (0);
}
static int made_finally = 0;
int
finally_body()
{
made_finally++;
return (0);
}
int
thrower()
{
@try
{
thrower_try_body();
@throw [Object new];
}
@finally
{
finally_body();
}
return 0;
}
static int made_catch = 0;
int
main(int ac, char *av[])
{
@try
{
thrower();
}
@catch (id exc)
{
made_catch++;
[exc free];
}
if (made_try != 1)
abort ();
if (made_finally != 1)
abort ();
if (made_catch != 1)
abort ();
}
It worked in 4.0.0 20050113 so this is a regression.
--
Summary: [4.1 Regression] Next runtime objc exceptions are broken
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23381
[Bug objc/23381] [4.1 Regression] Next runtime objc exceptions are broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13
22:46 ---
This looks like a gimplifier bug.
In .orginal:
if (objc_exception_try_enter (&D.2385);
_setjmp ((void *) &D.2385.buf) != 0;)
{
{
struct objc_object * D.2383;
D.2383 = objc_exception_extract (&D.2385);
if (objc_exception_try_enter (&D.2385);
_setjmp ((void *) &D.2385.buf) != 0;)
{
D.2386 = objc_exception_extract (&D.2385);
}
else
{
{
struct objc_object * exc;
exc = D.2383;
made_catch++ ;
OBJ_TYPE_REF(objc_msgSend;SAVE_EXPR ->0) (SAVE_EXPR
,
_OBJC_SELECTOR_REFERENCES_1);
}
}
}
}
else
{
thrower ();
in .gimple:
objc_exception_try_enter (&D.2385);
D.2387 = _setjmp (&D.2385.buf);
if (D.2387 == 0)
{
thrower ();
Someone should test 4.0.x also.
--
What|Removed |Added
Known to fail||4.1.0
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23381
[Bug target/21833] simd tests fail
--- Additional Comments From tg42 at gmx dot de 2005-08-13 23:28 --- Again: this is NOT an alignment problem, as the structures ARE properly 16-byte aligned (cf. addresses from gdb output). What exactly cannot be reproduced: The code generated (movdqa?) or how the code acts? On which processor did you try to reproduce it? The failure occurs on various P3. Why was the code generation changed between 3.3 to 3.4? -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21833
[Bug target/21833] simd tests fail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 23:29 --- This works in 3.4.0 on i686-pc-linux-gnu and binutils version 2.15.90.0.3 20040415 so I still think this is not a GCC bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21833
[Bug objc/23381] [4.1 Regression] Next runtime objc exceptions are broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13 23:37 --- I think this is the same reason for the "objc.dg/try-catch-11.m execution test" failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23381
[Bug objc/23306] [4.1 Regression] [unit-at-a-time] objc exceptions (GNU runtime) don't work with unit-at-a-time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 01:05 --- The failures which this covers has changed since objc.dg/try-catch-8.m was moved. The failures now are: FAIL: objc/execute/exceptions/local-variables-1.m compilation, -O1 -fgnu-runtime FAIL: objc/execute/exceptions/local-variables-1.m compilation, -O2 -fgnu-runtime FAIL: objc/execute/exceptions/local-variables-1.m compilation, -O3 -fomit-frame-pointer -fgnu- runtime FAIL: objc/execute/exceptions/local-variables-1.m compilation, -O3 -g -fgnu-runtime FAIL: objc/execute/exceptions/local-variables-1.m compilation, -Os -fgnu-runtime Though the -O1 is a regression because unit-at-a-time was not on at -O1 for 4.0.0 so I am going to mark this as a regression. The way to fix this is generate the strings at the end of compilation and not at the end of file. -- What|Removed |Added Summary|[unit-at-a-time]|[4.1 Regression] [unit-at-a- |objc.dg/try-catch-8.m fails |time] objc exceptions (GNU |to link/compile with the gnu|runtime) don't work with |runtime |unit-at-a-time Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23306
[Bug libfortran/23380] [mingw32] cpu_time intrinsic malfunction
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-14 01:33 --- (In reply to comment #1) > This is a mingw32 specific issue. > > The implemention for mingw32 is not complete. > intrinsics/cpu_time.c is where it is implemented, > we only check for HAVE_GETRUSAGE and HAVE_TIMES. This isn't exactly correct. If neither HAVE_GETRUSAGE nor HAVE_TIMES is defined, cpu_time can and does return -1. It appears that MingW claims to have a HAVE_TIMES, when in fact it is broken. This is not a gfortran problem. Please contact the MingW developers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23380
[Bug libobjc/22492] [PATCH] Abort after @finally: libobjc passing exception value instead of exception.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14 02:02 --- Subject: Bug 22492 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-14 02:01:52 Modified files: libobjc: ChangeLog exception.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/objc/execute/exceptions: finally-1.m Log message: libobjc/ChangeLog: 2005-08-13 Marcin Koziej <[EMAIL PROTECTED]> Andrew Pinski <[EMAIL PROTECTED]> PR libobjc/22492 * exception.c (PERSONALITY_FUNCTION): Fix the PC with finally. testsuite/ChangeLog: 2005-08-13 Marcin Koziej <[EMAIL PROTECTED]> Andrew Pinski <[EMAIL PROTECTED]> PR libobjc/22492 * execute/exceptions/finally-1.m: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/ChangeLog.diff?cvsroot=gcc&r1=1.170&r2=1.171 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/exception.c.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5918&r2=1.5919 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/objc/execute/exceptions/finally-1.m.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22492
[Bug libobjc/22492] [PATCH] Abort after @finally: libobjc passing exception value instead of exception.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 02:03 --- I commited your fix with slight changes, two style changes and the change of the type of return_object to void* to aviod a warning. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22492
[Bug objc/23381] [4.1 Regression] Next runtime objc exceptions are broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 02:04 --- The failures are: FAIL: objc/execute/exceptions/finally-1.m execution, -O0 -fnext-runtime FAIL: objc/execute/exceptions/finally-1.m execution, -O1 -fnext-runtime FAIL: objc/execute/exceptions/finally-1.m execution, -O2 -fnext-runtime FAIL: objc/execute/exceptions/finally-1.m execution, -O3 -fomit-frame-pointer -fnext-runtime FAIL: objc/execute/exceptions/finally-1.m execution, -O3 -g -fnext-runtime FAIL: objc/execute/exceptions/finally-1.m execution, -Os -fnext-runtime -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23381
[Bug middle-end/21076] [4.1 Regression] ACATs ICE cxh1001 at tree-vrp.c:124 (fold bug)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 02:20 --- No longer working on this. -- What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21076
[Bug testsuite/23348] objc testsuite should run over both GNU and NeXT runtimes if supported
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 02:42 --- This is basically fixed. Some of the tests in objc.dg/ can be moved over to objc/compile / objc/ execute. I already moved over some of them, just the exceptions one and one other one. Closing as fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23348
[Bug libobjc/23108] alignment bug in libobjc/archive.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 03:16 --- Hmm on powerpc-darwin we get: a = 1, b = 3 Which is still wrong. -- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2005-08-14 03:16:31 date|| Version|unknown |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23108
[Bug tree-optimization/21591] not vectorizing a loop with access to structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 03:20 --- Hmm, the aliasing info is good: # VUSE ; D.1618_13 = b_5->a1[i_66]; # VUSE ; D.1619_15 = c_7->a1[i_66]; D.1620_16 = D.1618_13 + D.1619_15; # HEAP.45_143 = V_MAY_DEF ; a_3->a1[i_66] = D.1620_16; So someone is not looking at that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug tree-optimization/23382] New: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP)
Take the following example from PR 21591:
struct a
{
int length;
int a1[256];
};
struct a *malloc1(__SIZE_TYPE__) __attribute__((malloc));
void free(void*);
void f(void)
{
struct a *a = malloc1(sizeof(struct a));
struct a *b = malloc1(sizeof(struct a));
struct a *c = malloc1(sizeof(struct a));
int i;
for (i = 0; i < 256; i++) {
b->a1[i] = i;
c->a1[i] = i;
}
for (i = 0; i < 256; i++) {
a->a1[i] = b->a1[i] + c->a1[i];
}
free(a);
free(b);
free(c);
}
In .alias1:
i.0_18 = i_1;
# HEAP.7_46 = V_MAY_DEF ;
b_6->a1[i.0_18] = i_1;
i.0_19 = i_1;
# HEAP.8_47 = V_MAY_DEF ;
c_8->a1[i.0_19] = i_1;
i_20 = i_1 + 1;
In .alias2:
# HEAP.19_14 = V_MAY_DEF ;
b_5->a1[i_65] = i_65;
# HEAP.20_73 = V_MAY_DEF ;
c_7->a1[i_65] = i_65;
i_20 = i_65 + 1;
---
I don't know how much harm in compile time does this hurt in normal code but we
then keep on adding
them to clobbered variables:
# HEAP.6_27 = V_MAY_DEF ;
# HEAP.7_28 = V_MAY_DEF ;
# HEAP.8_29 = V_MAY_DEF ;
# HEAP.18_6 = V_MAY_DEF ;
# HEAP.19_8 = V_MAY_DEF ;
# HEAP.20_1 = V_MAY_DEF ;
a_3 = malloc1 (1028);
--
Summary: [4.1 Regression] tree-ssa-alias creates a new virtual
variable for malloc each time may_alias is run (HEAP)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: memory-hog, compile-time-hog
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: dberlin at gcc dot gnu dot org,dnovillo at gcc dot gnu
dot org,gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug tree-optimization/23382] [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 03:38 --- I think this is the issue I am hitting for PR 15855. -- What|Removed |Added OtherBugsDependingO||15855 nThis|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug tree-optimization/23382] [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP)
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-14 03:40 --- Subject: Re: New: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP) On Sun, 2005-08-14 at 03:36 +, pinskia at gcc dot gnu dot org wrote: > > In .alias1: > i.0_18 = i_1; > # HEAP.7_46 = V_MAY_DEF ; > b_6->a1[i.0_18] = i_1; > i.0_19 = i_1; > # HEAP.8_47 = V_MAY_DEF ; > c_8->a1[i.0_19] = i_1; > i_20 = i_1 + 1; > > In .alias2: > # HEAP.19_14 = V_MAY_DEF ; > b_5->a1[i_65] = i_65; > # HEAP.20_73 = V_MAY_DEF ; > c_7->a1[i_65] = i_65; > i_20 = i_65 + 1; Uh, so? This is because we recompute all the alias info, which means we really recompute the alias info. > > --- > I don't know how much harm in compile time does this hurt in normal code but > we then keep on adding > them to clobbered variables: > # HEAP.6_27 = V_MAY_DEF ; > # HEAP.7_28 = V_MAY_DEF ; > # HEAP.8_29 = V_MAY_DEF ; > # HEAP.18_6 = V_MAY_DEF ; > # HEAP.19_8 = V_MAY_DEF ; > # HEAP.20_1 = V_MAY_DEF ; > a_3 = malloc1 (1028); This is wrong. malloc functions don't *clobber* anything, AFAIK. --Dan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
Re: [Bug tree-optimization/23382] [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP)
On Aug 13, 2005, at 11:40 PM, dberlin at dberlin dot org wrote: Uh, so? We keep the virtual variable around even in the clobbered variables. Add a function call to an different function like say f so it does not get GC'd and we keep on adding more and more V_MAY_DEFs: # HEAP.6_36 = V_MAY_DEF ; # HEAP.7_37 = V_MAY_DEF ; # HEAP.8_38 = V_MAY_DEF ; # HEAP.18_78 = V_MAY_DEF ; # HEAP.19_79 = V_MAY_DEF ; # HEAP.20_80 = V_MAY_DEF ; g (); -- Pinski
[Bug tree-optimization/23382] [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP)
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-14 03:48 --- Subject: Re: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP) On Aug 13, 2005, at 11:40 PM, dberlin at dberlin dot org wrote: > Uh, so? We keep the virtual variable around even in the clobbered variables. Add a function call to an different function like say f so it does not get GC'd and we keep on adding more and more V_MAY_DEFs: # HEAP.6_36 = V_MAY_DEF ; # HEAP.7_37 = V_MAY_DEF ; # HEAP.8_38 = V_MAY_DEF ; # HEAP.18_78 = V_MAY_DEF ; # HEAP.19_79 = V_MAY_DEF ; # HEAP.20_80 = V_MAY_DEF ; g (); -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug tree-optimization/23382] [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP)
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-14 03:48 --- Subject: Re: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP) On Sun, 2005-08-14 at 03:38 +, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 > 03:38 --- > I think this is the issue I am hitting for PR 15855. Do you have *anything* to back this up? There are still no timings, dumps, or anything attached to 15855 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug tree-optimization/23382] [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP)
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-14 04:04 --- Subject: Re: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP) On Sun, 2005-08-14 at 03:48 +, pinskia at physics dot uc dot edu wrote: > --- Additional Comments From pinskia at physics dot uc dot edu > 2005-08-14 03:48 --- > Subject: Re: [4.1 Regression] tree-ssa-alias creates a new virtual variable > for malloc each time may_alias is run (HEAP) > > > On Aug 13, 2005, at 11:40 PM, dberlin at dberlin dot org wrote: > > > Uh, so? > We keep the virtual variable around even in the clobbered variables. I thought the call clobbered list was recomputed at the same time, which should alleviate this problem. If not, *that* is buggy. Recreating the heap variables is *not* a bug. Redoing alias information is sometihng we may not want to do, but the fact that it requires us to recreate heap variables is a fact of life. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug tree-optimization/23382] [4.1 Regression] Don't remove the old HEAP virtual variables in clobbered
-- What|Removed |Added Summary|[4.1 Regression] tree-ssa- |[4.1 Regression] Don't |alias creates a new virtual |remove the old HEAP virtual |variable for malloc each|variables in clobbered |time may_alias is run (HEAP)| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug tree-optimization/23382] [4.1 Regression] Does not remove the old HEAP virtual variables in clobbered
-- What|Removed |Added Summary|[4.1 Regression] Don't |[4.1 Regression] Does not |remove the old HEAP virtual |remove the old HEAP virtual |variables in clobbered |variables in clobbered http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug c++/23383] New: builtin array operator new is not marked with malloc attribute
Testcase:
int f(void)
{
int t;
int *a = new int[1024];
int *b = new int[1024];
*a = 1;
*b = 2;
t = *a;
delete a;
delete b;
return t;
}
the return is not turned into 1 but still have "return t" in the final_cleanup.
--
Summary: builtin array operator new is not marked with malloc
attribute
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug tree-optimization/23119] gcc.dg/vect/vect-105.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14 06:13 --- Subject: Bug 23119 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-14 06:13:30 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg/vect: vect-105.c Log message: PR tree-optimization/23119 * gcc.dg/vect/vect-105.c: Add xfail for no_align targets. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5919&r2=1.5920 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-105.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23119
[Bug tree-optimization/23384] New: Clobber list should be flow sensitive
Take the following code:
struct f
{
int i;
int j;
};
void g(void);
void i(struct f*);
int kk(void)
{
struct f a;
int j;
a.i = 1;
a.j =2 ;
g();
j = a.i;
i(&a);
return j;
}
---
j should be changed to 1 as the address of a is not escape until after the call
to i so g should not get a
call clobbered for the SFT's of a.
--
Summary: Clobber list should be flow sensitive
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384
[Bug tree-optimization/23119] gcc.dg/vect/vect-105.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 06:17 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23119
[Bug tree-optimization/23320] [4.1 Regression] ICE in in base_addr_differ_p, at tree-data-ref.c:430
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14 06:28 --- Subject: Bug 23320 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-14 06:28:03 Modified files: gcc: ChangeLog tree-data-ref.c Log message: PR tree-optimization/23320 * tree-data-ref.c (base_addr_differ_p): Add comment. Check data-refs' types instead of base object nullness. Add check for pointer type data-refs before first location comparison. Remove assert. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9725&r2=2.9726 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-data-ref.c.diff?cvsroot=gcc&r1=2.36&r2=2.37 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23320
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2005-08-14 06:45 ---
Looking at it again, I found an even worse regression with respect to g++ 3.4.
Consider this testcase:
struct A { int a[1000]; }
A f();
void g(A);
void h() { g(f()); }
Ideally, h will allocate a stack frame for g and ask f to directly dump its
result in it. No temporary nor memcpy will be used at all. g++ 3.4 behaves this
way.
g++ 4.0 however will first allocate some space for the result of f, then call f
and copy its result in another temporary, and finally it will allocate the stack
frame for g and copy the temporary in it. Two temporaries and two memcpys are
needed for g++ 4.0.
So the same issue arises when returning a result by value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
