--- Additional Comments From bjoern dot m dot haase at web dot de
2005-07-27 06:18 ---
What's the plan? I'd like to see it in CVS. The patch I posted on gcc-patches
in may 05 is already approved (it's a straight-forward change) by Richard
Henderson.
Unfortunately, I don't have
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-07-27 06:21 ---
Sorry: Let me correct myself.
I just see that You have been refering to an earlier revision of the patch that
I had posted on this bugzilla entry. This is not the current state of the
patch. The
--- Additional Comments From wouter at grep dot be 2005-07-27 06:48 ---
Error does not occur with GCC 3.4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23080
--- Additional Comments From wouter at grep dot be 2005-07-27 07:50 ---
Error does not occur with g++ 3.4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23078
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27
08:30 ---
Subject: Bug 22503
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-27 08:30:47
Modified files:
gcc/fortran: ChangeLog resolve.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27
08:39 ---
Subject: Bug 22503
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-27 08:39:46
Modified files:
gcc/fortran:
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-27
08:41 ---
Fixed on mainline and 4.0 branch (for 4.0.2).
--
What|Removed |Added
URL|
--- Additional Comments From giovannibajo at libero dot it 2005-07-27
08:54 ---
Bjorn, do you have a copyright assignment filed with the FSF?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
--- Additional Comments From giovannibajo at libero dot it 2005-07-27
08:56 ---
This is the patch RTH already approved for head and 4.0:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01899.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-27
08:56 ---
The fix for PR 22591 fixed a miscompilation of std::list::swap.
Could you please try whether this also fixes this problem?
--
What|Removed |Added
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-07-27 09:01 ---
Subject: Re: [4.1 Regression] wrong code for casts and scev
dberlin at dberlin dot org wrote:
A sequence of unsigned char 1, 2, ..., 255 has to be converted to
signed char that would wrap
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-07-27 09:04 ---
Subject: Re: [4.1 Regression] wrong code for casts and scev
dberlin at dberlin dot org wrote:
I don't think it is possible to properly convert these ivs without
knowing an approximation of
--- Additional Comments From micis at gmx dot de 2005-07-27 09:36 ---
This loop make gcc bootstrap fail if you use -ftree-vectorize
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23079
--- Additional Comments From dorit at il dot ibm dot com 2005-07-27 10:11
---
patch:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01776.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23083
--- Additional Comments From ramana dot radhakrishnan at codito dot com
2005-07-27 10:19 ---
(In reply to comment #11)
No, that'd be wrong. The correct status for a bug with a pending patch is
ASSIGNED.
Can the target milestone be changed ? I see this has been approved by Roger
--- Additional Comments From ramana dot radhakrishnan at codito dot com
2005-07-27 10:20 ---
(In reply to comment #11)
No that's wrong. WAITING means waiting feedback *from submitter*.
This has been approved at :
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01918.html
Can this be
--- Additional Comments From dorit at il dot ibm dot com 2005-07-27 10:35
---
patch:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01776.html
(I should have referred to it as a patch for PR23073 rather than the duplicate
PR23083)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at il dot ibm dot com
|dot org |
URL|
--- Additional Comments From dorit at il dot ibm dot com 2005-07-27 10:38
---
This is triggered by tree-ifcvt (which is enabled by -ftree-vectorize)
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27
10:51 ---
Subject: Bug 22574
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-27 10:51:03
Modified files:
gcc: ChangeLog cgraph.c
Log message:
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-27
11:50 ---
My patch was approved: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00286.html
I had hoped some ARM person would act on one of my requests to test the patch
on ARM, but since this hasn't happened, I am
Subroutine My(n1)
Dimension myArray(n1)
Save ! or 'Save myArray'
Call xxx(myArray)
Return
End
gives
internal compiler error: in
--- Additional Comments From redi at gcc dot gnu dot org 2005-07-27 12:22
---
gcc version 4.0.2 20050727 (prerelease) still shows the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22513
--- Additional Comments From Jean-pierre dot vial at wanadoo dot fr
2005-07-27 12:23 ---
the bug no longer shows after complete recompilation of gcc-4.1 20050723
--
What|Removed |Added
--- Additional Comments From christian dot joensson at gmail dot com
2005-07-27 12:25 ---
Same problem on the 3.4 branch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23072
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-27
12:25 ---
Did you do a full bootstrap?
A library function was miscompiled, so a just using a new compiler
isn't enough.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22513
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-07-27
12:46 ---
It'll come as no surprise that this is yet another bug related
to the infamous RTX_UNCHANGING_P. A reduced C testcase is:
extern void abort (void);
void f (const char *x)
{
if (x[0] +
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-27
12:50 ---
This is a duplicate of PR 21034 and already fixed for gcc 4.0.2.
*** This bug has been marked as a duplicate of 21034 ***
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-27
12:50 ---
*** Bug 23091 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From redi at gcc dot gnu dot org 2005-07-27 12:52
---
No, sorry I didn't. Bootstrapping now...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22513
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-27
12:53 ---
Well, not qiote a duplicate: Save myArray still ICE's.
Reopening.
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-27
12:59 ---
Confirmed. The following still ICE's (4.0 branch and mainline)
==
Subroutine My(n1)
Dimension myArray(n1)
Save myArray
Call xxx(myArray)
End
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-27
13:00 ---
(In reply to comment #7)
Subject: Re: interface body has incorrect scope
Paul, do you have any idea what find_special could be intended for? It seems
obvious that it does the wrong thing in the case
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-07-27 13:21 ---
Subject: Re: interface body has incorrect scope
Quoting erik dot edelmann at iki dot fi [EMAIL PROTECTED]:
I've taken a look at another compiler (i.e. g95). The difference is in
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27
13:24 ---
Subject: Bug 20773
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-27 13:23:35
Modified files:
gcc: ChangeLog tree-ssa-loop-ch.c
Log
--- Additional Comments From redi at gcc dot gnu dot org 2005-07-27 13:24
---
*** Bug 22513 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From redi at gcc dot gnu dot org 2005-07-27 13:24
---
Testcase succeeds after a clean bootstrap. Hoorah! Thanks.
Marking as a duplicate of bug 22591
*** This bug has been marked as a duplicate of 22591 ***
--
What|Removed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27
13:27 ---
Subject: Bug 22325
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-27 13:26:56
Modified files:
gcc: ChangeLog tree-flow.h
--- Additional Comments From matz at suse dot de 2005-07-27 13:46 ---
Because these symbols indeed are not defined anywhere. On linux this happens
to work, but on darwin you need to link against something which provides them.
So you would need to create a library which
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
13:56 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 20656 depends on bug 22325, which changed state.
Bug 22325 Summary: missed optimization in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22325
What|Old Value |New Value
--
Bug 22366 depends on bug 22325, which changed state.
Bug 22325 Summary: missed optimization in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22325
What|Old Value |New Value
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27
14:04 ---
Subject: Bug 22348
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-27 14:04:17
Modified files:
gcc: ChangeLog tree-ssa-loop-niter.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
14:06 ---
Fixed. I am linking this to PR 17662 for the testsuite part.
--
What|Removed |Added
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-07-27
14:07 ---
Not closing the PR, the workaround in number_of_iterations_cond just masks the
problem.
--
What|Removed |Added
--- Additional Comments From dorit at il dot ibm dot com 2005-07-27 14:27
---
This patch should fix it:
Index: tree-vectorizer.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v
retrieving revision 2.105
diff -c -3 -p
--- Additional Comments From Simon dot Finn at reify dot co dot uk
2005-07-27 15:04 ---
Thanks everyone. I'm really impressed by the effectiveness of the collaborative
debugging process.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
$ cat minval.f90
program main
real, dimension(2) :: a
logical :: m
a = (/ 1.0, 2.0 /)
m = .true.
print *,minval(a, m)
end program main
$ gfortran minval.f90
minval.f90: In function 'MAIN__':
minval.f90:6: internal compiler error: in gfc_conv_intrinsic_minmaxval, at
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27
15:19 ---
Subject: Bug 23073
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-27 15:19:45
Modified files:
gcc: ChangeLog tree-vect-analyze.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
15:20 ---
Confirmed, not a regression.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-27 15:29
---
Related to string instructions.
--
What|Removed |Added
Status|UNCONFIRMED
I have found an apparent bug in gcc 3.4.4 under Cygwin. The attached test case
(and the code it's derived from) works as expected with Cygwin gcc 3.3.3 with
the exact same Cygwin install except the compiler packages. It also works fine
with various versions of gcc on other platforms, including
--- Additional Comments From john dot gravley at cctechnol dot com
2005-07-27 15:43 ---
Created an attachment (id=9372)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9372action=view)
results of cygcheck
Cygwin bug reporting requests this file. It is included in case it useful
--- Additional Comments From john dot gravley at cctechnol dot com
2005-07-27 15:45 ---
Created an attachment (id=9373)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9373action=view)
This is the set of test case files.
This set of files exhibits the apparent bug. Makefiles are
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-27 15:48
---
The AIX and PowerOpen ABIs specify doubleword alignment for long long ints in
32-bit mode and FSF GCC always has implemented this for all AIX-derived ABIs.
--
// This function can be optimized to just *p = *q = 1; at tree level:
void foo (int *p, int *q)
{
*p = 1;
*q = 1;
if (*p != 1)
link_error ();
}
--
Summary: store ccp misses an optimization
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--
What|Removed |Added
CC||dalej at apple dot com
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
15:56 ---
Confirmed. A weird case but still should be able to optimizated very easily.
--
What|Removed |Added
Danny,
I don't get the auto_import message when I build the test case.
I'm also confused as to why reordering the calls makes the test case
work if the problem is as you describe it.
John
Danny Smith wrote:
I have found an apparent bug in gcc 3.4.4 under Cygwin. The attached test case
--
What|Removed |Added
Component|c++ |target
GCC target triplet||i686-pc-cygwin
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-27
16:04 ---
store CCP returns UNKNOWN_VAL as soon as it sees the TMT, even though the RHS is
completely constant, and even after we set the value of the TMT's to constant.
Even if you change the call to link_error to
--- Additional Comments From danglin at gcc dot gnu dot org 2005-07-27
16:04 ---
Looking at gcc-testresults, this test only failed for a brief period
in Feb. 2005.
--
What|Removed |Added
Hi,
GNU F95 version 4.1.0 20050727 (experimental) (x86_64-unknown-linux-gnu) gives
an ICE when compiling the following ugly but valid code (reduced from galgel):
function foo(n)
real*8 foo
integer ix, n, next
real*8
--- Additional Comments From law at redhat dot com 2005-07-27 16:21 ---
Fixed by the attached patch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-27
16:21 ---
interfaces. This brings me to a question: what is a named interface? I
This is a nameless interface, isn't it?
module snafu
interface
subroutine really_snafu (foo)
integer, intent
--- Additional Comments From schlie at comcast dot net 2005-07-27 16:22
---
(In reply to comment #4)
Oh, I agree completely that making string literals const
(as they are in C++) would make more sense. The reason they
aren't defined that way in C is that by the time const was
added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27
16:28 ---
Subject: Bug 17808
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-27 16:28:38
Modified files:
gcc: ChangeLog sched-deps.c sched-ebb.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
16:29 ---
Confirmed, a regression from 4.0.x.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From mki at maconomy dot dk 2005-07-27 16:30
---
Hi,
Dave, you mentioned that it needs debugging on a system that can reproduce it.
Is there anything I can do to debug it? It seems like you know what to look
for... Something like building gcc with -save-temps,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
16:31 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
CC||gerrit at gcc dot gnu dot
||org
--- Additional Comments From ja2morri at csclub dot uwaterloo dot ca
2005-07-27 16:34 ---
Subject: Re: [4.1 Regression] vrp produces
wrong code
Jeffrey A Law [EMAIL PROTECTED] writes:
The underlying problem here is the code to meet a VR_ANTI_RANGE and
a VR_RANGE does not
See PR 22348 for the full analysis of this bug.
--
Summary: Wrong folding for FLOOR_MOD_EXPR
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo:
--
What|Removed |Added
OtherBugsDependingO||23096
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22348
--
What|Removed |Added
BugsThisDependsOn|22348 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
16:37 ---
The work around is in but the new problem should have been filed as a new bug
which I did as PR
23096.
The testcase is now fixed.
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||22348
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
--
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
16:38 ---
From comment #7 of PR 22348:
extract_muldiv(51 - 7, 3, FLOOR_MOD_EXPR) returns incorrectly 0.
The reason is that 51 - 7 is replaced with 51 + ~6, and both 51 and ~6 are
divisible by 3, so the result
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
16:40 ---
Actually this was only fixed on the mainline, it also fails in 4.0.0 branch too.
--
What|Removed |Added
--
What|Removed |Added
Status|REOPENED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22348
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
16:45 ---
Fixed on the mainline, I think the 4.0 branch's bug is slightly different also.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
16:51 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From law at redhat dot com 2005-07-27 16:55 ---
Subject: Re: [4.1 Regression] vrp produces
wrong code
On Wed, 2005-07-27 at 16:34 +, ja2morri at csclub dot uwaterloo dot
ca wrote:
--- Additional Comments From ja2morri at csclub dot uwaterloo dot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
17:06 ---
Another testcase for extra load at the tree level:
int g (int* g1, int* g2)
{
int i;
g2[0] = 2;
g1[0] = 3;
return g2[0];
}
Note the test in comment #1 has been fixed already.
--
--- Additional Comments From law at redhat dot com 2005-07-27 17:13 ---
It's highly unlikely threading is going to be able to completely eliminate the
test for bytes == 0.
The fundamental problem is the threader has no way of knowing that the loop exit
test (toread != 0) can never be
[EMAIL PROTECTED] test_blas]$ ~/GREG/bin_gcc/bin/gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc4/configure --prefix=/home/casper/GREG/bin_gcc --
mandir=/home/casper/GREG/objdir/share/man --enable-
languages=c,c++,f95,java,objc --enable-shared
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-07-27 17:20 ---
Subject: Re: [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
Dave, you mentioned that it needs debugging on a system that can reproduce
it.
I was just able to reproduce it
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
17:30 ---
Fixed already.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-07-27
17:31 ---
This seems to be caused by:
2004-02-15 Roger Sayle [EMAIL PROTECTED]
Backport from mainline:
2004-02-07 Roger Sayle [EMAIL PROTECTED]
PR middle-end/13696
*
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
17:31 ---
This works with 4.1.0 20050727.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23097
--- Additional Comments From tromey at gcc dot gnu dot org 2005-07-27
17:39 ---
This is a request for Classpath.
--
What|Removed |Added
Component|libgcj
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-07-27 18:30 ---
Bjorn, do you have a copyright assignment filed with the FSF?
Yes. It took quite a while but since a couple of weeks the paperwork is
finished.
--
Take the following program:
int g (float* g1)
{
*g1 = 0;
}
Running it on ppc-darwin on the mainline (with -static), we get:
LC0:
.long 0
.text
.align 2
.globl _g
_g:
lis r2,ha16(LC0)
lfs f0,lo16(LC0)(r2)
stfs f0,0(r3)
blr
On
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
18:49 ---
Actually I take back x86 is not a regression. It is a regression from 3.2.3
--
What|Removed |Added
--
What|Removed |Added
GCC target triplet|powerpc-darwin |powerpc-darwin, i?86-*-*
Target Milestone|--- |4.0.2
The following test case:
struct Base {
int x;
};
template typename T
struct A {
static const int N = sizeof(static_castBase*(T()));
};
struct Derived : Base {
ADerived* a;
};
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
19:03 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-27 19:11
---
On PowerPC this is because we now are forcing all FP constants to memory. The
only constant for which this is interesting is zero, and only if one is storing
to memory. XLC produces the same code as GCC
1 - 100 of 170 matches
Mail list logo
