--- 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:
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 {
in
--- 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/bugzil
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 (
--- 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
--- 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 informat
--- 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
--- 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
--- 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 m
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 compi
--- 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
--- 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
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-
--- 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
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 t
--- 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 So
--- 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
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-
--- 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
--- 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://gc
--- 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
--
What|Removed |Added
CC||fang at csl dot cornell dot
||edu
http://gcc.gnu.org/bugzilla/s
--- 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
--- 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 fil
--- 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
--
--- 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 s
--- 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
--
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?i
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 co
--- 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
---
--- 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
--
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Component|pending
--- 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
--- 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
--- 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
--- 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.)
###
--- 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|
--- 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
--- 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_ad
--
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
--- 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:
--- 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/s
--- 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=2
--- 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_b
--
What|Removed |Added
OtherBugsDependingO||23379
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23364
$ 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,
--
What|Removed |Added
BugsThisDependsOn||23379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19274
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-13
21:25 ---
Sorry, wrong bug number.
--
What|Removed |Added
OtherBugsDependingO|19274
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-13
21:26 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- 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
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 functionpointe
--- 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 g
--- 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 treatmen
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.
--
--- 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|R
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.
--- 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|Re
--- 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
--
--- 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
>|c
--- 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
---
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()
{
--- 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.238
--- 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 pr
--- 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
--- 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
--- 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
--- 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_T
--- 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/te
--- 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
-
--- 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
--- 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
--- 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.
--- 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
G
--- 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.
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(
--- 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
OtherBugsDependin
--- 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 o
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_
--- 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 k
--- 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 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:
--
What|Removed |Added
Summary|[4.1 Regression] tree-ssa- |[4.1 Regression] Don't
|alias creates a new virtual |remove the old HEAP virtual
--
What|Removed |Added
Summary|[4.1 Regression] Don't |[4.1 Regression] Does not
|remove the old HEAP virtual |remove the old HEAP virtual
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
--- 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.
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
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
06:17 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- 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 messa
--- 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
89 matches
Mail list logo
