On Mon, 4 Feb 2008, Kaveh R. Ghazi wrote:
Well, since it's not working I guess something got lost in translation? I
don't have access to solaris11, can you please help?
I don't have solaris11 either.
--
Joseph S. Myers
[EMAIL PROTECTED]
Kaveh R. Ghazi writes:
Well, since it's not working I guess something got lost in translation? I
don't have access to solaris11, can you please help?
the libm sources, including math_c99.h, are available for download from
http://dlc.sun.com/osol/devpro/downloads/current/
Hi Kaveh,
I notice that the solaris_math_* fix hacks all seems to have a bypass clause
on GNUC. Sometimes the solaris headers try to be gcc-aware. Is there a
GNUC appearing in solaris11's /usr/include/iso/math_c99.h header? And that
begs the question, why do these fix hacks have this
Rainer Orth wrote:
Hi Kaveh,
I notice that the solaris_math_* fix hacks all seems to have a bypass clause
on GNUC. Sometimes the solaris headers try to be gcc-aware. Is there a
GNUC appearing in solaris11's /usr/include/iso/math_c99.h header? And that
begs the question, why do these fix
From: Andreas Tobler [EMAIL PROTECTED]
Rainer Orth wrote:
In c99-math-double-1.c, the first C99_MATH_TESTS invocation abort()s.
Single-stepping in gdb (which couldn't display the macro, even if
compiled
with -g3 ;-) revealed that this clause
if (fetestexcept (FE_ALL_EXCEPT) != 0) \
Kaveh R. Ghazi wrote:
Okay, thanks both of you for tracking this down.
So the solaris definition of isinf is not exception-safe in the presence
of nans. Try inserting this code into c99-math-double-1.c after it
includes math headers. (This is what fixincludes puts into the header
for
From: Andreas Tobler [EMAIL PROTECTED]
[ultra10:gcc/gcc/testsuite] andreast% svn diff gcc.dg/c99-math-double-1.c
Index: gcc.dg/c99-math-double-1.c
===
--- gcc.dg/c99-math-double-1.c (revision 132096)
+++ gcc.dg/c99-math-double-1.c
Kaveh R. Ghazi wrote:
Great, we're making progress.
On mainline only (not 4.2 or prior) does this work instead?
Yep, trunk.
[ultra10:gcc/testsuite/gcc.dg] andreast% diff -u
/usr/include/iso/math_c99.h.orig /usr/include/iso/math_c99.h
--- /usr/include/iso/math_c99.h.origMon Feb 4
Hallo,
Is there summarized table of ABI binary compatibility of following
compiled programs by ...?
1st. C (the core)
2nd. Fortran
3rd. C++
and 4th. GCJ's Java
between the 4.3.0, 4.2.3, 4.1.x, 4.0.x, 3.4.x and 3.3.x versions?
The comments are not for me, they are for everyones who need
J.C. Pizarro wrote:
2nd. Fortran
4.0.x: I don't know, but one should really not use that version
4,[1-3].x come with incompatible gfortran libraries, which have also
different version numbers: libgfortran.so.1 to libgfortran.so.3.
Minor versions are upward compatible, i.e. programs compiled
Richard Guenther wrote:
Status
==
We are in Stage 3 and the trunk is open for regression and documentation
fixes only. When we reach zero open P1 regressions, we will create a
release candidate for 4.3.0, branch and announce the opening of Stage 1
for 4.4.
make profiledbootstrap is still
On Tue, Feb 05, 2008 at 11:38:06PM +0100, J.C. Pizarro wrote:
Hallo,
Is there summarized table of ABI binary compatibility of following
compiled programs by ...?
1st. C (the core)
2nd. Fortran
3rd. C++
and 4th. GCJ's Java
between the 4.3.0, 4.2.3, 4.1.x, 4.0.x, 3.4.x and 3.3.x
--- 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
1 - 100 of 147 matches
Mail list logo
