Executing on host: /abuild/aj/gcc/gcc/xgcc -B/abuild/aj/gcc/gcc/
/aj-cvs/gcc-svn/trunk/gcc/testsuite/gcc.dg/vect/vect
-46.c -O2 -ftree-vectorize -maltivec -ftree-vectorizer-verbose=4
-fdump-tree-vect-stats -fno-show-column -lm -m6
4 -o ./vect-46.exe(timeout = 300)
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-10 09:34 ---
Confirmed (rtl checking enabled only).
/abuild/rguenther/gcc-obj/gcc/cc1 -fpreprocessed vect-46.i -quiet -dumpbase
vect-46.c -maltivec -m64 -auxbase-strip vect-46.s -O2 -version -ftree-vectorize
--- Comment #3 from jakub at gcc dot gnu dot org 2005-11-10 09:49 ---
glibc can be configured without tls support when using --without-tls configure
switch. I think glibc 2.3.2 defaulted to --without-tls, so you had to
explicitly request --with-tls support.
Does even a trivial
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-10 09:51 ---
Testcase:
void bar (float *pa, float *pb, float *pc)
{
int i;
for (i = 0; i 256; i++)
{
}
}
main1 (int n)
{
int i;
float a[256] __attribute__ ((__aligned__(16))); float b[256] __attribute__
--- Comment #7 from pcarlini at suse dot de 2005-11-10 09:59 ---
I'm marking this as a 4.1 Regression: certainly it is. If people can figure a
way to workaround it at the library level, I'm ok with that.
--
pcarlini at suse dot de changed:
What|Removed
function cannot be recursive.
! Contributed by Joost VandeVondele [EMAIL PROTECTED]
! !
! ! Modified 20051110 to check that regressions PR24655 and PR24755
! ! are fixed. Thanks to [EMAIL PROTECTED] and [EMAIL PROTECTED] for
! ! the tests.
! !
! INTEGER :: i, st1, st2, st3, lambda, n
REAL :: x, z
function cannot be recursive.
! Contributed by Joost VandeVondele [EMAIL PROTECTED]
! !
! ! Modified 20051110 to check that regressions PR24655 and PR24755
! ! are fixed. Thanks to [EMAIL PROTECTED] and [EMAIL PROTECTED] for
! ! the tests.
! !
! INTEGER :: i, st1, st2, st3, lambda, n
REAL :: x, z
--- Comment #7 from ben at decadentplace dot org dot uk 2005-11-10 11:33
---
I have no interest in constructing buffer overflow exploits, but if someone
were to construct shell-code in a filename it should be possible to use it
against a privileged user of libgcj that reads
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-11-10 11:33
---
Subject: Bug 23995
Author: ebotcazou
Date: Thu Nov 10 11:32:56 2005
New Revision: 106731
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106731
Log:
PR ada/23995
* trans.c (call_to_gnu):
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-11-10 11:33
---
Subject: Bug 23995
Author: ebotcazou
Date: Thu Nov 10 11:33:55 2005
New Revision: 106732
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106732
Log:
PR ada/23995
* trans.c (call_to_gnu):
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-11-10 11:38
---
See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00701.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
The following program produces incorrect output when compiled with the
current gfortran from the gomp branch, but correct output when run with
current mainline gfortran:
program test
implicit none
character(len=80) :: filename
logical :: file_present
filename=testfile
--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-11-10 12:19
---
Some more comments:
- the problem was already present before the 20051109 merge; I just
waited for the merge to see if it would go away
- I'm seeing the same problem on x86_64
--
--- Comment #12 from jakub at gcc dot gnu dot org 2005-11-10 13:14 ---
Subject: Bug 4372
Author: jakub
Date: Thu Nov 10 13:14:05 2005
New Revision: 106735
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106735
Log:
PR other/4372
* varasm.c (assemble_alias): Use
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-10 13:48 ---
(In reply to comment #2)
they appear after 40.flow2 for some reason.
The some reason is that they are prologue/epologue code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from j3p0uk at hotmail dot com 2005-11-10 13:49 ---
I was not intending to show a correct fix for the problem, my simple test
program was merely intended to show that given sufficient distance between 2
pointers the result from ptr_a - ptr_b can be incorrect. I am not
--- Comment #7 from j3p0uk at hotmail dot com 2005-11-10 13:54 ---
Created an attachment (id=10201)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10201action=view)
More correct test program
Here is a test program designed to show the problem more clearly. When run the
pointer
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-10 13:58 ---
If pointer1 and pointer2 are not in the same array (+-1 element), the behavior
is undefined so what GCC is doing for your case is fine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from j3p0uk at hotmail dot com 2005-11-10 14:02 ---
Sorry - I don't mean to pester you, I would just like to clarify your final
point.
What you are saying is that:
Pointer arithmetic is only valid on elements of the same array that are
adjacent, and that any other uses
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-10 14:09
---
(In reply to comment #9)
What you are saying is that:
Pointer arithmetic is only valid on elements of the same array that are
adjacent, and that any other uses of pointer arithmetic produces undefined
--- Comment #7 from joern dot rennecke at st dot com 2005-11-10 14:11
---
Subject: Re: -d option changes generated code
rakdver at gcc dot gnu dot org wrote:
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-11-09 22:36
---
Yes, this is indeed the case. I am testing
--- Comment #3 from pbrook at gcc dot gnu dot org 2005-11-10 14:16 ---
Yes. You should use binutils HEAD for csl-arm-branch. Ther
binutils-csl-arm-branch is obsolete.
We'll probably add a configure check before merging this code to mainline, but
that's not a priority for csl-arm-branch.
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-10 14:17 ---
Subject: Re: -d option changes generated code
This is a multi-part message in MIME format.
--070507020407080301090707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
--- Comment #2 from machata at post dot cz 2005-11-10 14:21 ---
Created an attachment (id=10202)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10202action=view)
Patch against gcc/cp/decl.c, and a testcase
This is rather straightforward solution for this PR. It allows parsing of
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 14:45 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-10 14:45 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2005-11-10
14:46 ---
A give-away here is that inverting the order of the equivalence members, makes
the problem go away. The path below cures the problem but I have not regtested
yet.
Paul T
Index:
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-10 14:58 ---
(In reply to comment #3)
Reducing (which means I can reproduce it).
Note I am still reducing this one. It is just taking a long time. Also I lost
connection to the machine I was reducing on last night.
--
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2005-11-10 15:35
---
On mips-irix6.5, the libgfortran config.h contains:
#define HAVE_CABSF 1
and
/* #undef HAVE_COMPLEX_H */
and in math.h it does have the following:
struct __cabsl_s { long double a,b; };
extern long double
The issue here is that libobjc current includes GCC's target headers like
config/rs6000/rs6000.h and config/i386/i386.h This needs to be changed so that
libobjc no longer includes them.
--
Summary: libobjc should not include GCC's target headers
Product: gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 15:45 ---
Mine, I am working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Right now if TLS is disable (or if a target does not support TLS) the thread
private testcase fail. There should be a way to enable thread private and non
TLS targets.
--
Summary: [GOMP] non-TLS and thread private
Product: gcc
Version: 4.1.0
Status:
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2005-11-10
15:54 ---
The following patch fixes this PR. Please note that it has yet to be regtested
but I do not see any problems with it. I do not thank that PR15809 has
anything to do with this one.
Index:
Couple of the FIXME's in c-decl.c:
/* A conflicting function declaration for a predeclared
function that isn't actually built in. Objective C uses
these. The new declaration silently overrides everything
but the volatility (i.e. noreturn)
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2005-11-10 16:58
---
Subject: Bug 22127
Author: ebotcazou
Date: Thu Nov 10 16:58:56 2005
New Revision: 106739
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106739
Log:
PR middle-end/22127
* calls.c
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2005-11-10 17:00
---
Subject: Bug 22127
Author: ebotcazou
Date: Thu Nov 10 17:00:41 2005
New Revision: 106740
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106740
Log:
PR middle-end/22127
* calls.c
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2005-11-10 17:05
---
See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00663.html.
Fixed in 4.0.3 and up.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
I checked out gcc from svn; I have version
$ svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 106735
Node Kind: directory
Schedule: normal
Last Changed Author: jakub
Last Changed Rev: 106735
Last Changed Date: 2005-11-10
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-10 17:18 ---
Subject: Bug 24774
Author: jakub
Date: Thu Nov 10 17:18:12 2005
New Revision: 106742
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106742
Log:
PR fortran/24774
* io/inquire.c
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-10 17:22
---
Created an attachment (id=10203)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10203action=view)
Complete error message
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24778
--- Comment #3 from jakub at gcc dot gnu dot org 2005-11-10 17:23 ---
Fixed in CVS.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from schnetter at aei dot mpg dot de 2005-11-10 17:24
---
Created an attachment (id=10204)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10204action=view)
Failing assembler output
This is from a different invokation of the compiler, i.e., the auto-generated
file
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-10 17:32 ---
Something is really wrong:
beq- cr7,_L13070
There should be no underscore there.
Some get it correct:
b L12781
What gcc are you starting with?
What happens if you remove -mlongcall from the
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Hi,
The following testcase reduced from Python's mathmodule.c is miscompiled with
gcc 3.3-hammer at -O2 and FSF gcc version 4.0.3 20051103 at -O2
-fno-unit-at-a-time as otherwise gcc is smart enough to optimize out the
function descriptor and the problem disappears.
Looking at the generated
In a file that defined several templates, I received the following error
message:
internal compiler error: in set_mem_attributes_minus_bitpos, at emit-rtl.c:1539
Bug 20073 involved the same error message, but that was marked fixed last
February. The .ii file compiles in 3.4.4 but fails in
--- Comment #1 from gbeauchesne at mandriva dot com 2005-11-10 17:51
---
Created an attachment (id=10205)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10205action=view)
Reduced testcase
I will attach a variant which is self-contained but it's a little messay as it
requires some
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 17:52 ---
Reducing (this means I can reproduce it).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Summary|Assembler errors during |[4.1
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from gbeauchesne at mandriva dot com 2005-11-10 18:02
---
Created an attachment (id=10206)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10206action=view)
Self-contained testcase
Fails with gcc 4.0.3 20051103 (prerelease) -O2 -fno-unit-at-a-time
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-10 18:03 ---
Caused by:
http://gcc.gnu.org/viewcvs?view=revrev=106703
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24778
--- Comment #5 from aoliva at gcc dot gnu dot org 2005-11-10 18:11 ---
Mine. I'll try to get the failure with a cross compiler.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from sje at cup dot hp dot com 2005-11-10 18:20 ---
I can't believe I configured with --disable-shared. OK, without that things
look better. I changed LIBGCC to %{shared-libgcc:%{mlp64:-lgcc_s_hpux64}}
-lgcc and I get -lgcc_s on the link command. I am doing a
--- Comment #16 from law at redhat dot com 2005-11-10 18:26 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Wed, 2005-11-02 at 14:32 +, hubicka at ucw dot cz wrote:
Hmm, perhaps restricting the reassociation + simplification
--- Comment #17 from law at redhat dot com 2005-11-10 18:30 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Wed, 2005-11-02 at 14:32 +, hubicka at ucw dot cz wrote:
Hmm, perhaps restricting the reassociation + simplification into
--- Comment #16 from jason at gcc dot gnu dot org 2005-11-10 18:32 ---
The patch breaks the 4.0 branch compiler, and I don't think this is a serious
enough bug to put more work into coming up with a different fix for older
releases.
--
jason at gcc dot gnu dot org changed:
GCC version:
Using builtin specs.
gcc version 2.95.2 19991024 (release)
System Type:
iBSD4
GCC Options:
--prefix=/usr/bin/gcc4
During install of gcc version 4.0.2
Configure Command:
/usr/home/joelk/ftp/gcc-4.0.2/configure --prefix=/usr/bin/gcc4
During Make command, Locks Up after the
--- Comment #6 from aoliva at gcc dot gnu dot org 2005-11-10 19:54 ---
Subject: Bug 24778
Author: aoliva
Date: Thu Nov 10 19:54:06 2005
New Revision: 106749
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106749
Log:
PR target/24778
* varasm.c (assemble_name): Recompute name only
--- Comment #7 from aoliva at gcc dot gnu dot org 2005-11-10 20:04 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
class Foo { public: typedef int type1; };
class Bar { private: typedef Foo type2; };
void f(Bar::type2 ) {} // rejected, OK
void g(Bar::type2::type1) {} // accepted ???
gcc-3.2.3 and 3.3.6 reject both lines
3.4.5 4.0.3 and CVS snapshot wrongly(?) accept the last line
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 20:31 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The small program given do not compile with gfortran: Compiler complains:
Error: Symbol 'ny' at (1) has no IMPLICIT type
- Removing IMPLICIT NONE for the module allows compilation.
or
- removing the DIMENSION vec(ny) allows compilation.
The problem seems to be related to implicit ny variable
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-10 21:11 ---
Confirmed, reduced testcase:
templatetypename S=int
struct Move {
Move();
static MoveS const MOVES[2][2];
};
templatetypename S
MoveS const MoveS::MOVES[2][2]={};
typedef Moveint const MoveClass;
void
The Fortran code
$ cat unused.f90
subroutine a(x)
implicit none
real x
end subroutine a
gives the warning
$ ~/gcc/bin/gfortran -c unused.f90 -Wall
unused.f90: In function a:
unused.f90:1: warning: unused variable x
when compiled with
$ ~/gcc/bin/gfortran --version
GNU Fortran 95
--- Comment #9 from janis at gcc dot gnu dot org 2005-11-10 21:22 ---
I can't reproduce the segfault using a cross compiler on a powerpc64-linux
system. The second testcase compiles successfully there using several very
recent checkouts from the trunk, including the date the PR was
--- Comment #5 from eedelman at gcc dot gnu dot org 2005-11-10 21:24
---
Subject: Bug 22607
Author: eedelman
Date: Thu Nov 10 21:24:12 2005
New Revision: 106751
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106751
Log:
fortran/
2005-11-10 Erik Edelmann [EMAIL PROTECTED]
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 21:24 ---
Hmm, there is something weird going on here.
If I do -W -Wall, then I get:
t.f90: In function 'a':
t.f90:1: warning: unused parameter 'x'
t.f90: At top level:
t.f90:1: warning: unused parameter 'x'
But if I just do
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 21:35 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from redi at gcc dot gnu dot org 2005-11-10 21:42 ---
I'm building the compiler now, will test a.s.a.p
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from tobi at gcc dot gnu dot org 2005-11-10 21:49 ---
Subject: Bug 24643
Author: tobi
Date: Thu Nov 10 21:49:29 2005
New Revision: 106753
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106753
Log:
fortran/
PR fortran/24643
* primary.c (match_varspec): Check for
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-11-10 21:50
---
Fixed on both 4.1 and 4.0
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-11-10 21:51
---
This bug and PR 22607, which was fixed recently, appears to be duplicates.
*** This bug has been marked as a duplicate of 22607 ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from eedelman at gcc dot gnu dot org 2005-11-10 21:51
---
*** Bug 19766 has been marked as a duplicate of this bug. ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
Hi,
the following program shows that the X edit descriptor
can get lost when splitting a WRITE with ADVANCE=NO:
program x_with_advance_bug
c This variant works as expected,
write (*,'(A, )',advance=no)
write (*,'(A)')
c while this one misses the 2X:
write (*,'(A,2X)',
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-10 22:24 ---
Subject: Bug 24409
Author: pault
Date: Thu Nov 10 22:24:28 2005
New Revision: 106756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106756
Log:
2005-11-10 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-10 22:24 ---
Subject: Bug 24755
Author: pault
Date: Thu Nov 10 22:24:28 2005
New Revision: 106756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106756
Log:
2005-11-10 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from pault at gcc dot gnu dot org 2005-11-10 22:24 ---
Subject: Bug 24655
Author: pault
Date: Thu Nov 10 22:24:28 2005
New Revision: 106756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106756
Log:
2005-11-10 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #12 from tkoenig at gcc dot gnu dot org 2005-11-10 22:39
---
Created an attachment (id=10210)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10210action=view)
proposed patch, without docs (so far)
Here's a partial solution, which implements the CONVERT keyword
in the
--- Comment #23 from tkho at ucla dot edu 2005-11-10 22:43 ---
Created an attachment (id=10211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10211action=view)
Another long long rotate test case
Hi Michael,
I tried your patch in comment #16, and it didn't optimize our code.
--- Comment #3 from janis at gcc dot gnu dot org 2005-11-10 22:53 ---
A regression hunt identified this patch:
r95217 | jakub | 2005-02-18 06:58:40 + (Fri, 18 Feb 2005) | 9 lines
PR c++/19813
* emit-rtl.c (set_mem_attributes_minus_bitpos): Add assertion
--- Comment #13 from tkoenig at gcc dot gnu dot org 2005-11-10 22:53
---
Also, little_endian and big_endian have
to be converted to native or swap, depending on
the architecture.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16702
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|3.4.0 |
Priority|P2 |P3
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14532
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15535
--- Comment #13 from tobi at gcc dot gnu dot org 2005-11-10 23:10 ---
Subject: Bug 24643
Author: tobi
Date: Thu Nov 10 23:10:51 2005
New Revision: 106757
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106757
Log:
Backport r106753
fortran/
PR fortran/24643
* primary.c
--- Comment #14 from tobi at gcc dot gnu dot org 2005-11-10 23:11 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-10 23:13 ---
I think this is related to PR 19340.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15439
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-10 23:15 ---
*** This bug has been marked as a duplicate of 24643 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from tobi at gcc dot gnu dot org 2005-11-10 23:15 ---
*** Bug 22048 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-10 23:20 ---
Mark do you know if your patch for PR 20912 would fix this?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janis at gcc dot gnu dot org 2005-11-10 23:40 ---
A regression hunt using a cris-axis-elf cross compiler on powerpc-linux
identified this patch:
r95823 | hp | 2005-03-03 03:53:29 + (Thu, 03 Mar 2005) | 40 lines
http://gcc.gnu.org/viewcvs?view=revrev=95823
--
--- Comment #10 from bill dot thompsons at gmail dot com 2005-11-11 00:56
---
Subject: Re: Stack corruption in ARM arch. if 64bit variable is passed to a
function of which the low 32 use the register and the up 32 use the stack
What is the procedure for getting fixes in 3.4.x and
--- Comment #9 from hp at bitrange dot com 2005-11-11 01:06 ---
Subject: Re: [4.1 regression] global-alloc (reload)
trips over own confusion for unexpected addressing modes
On Thu, 10 Nov 2005, janis at gcc dot gnu dot org wrote:
--- Comment #8 from janis at gcc dot gnu dot org
--- Comment #24 from tkho at ucla dot edu 2005-11-11 01:26 ---
For comparison, here's the code from gcc 2.95.3. It generates the same 18
instructions for both march=i386 and march=pentiumpro.
`gcc -c test3.c -save-temps -O2 -momit-leaf-frame-pointer -march=pentiumpro`:
pushl
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-11 02:07
---
Another trasnfer.c bug possibly. I will investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24785
1 - 100 of 126 matches
Mail list logo
