--- Comment #3 from ubizjak at gmail dot com 2008-02-05 08:26 ---
Mine.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #4 from vegard dot nossum at gmail dot com 2008-02-05 09:23
---
Is there a work-around, i.e. a command-line flag that turns _this particular_
kind of optimization off (without turning off all optimizations)? It seems that
the behaviour is found in -O1 and -O2 as well, in
The code example below compiles successfully under Microsoft Visual Studio 2005
SP1.
Minimal steps to reproduce:
-
templatetypename T void foo(T ) {}
int main()
{
struct A
{
int m;
};
A a;
foo(a);
return 0;
}
--- Comment #5 from ubizjak at gmail dot com 2008-02-05 09:45 ---
optabs.c, line 5150:
--cut here--
/* Unsigned integer, and no way to convert directly. Convert as signed,
then unconditionally adjust the result. For decimal float values we
do this only if we have already
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-02-05
09:37 ---
Patch at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00118.html
danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2008-02-05 09:33 ---
Allocation functions cannot be declared in namespace scope, see
[basic.stc.dynamic.allocation].
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2008-02-05 09:36 ---
Following patch fixes ICE (and avoids nasty runtime/code-size regression for
x87 math where we don't use fildll):
--cut here--
Index: config/i386/i386.md
--- Comment #4 from pault at gcc dot gnu dot org 2008-02-05 09:36 ---
I have just posted a patch, so I had better take the PR on!
http://gcc.gnu.org/ml/fortran/2008-02/msg00027.html
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|--- |4.3.0
--- Comment #1 from pcarlini at suse dot de 2008-02-05 10:00 ---
This is illegal in C++03, per 14.3.1/2, and no strictly conforming compiler
accepts it.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P2
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-05 10:13 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-02-05 10:17
---
(In reply to comment #0)
As the standard makes not provisions and !DEC$ (*DEC$, cDEC$) is widely used,
gfortran should accept the following:
function CallWndRetProc(nCode, wParam, lParam)
!DEC$
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-05 10:19 ---
Works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #2 from ismail at pardus dot org dot tr 2008-02-05 10:21
---
I bootstrapped twice and still get it. I will try svn up, reboot the machine
etc *sigh*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-05 10:28 ---
This works for me on x86_64 with 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33661
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-02-05 10:55
---
OK, found it by commenting out various parts of the I/O library until it
disappeared. The leak is the following line in data_transfer_init (transfer.c):
dtp-u.p.current_unit = get_unit (dtp, 1);
The memory
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-02-05 10:54 ---
Created an attachment (id=15098)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15098action=view)
patch
Try this instead.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from manu at gcc dot gnu dot org 2008-02-05 11:21 ---
You should use OPT_Wtype_limits instead of OPT_Wextra.
Also, the code could simply do:
+ tree op0 = TREE_OPERAND (cond, 0);
+ tree op1 = TREE_OPERAND (cond, 1);
+ tree type = TREE_TYPE (op0);
+
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34109
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|4.3.0 |4.1.3 4.3.0
Summary|[4.2 only] vectorization|[4.2
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-05 11:08 ---
The difference with your last testcase is indeed that we unroll the loop
setting c[] and constant-fold the result by computing the integral powers
with 0.5ulp precision (and a single rounding(!)). But all your
--- Comment #5 from pault at gcc dot gnu dot org 2008-02-05 11:17 ---
Subject: Bug 32315
Author: pault
Date: Tue Feb 5 11:16:33 2008
New Revision: 132113
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132113
Log:
2008-02-05 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from uros at gcc dot gnu dot org 2008-02-05 11:28 ---
Subject: Bug 35083
Author: uros
Date: Tue Feb 5 11:27:41 2008
New Revision: 132114
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132114
Log:
PR target/35083
* config/i386/i386.md
--- Comment #3 from ismail at pardus dot org dot tr 2008-02-05 11:53
---
Ok on a third bootstrap I can still reproduce, is there a way to debug it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-02-05 12:27
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-05 12:35 ---
How does it fail?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 regression]|[4.3 Regression]
|gcc.dg/vect/vect-iv-9.c
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-02-05 12:32
---
Subject: Bug 34825
Author: rguenth
Date: Tue Feb 5 12:31:50 2008
New Revision: 132119
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132119
Log:
2008-05-02 Richard Guenther [EMAIL PROTECTED]
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-02-05 12:31
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-02-05 12:03
---
This problem is not seen on 4.3.0.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-02-05 12:04
---
Subject: Bug 33946
Author: fxcoudert
Date: Tue Feb 5 12:03:21 2008
New Revision: 132115
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132115
Log:
PR testsuite/33946
*
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-02-05 12:04
---
Fixed on 4.3.0.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-02-05 12:27
---
Subject: Bug 33819
Author: rguenth
Date: Tue Feb 5 12:26:53 2008
New Revision: 132118
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132118
Log:
2008-02-05 Richard Guenther [EMAIL PROTECTED]
--- Comment #5 from ismail at pardus dot org dot tr 2008-02-05 12:38
---
The long only shows:
FAIL: gcc.dg/vect/vect-iv-9.c scan-tree-dump-times vect vectorized 1 loops 2
nothing else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-02-05 12:38 ---
does making int a[N]; aligned fix it? That is
int a[N] __attribute__((aligned(16)));
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #8 from pault at gcc dot gnu dot org 2008-02-05 12:57 ---
I just noticed that this is due to incorrect or non-existent type/kind checking
in the constructor 'mytype'. With -fdefault-integer-8, yy has KIND=8, whereas
the corresponding component has KIND=4, as given by the
--- Comment #7 from ismail at pardus dot org dot tr 2008-02-05 13:20
---
Adding __attribute__((aligned(16))) doesn't work, attached is the *.vect file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #9 from pault at gcc dot gnu dot org 2008-02-05 13:05 ---
I've knocked back it's priority but have assigned it to myself to compensate.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2008-02-05 13:06 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ismail at pardus dot org dot tr 2008-02-05 13:20
---
Created an attachment (id=15099)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15099action=view)
*.vect file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #7 from ubizjak at gmail dot com 2008-02-05 13:58 ---
This is the diff of expand_float() between gcc-4.2 and gcc-4.3. The relevant
part is logic at the top of the diff that has changed substantially:
--- 222 2008-02-05 14:52:52.0 +0100
+++ 111 2008-02-05
--- Comment #10 from pault at gcc dot gnu dot org 2008-02-05 13:37 ---
Fixed on trunk - thanks, Dick!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-02-05 13:36
---
Thanks, looks comparable to K8 scores, except that -O3 is not actually that
worse there. So it looks there is more than just random effect of code layout
involved, I will try to look into the assembly produced
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-02-05 13:30 ---
Subject: Bug 35074
Author: dgregor
Date: Tue Feb 5 13:29:43 2008
New Revision: 132120
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132120
Log:
2008-02-05 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-02-05 13:30 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-02-05 13:31
---
This testcase is still slower, 4.4s with -O2 and 3.6s with -O2
-fno-inline-small-functions (on i386). I wondered if the patch counting
frequency of calls crossed helped here. My slowdown is smaller than what
--- Comment #11 from dgregor at gcc dot gnu dot org 2008-02-05 13:34
---
This latest problem is identical to PR c++/35074, which has now been fixed. The
new test case in this bug is passing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33620
--- Comment #9 from pault at gcc dot gnu dot org 2008-02-05 13:34 ---
Subject: Bug 34945
Author: pault
Date: Tue Feb 5 13:33:35 2008
New Revision: 132121
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132121
Log:
2008-02-05 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from jakub at gcc dot gnu dot org 2008-02-05 13:49 ---
For -O1 and higher I of course expect this to be DEFERRED until we have
infrastructure. But for -O0 we IMHO can and should keep the expressions
around.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34037
--- Comment #16 from hubicka at gcc dot gnu dot org 2008-02-05 13:55
---
Thanks, looks comparable to K8 scores, except that -O3 is not actually that
worse there. So it looks there is more than just random effect of code layout
involved, I will try to look into the assembly produced
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-02-05 14:35 ---
This is a canonical types issue; I'm on it.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Today's (2008-02-05; rev. 132112) m68k-rtems*-gcc from gcc-trunk ICEs when
building rtems :
...
m68k-rtems4.9-gcc --pipe -B../../../lib/ -B../../../av5282/lib/ -specs
bsp_specs -qrtems -DPACKAGE_NAME=\rtems-c-src\
-DPACKAGE_TARNAME=\rtems-c-src\ -DPACKAGE_VERSION=\4.8.99.0\
When the -Os option is specified, a global variable reference can generate code
that has a relocation-style entry, i.e. load register A with 0x30, which
causes an invalid pointer reference. This was found in Linux kernel version
2.6.16.27-0.9-smp in Suse, compiling a driver, which seems to have
With revision 132122, I got
bash-3.2$
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../
/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/data_constraints_1.f90 -O
-pedantic-errors -S -m32
--- Comment #1 from lee_merrill at yahoo dot com 2008-02-05 15:51 ---
Created an attachment (id=15101)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15101action=view)
The source code for causing the described problem
Type make and then run btifc to cause a core dump. The
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-02-05
15:26 ---
Have you tried current gcc trunk to make sure that...
r132095 | rguenth | 2008-02-04 16:12:49 -0500 (Mon, 04 Feb 2008) | 6 lines
2008-02-04 Richard Guenther [EMAIL PROTECTED]
PR java/35035
not seen with trunk 20071202, seen with trunk 20080202
not seen with the backport of java from the trunk to the gcc-4.2 branch.
Matthias
=== libjava tests ===
Running target unix
FAIL:
--- Comment #3 from debian-gcc at lists dot debian dot org 2008-02-05
15:01 ---
reconfirmed with 20080202:
http://buildd.debian.org/fetch.cgi?pkg=gcj-4.3ver=4.3-20080202-1arch=alphastamp=1202180571file=log
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33263
With the df branch merge we got duplicate uses of dump file letters ('z' at
least)
and some of the letters used are not documented as well.
--
Summary: RTL dump file letters hosed and partly undocumented
Product: gcc
Version: 4.3.0
Status:
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-05 14:32
---
Created an attachment (id=15100)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15100action=view)
preprocessed source of file producing ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
--- Comment #2 from burnus at gcc dot gnu dot org 2008-02-05 15:02 ---
We need to add a volatile_ attribute to COMMON; and, either add the VOLATILE
attribute to all its symbols in resolve.c or change the if block in
trans-common.c, which has been added in PR 35037.
--
When compiling JNI code in Linux RedHat, I get the following error:
/usr/java/j2sdk1.4.2_16/include/jni.h:39: error: conflicting types for
'jboolean'
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/jni_md.h:84: error: previous
declaration of 'jboolean' was here
I need the compiler to pick the Sun's
--- Comment #4 from hjl at gcc dot gnu dot org 2008-02-05 14:51 ---
Subject: Bug 35084
Author: hjl
Date: Tue Feb 5 14:51:06 2008
New Revision: 132122
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132122
Log:
2008-02-05 H.J. Lu [EMAIL PROTECTED]
PR target/35084
--- Comment #5 from hjl dot tools at gmail dot com 2008-02-05 14:52 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #5 from burnus at gcc dot gnu dot org 2008-02-05 15:12 ---
I thought a bit about that recently, and I don't like the idea of having to
support parts of another vendor's extension. The first other idea I had was to
add that STDCALL specification as an extension to the BIND
[forwarded from http://bugs.debian.org/397853]
confirmed with trunk 20080116
$ java FirstSample
Exception in thread main java.lang.NoClassDefFoundError: FirstSample
at gnu.java.lang.MainThread.run(libgcj.so.70)
Caused by: java.lang.ClassNotFoundException: FirstSample not found in
--- Comment #6 from dnovillo at google dot com 2008-02-05 16:15 ---
Subject: Re: -Wtype-limits misses a warning when comparing enums
On 5 Feb 2008 11:21:26 -, manu at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
You should use OPT_Wtype_limits instead of OPT_Wextra.
Ah, yes,
--- Comment #17 from hubicka at gcc dot gnu dot org 2008-02-05 16:18
---
The simplified testcase is dealt with the call crossed frequency patch. I now
get:
.L2:
faddl (%edx,%eax,8)
addl$1, %eax
cmpl$2000, %eax
jne .L2
fstpl
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-02-05 16:23 ---
Subject: Bug 35070
Author: ghazi
Date: Tue Feb 5 16:23:10 2008
New Revision: 132123
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132123
Log:
PR other/35070
* toplev.c (print_version): Honor
--- Comment #18 from hubicka at gcc dot gnu dot org 2008-02-05 16:24
---
RA still don't split live ranges, but works sanely here:
.L21:
faddl (%ebx,%eax,8)
addl$1, %eax
cmpl%edx, %eax
jl .L21
Honza
--
hubicka at gcc dot gnu dot org
--- Comment #8 from tgall dot foo at gmail dot com 2008-02-05 16:24 ---
this bug might in some ways be related bug an older bug in gcc 4.1 where make
profiledbootstrap on power3 was busted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28326
When I have been running into this problem it
--- Comment #7 from ghazi at gcc dot gnu dot org 2008-02-05 16:27 ---
Fixed.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-05 16:02 ---
I suggest to rip out support for -d'LETTER'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35094
--- Comment #7 from dnovillo at gcc dot gnu dot org 2008-02-05 16:32
---
Subject: Bug 33738
Author: dnovillo
Date: Tue Feb 5 16:31:20 2008
New Revision: 132124
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132124
Log:
--- Comment #2 from pluto at agmk dot net 2008-02-05 16:33 ---
(In reply to comment #0)
it's not a gcc bug, it's a null pointer dereference.
while (1) {
if (ctrl) {
(...)
lxTraceCopy(cuSub-traceTag, ctrl-ctrlPath, ...
} else if (pkt) {
--- Comment #10 from bergner at gcc dot gnu dot org 2008-02-05 16:38
---
Bootstrap and regtesting is in progress on the new patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29253
--- Comment #5 from bergner at gcc dot gnu dot org 2008-02-05 16:45 ---
This works for me using latest mainline, but using a compiler built with
revision 131553, it fails. I'll try and see if we're just getting lucky now or
whether it has been fixed since then.
Janis, in the meantime,
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-05 16:53 ---
The declarations should be effectively the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35089
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P4
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-05 16:57 ---
Thus, invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dnovillo at gcc dot gnu dot org 2008-02-05 16:58
---
Why was I CC'd on this PR?
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hp at gcc dot gnu dot org 2008-02-05 16:50 ---
Same for cris-elf, host x86_64 under F 8. Further narrowing of revisions:
r132114 failed and r132112 worked. It can't be the r132114 revision (being i386
only), so it's pretty sure to be pault's commit.
--
hp at gcc
--- Comment #2 from tromey at gcc dot gnu dot org 2008-02-05 17:02 ---
I think you need an additional -I pointing to the directory
containing the JDK's jni_md.h.
Can you confirm this and get back to me?
--
tromey at gcc dot gnu dot org changed:
What|Removed
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35089
--- Comment #1 from tromey at gcc dot gnu dot org 2008-02-05 17:09 ---
Probably a dup of PR 9463.
What locale are you using? How is the umlaut encoded in the directory name?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-02-05 17:13 ---
==25387== Invalid free() / delete / delete[]
==25387==at 0x4C2430F: free (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==25387==by 0x414BE9: gfc_assign_data_value (data.c:332)
==25387==by
--- Comment #4 from hp at gcc dot gnu dot org 2008-02-05 17:21 ---
s/ice-on-valid/ice-on-invalid/
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-05 17:28 ---
Duplicates have always existed. E.g. -dr and -dG have been overloaded for as
long as I can remember using them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35094
--- Comment #5 from burnus at gcc dot gnu dot org 2008-02-05 17:29 ---
As I have a patch ... (Currently regtesting; valgrind reports no failures with
that patch.)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-02-05 18:06 ---
Well, this was a fun one. Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00146.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35049
--- Comment #19 from ubizjak at gmail dot com 2008-02-05 18:25 ---
There was a discussion on IRC some time ago, and it was suggested that there
was a LR-splitting patch in cygnus local tree. maybe someone would like to post
this patch on gcc-patches@ ML?
--
This is a follow-up from PR 32315.
The following accesses valid data, but the array bounds are wrong:
program chkdata
character(len=20), dimension(4,4) :: string
data ( string(i,1),i=1,5) / 'A', 'B', 'C', 'D', 'E' /
end program chkdata
Since PR 32315 all invalid memory accesses are
--- Comment #6 from burnus at gcc dot gnu dot org 2008-02-05 18:37 ---
Patch:
http://gcc.gnu.org/ml/fortran/2008-02/msg00037.html
(Cross reference: The regression was caused by the fix for PR 32315.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35093
--- Comment #35 from dominiq at lps dot ens dot fr 2008-02-05 19:27 ---
Before closing this PR would it be possible to apply the patch in comment #19
for libjava/testsuite/libjava.jvmti/interp/natgetstacktrace.cc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
--- Comment #11 from bergner at gcc dot gnu dot org 2008-02-05 19:34
---
Now we get a different ICE with the following test case:
[EMAIL PROTECTED]:~/gcc/PR29253/bugs cat _abs_r16.f95
elemental function _gfortran_specific__abs_r16 (parm)
real (kind=16), intent (in) :: parm
real
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-05
19:46 ---
Subject: Re: [4.2 Regression] 841 unexpected failures in gfortran testsuite
CC||rth at gcc dot gnu dot org
I'm sorry but Richard's change isn't the cause.
--- Comment #8 from reichelt at gcc dot gnu dot org 2008-02-05 19:54
---
Reopened, since the patch was reverted.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from vincent dot riviere at freesbee dot fr 2008-02-05
19:56 ---
Same problem with GCC 4.3-20080201 on target i686-pc-linux-gnu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33661
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||33702
nThis||
Target
1 - 100 of 135 matches
Mail list logo