--- Comment #10 from elizabeth dot l dot yip at boeing dot com 2007-05-15
07:48 ---
The following code exposes the problem relating to conjg(transpose(.)), with
which gfortran returns the wrong answer. If we break conjg(transpose(.)) into
two lines, then we can get the right answer.
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-15 08:52 ---
This patch fixes this.
+ else
+ *dest = NULL;
This patch fixes the actual problem and should be committed. Thanks Jerry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31922
--- Comment #27 from rguenth at gcc dot gnu dot org 2007-05-15 08:59
---
Yes, that's a (part of!) a diff of a -details dump with the following patch
Index: passes.c
===
--- passes.c(revision 124501)
+++ passes.c
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-05-15 09:05 ---
Well, 4.0 didn't have struct aliasing, so yes. Though it's unlikely to be
fixed
for 4.1.x.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following code is invalid as shapes of X and Y are not identical:
$ cat atan2.f90
real :: x(3), y(2) ! same rank but different shapes
x = atan2(x,y)
end
$ gfortran-svn -fdump-tree-original atan2.f90
$ cat atan2.f90.003t.original
MAIN__ ()
{
real4 y[2];
real4 x[3];
F95, 7.1.5, Conformability rules for elemental operations
An elemental operation is an intrinsic operation or a de#64257;ned elemental
operation. Two entities are in shape conformance if both are arrays of the same
shape, or one or both are scalars.
Thus, for bes[jy]n the following should be
--- Comment #6 from chrbr at gcc dot gnu dot org 2007-05-15 10:30 ---
I dropped the 4.1 and implemented a -finvert-loops option on the trunk.
This option allows a basic induction variable to be decremented instead of
incremented to support exit testing against 0.
I'm validating a
--- Comment #11 from rob1weld at aol dot com 2007-05-15 10:46 ---
Here are my results with gcc version 4.2.0 20070505 (prerelease).
/wonka# ./vte
logMessage is called
/root/downloads/gcc-4_2-branch/libjava/classpath/native/jni/gtk-peer/gthread-jni.c:1242:
AWT JNI failure
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-15 10:56 ---
(In reply to comment #8)
The patch below works and regtests OK.
I told a lie - the version that regtests OK has the line
+ if (!integer_onep (info-stride[dim]))
+ stride_ne_one = 1;
a
I compiled gcc version 4.2.0 20070505 (prerelease) and decided to try some of
the Mauve tests ( http://sources.redhat.com/mauve/ ) as suggested on
http://gcc.gnu.org/install/test.html .
I did read http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16662 but when I tried
to re-open the bug it was not
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-15 11:17 ---
Subject: Bug 31915
Author: burnus
Date: Tue May 15 10:16:46 2007
New Revision: 124741
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124741
Log:
2007-05-15 Tobias Burnus [EMAIL PROTECTED]
PR
Parts of gcc are compiled without libiconv even if it's present in the system
and --with-libiconv-prefix specified correctly.
The reason for this is usage of HAVE_ICONV_H macro.
1. The check for iconv.h in configure does not use the value of
--with-libiconv-prefix option.
2. HAVE_ICONV_H is
--- Comment #1 from serg at vostok dot net 2007-05-15 11:25 ---
Created an attachment (id=13557)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13557action=view)
Removes HAVE_ICONV_H from source code.
This should fix the bug. And, probably, some other problems with gcc not using
program main
implicit none
real(kind=10) :: a
a = 1.1_10
write(10) a
end program main
Maybe someone could check real(16) as well. I assume only real(10) is affected,
though.
Gives:
==4217== Syscall param write(buf) points to uninitialised byte(s)
==4217==at 0x5601550: write (in
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-15 11:29 ---
Filled PR 31933 for the valgrind errors. These seem to be related to REAL(10),
but are independent of convert.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from segher at kernel dot crashing dot org 2007-05-15 13:07
---
Bisecting shows that the original bug (powerpc64 Linux build
errors out) is caused by r122781. I didn't actually test on 4.2
but the same patch is applied there (as r122782).
If the reduced testcase in
I'm seeing differences between the DWARF data being generated by gcc 3.4.6 and
4.1.2.
Compiling the following (-g -mno-quickcall):
int f(int a)
{
return a;
}
generates the following code (in both 3.4.6 and 4.1.2):
_f:
0: 6d f6 mov.w r6,@-r7
2: 0d 76
--- Comment #10 from patchapp at dberlin dot org 2007-05-15 13:40 ---
Subject: Bug number PR31867
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00961.html
--
gfortran -O3 -ftree-loop-linear -ftree-vectorize air.f90
gives:
air.f90: In function 'MAIN__':
air.f90:28: internal compiler error: Segmentation fault
Using -O2 or dropping one of the -f options removes the error. Occurs also with
-m32. This is with today's GCC 4.3 (r124742). It was working
--- Comment #1 from pault at gcc dot gnu dot org 2007-05-15 13:49 ---
This does the trick on all fronts:
Index: gcc/fortran/check.c
===
*** gcc/fortran/check.c (révision 124614)
--- gcc/fortran/check.c (copie de travail)
--- Comment #1 from supermar at gmx dot de 2007-05-15 14:09 ---
I can confirm the bug for i486-unknown-linux-gnu, too.
--
supermar at gmx dot de changed:
What|Removed |Added
--- Comment #12 from ubizjak at gmail dot com 2007-05-15 15:06 ---
Patch for several other missing conversions:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00966.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24659
The option -fbacktrace gives a backtrace on various library and check errors.
If used in conjunction with -ffpe-trap=list, it could be useful to get a
backtrace for the fpe as well. Currently, the only output on fpe is Floating
point exception (or similar), which in itself isn't very helpful.
--
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-15 15:17 ---
*** This bug has been marked as a duplicate of 31189 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-15 15:17 ---
*** Bug 31936 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-15 15:33 ---
This code has been removed in 4.3.0 anyways as the java source parser is gone.
Only the bytecode parser exists on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31932
--- Comment #47 from manu at gcc dot gnu dot org 2007-05-15 16:15 ---
(In reply to comment #46)
I've been looking at this again recently. I have a patch that changes
dg-error
and dg-warning only for languages that define gcc_error_prefix and
gcc_warning_prefix. I have tested it
PowerPC CPU without FPU (such as the PPC405EP) doesn't pass the libffi
testsuite. Most of the tests crash with an illegal instruction error message,
even those that don't manipulate double/float. For instance, it crashes with
the cls_uint test.
After investigating, I think the problem comes from
Casting a 32 bit integer to a 16 bit integer on armeb with -Os causes the
compiler to generate wrong code.
Short sample:
int foo = 4;
int blah()
{
int bar;
bar = (unsigned short)foo;
return bar;
}
This function returns 0 when compiled with -Os on GCC 4.2.0, -Os on
--- Comment #9 from dberlin at gcc dot gnu dot org 2007-05-15 16:51 ---
Each one of thousands of temporary variables ends up with 12000 fields.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #29 from niemayer at isg dot de 2007-05-15 16:54 ---
That's sad - while memory gets cheaper, it has still not become cheap enough to
cope with that huge increase in memory usage imposed by gcc 4.2. Seems I have
to stick with 4.1 until that problem is fixed...
--
--- Comment #30 from pluto at agmk dot net 2007-05-15 17:04 ---
looks like related to PR30052.
--
pluto at agmk dot net changed:
What|Removed |Added
CC|
--- Comment #3 from serg at vostok dot net 2007-05-15 17:29 ---
(In reply to comment #2)
This code has been removed in 4.3.0 anyways as the java source parser is
gone.
Only the bytecode parser exists on the trunk.
That still means 4.1 and 4.2 branches can be fixed.
Also not only
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-15 17:31 ---
Created an attachment (id=13558)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13558action=view)
Patch
Since PR 30498 is fixed, gfortran supports backtraces. However, they are only
displayed for library
Conversion to UCS-2 encoding in GNU libiconv returns bytes in network
order. gcj wants to have them in host order. The hack in libgcj swaps bytes
when necessary. However, command line arguments slip by the swapper (or
go through it even number of times).
This produces unrecognizable for a program
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-05-15 17:47 ---
(In reply to comment #8)
My recommendations are to document, in the description of test directives in
the GCC Internals manual, that xfail for dg-do is only honored for dg-do run
and ignored for other keywords,
With gcc 4.1.2, this short code:
void f1(int);
void f2(int x)
{
if (x != -2147483647 - 1)
f1(-x);
}
causes GCC to segfault.
$ gcc/bin/gcc -c -O -ftree-vrp -ftrapv trapv-ice.c
trapv-ice.c: In function #8216;f2#8217;:
trapv-ice.c:3: internal compiler error: Segmentation fault
Please
--- Comment #1 from serg at vostok dot net 2007-05-15 18:05 ---
This bug is relevant only for iconv that have the UCS-2 encoding with byte
order different from native byte order of the platform, e.g. GNU libiconv on
i386.
There are actually two subjects here.
1. Fix source code to use
--- Comment #2 from serg at vostok dot net 2007-05-15 18:11 ---
Created an attachment (id=13559)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13559action=view)
A hack to use UCS-2-INTERNAL instead of plain UCS-2
For subject 1.
Works only for those who actually have
--- Comment #3 from serg at vostok dot net 2007-05-15 18:33 ---
For subject 1.
Can java/gcj even be used without iconv in general?
Considering that java.io.File assumes all file names in OS are encoded in UTF-8
and java.String stores it's data in UCS-2 (UTF-16), the answer should be
With the attached source, 4.0 prints and error and then says that it got
confused by earlier errors. In 4.1 and 4.2, however, it gets confused
without actually printing the earlier error:
[EMAIL PROTECTED]:~$ g++-4.0 -c digikam-libmetadatawidgets.ii
--- Comment #1 from tbm at cyrius dot com 2007-05-15 18:38 ---
Created an attachment (id=13560)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13560action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
--- Comment #2 from tbm at cyrius dot com 2007-05-15 18:40 ---
This is on ia64. Apparently x86_64 shows an error. Can someone confirm what
I see on ia64?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
On hppa, using either of the following gcc's (Debian sid and Ubuntu feisty):
gcc version 4.1.3 20070429 (prerelease) (Debian 4.1.2-6)
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4hppa1)
results in the following:
% cat xx.c; gcc -pie -fPIC -fPIE xx.c ./a.out
int main(int n,const**p) { ; return
--- Comment #48 from janis at gcc dot gnu dot org 2007-05-15 19:29 ---
Created an attachment (id=13561)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13561action=view)
patch for testsuite infrastructure
This patch overrides dg-error and dg-warning if gcc_error_prefix and
--- Comment #4 from pcarlini at suse dot de 2007-05-15 19:30 ---
I don't think libstdc++ (the C++ runtime library) has anything to do with this.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2007-05-15 19:41 ---
The patch is incomplete, as libcpp/configure.in still checks for iconv.h.
Anyway the best thing to do here is submit a patch or patches to the
gcc patch list. Include a ChangeLog entry, etc.
--
tromey at gcc
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-15 19:43 ---
libcpp is the C PreProcessor (not the standard C++ library).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-15 19:44 ---
THis is more likely the dyanmic load's fault rather than GCC's.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31942
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-15 20:06 ---
Paul thanks for your patch :)
Nonetheless, I found that this is a problem that should be addressed more
globally. I have a proposal that fixes PR31919, PR31329 and PR31930 (probably
together with many other, yet
--- Comment #7 from serg at vostok dot net 2007-05-15 20:08 ---
Created an attachment (id=13562)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13562action=view)
Removes HAVE_ICONV_H from source code.
Added libcpp/configure and libcpp/configure.ac to the patch.
--
serg at
--- Comment #8 from serg at vostok dot net 2007-05-15 20:34 ---
(In reply to comment #6)
libcpp is the C PreProcessor (not the standard C++ library).
Thanks. Now I know how to expose the bug here as well. It's -f*-charset options
of cpp.
--
serg at vostok dot net changed:
--- Comment #4 from patchapp at dberlin dot org 2007-05-15 21:05 ---
Subject: Bug number PR31919
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01003.html
--
--- Comment #9 from sje at cup dot hp dot com 2007-05-15 21:06 ---
I am going to close this defect as WORKSFORME. The bug can be reproduced with
124216 but is fixed in 124217 and later version. Whether the bug is really
fixed or became latent is not clear but it doesn't happen with
please look at the 32-bit asm. dump:
_Z3msby:
pushl %ebx
movl12(%esp), %edx
movl8(%esp), %eax
popl%ebx
movl%edx, %eax
xorl%edx, %edx
shrl$24, %eax
movzbl %al,%ecx
movzbl %cl, %eax
ret
wow!
--- Comment #1 from pluto at agmk dot net 2007-05-15 21:47 ---
Created an attachment (id=13563)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13563action=view)
sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31943
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-15 22:15 ---
Try with -fomit-frame-pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31943
--- Comment #3 from pluto at agmk dot net 2007-05-15 22:17 ---
(In reply to comment #2)
Try with -fomit-frame-pointer.
Andrew, please look at the makefile. -fomit.. is there already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31943
--- Comment #12 from rearnsha at gcc dot gnu dot org 2007-05-16 00:06
---
Confirmed fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
The file fs/ocfs2/dlm/dlmmaster.c from the 2.6.20 kernel triggers an endless
loop in gcc 4.1 built for the hppa64-linux-gnu target.
It occurs at -O2, but not at -O1 or -O0. Also specifying -fno-cse-follow-jumps
workaround the problem.
Thanks to Randolph Chung we have a reduced testcase:
struct
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-16 01:39
---
Fixed on trunk
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-05-16 01:38
---
Subject: Bug 31922
Author: jvdelisle
Date: Wed May 16 00:37:55 2007
New Revision: 124754
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124754
Log:
2007-05-15 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #5 from danglin at gcc dot gnu dot org 2007-05-16 04:11 ---
Nope. I'm not sure this is the same bug but the problem with
constructors/destructors has got worse:
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
--- Comment #2 from danglin at gcc dot gnu dot org 2007-05-16 04:19 ---
See
http://lists.parisc-linux.org/pipermail/parisc-linux/2006-January/028072.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31942
--- Comment #69 from ian at airs dot com 2007-05-16 06:33 ---
Unless somebody feels strongly otherwise, I propose that we only fix this in
mainline (i.e., 4.3). Any fix is going to be delicate, this bug is unusual and
difficult to trigger, and there is a source code workaround.
--
--- Comment #17 from pault at gcc dot gnu dot org 2007-05-16 06:41 ---
Subject: Bug 18769
Author: pault
Date: Wed May 16 05:40:51 2007
New Revision: 124759
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124759
Log:
2007-05-16 Brooks Moses [EMAIL PROTECTED]
PR
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-16 06:41 ---
Subject: Bug 31194
Author: pault
Date: Wed May 16 05:40:51 2007
New Revision: 124759
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124759
Log:
2007-05-16 Brooks Moses [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-16 06:41 ---
Subject: Bug 30881
Author: pault
Date: Wed May 16 05:40:51 2007
New Revision: 124759
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124759
Log:
2007-05-16 Brooks Moses [EMAIL PROTECTED]
PR
--- Comment #2 from pault at gcc dot gnu dot org 2007-05-16 06:41 ---
Subject: Bug 31216
Author: pault
Date: Wed May 16 05:40:51 2007
New Revision: 124759
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124759
Log:
2007-05-16 Brooks Moses [EMAIL PROTECTED]
PR
--- Comment #10 from pault at gcc dot gnu dot org 2007-05-16 06:41 ---
Subject: Bug 31427
Author: pault
Date: Wed May 16 05:40:51 2007
New Revision: 124759
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124759
Log:
2007-05-16 Brooks Moses [EMAIL PROTECTED]
PR
70 matches
Mail list logo
