--- 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=gcc&view=rev&rev=124759
Log:
2007-05-16 Brooks Moses <[EMAIL PROTECTED]>
PR fortra
--- 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=gcc&view=rev&rev=124759
Log:
2007-05-16 Brooks Moses <[EMAIL PROTECTED]>
PR fortran
--- 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=gcc&view=rev&rev=124759
Log:
2007-05-16 Brooks Moses <[EMAIL PROTECTED]>
PR fortran
--- 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=gcc&view=rev&rev=124759
Log:
2007-05-16 Brooks Moses <[EMAIL PROTECTED]>
PR fortran
--- 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=gcc&view=rev&rev=124759
Log:
2007-05-16 Brooks Moses <[EMAIL PROTECTED]>
PR fortra
--- 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 #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 #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/
gcc/objdir/gcc/testsuite/g++/../
--- 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
Assigne
--- 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=gcc&view=rev&rev=124754
Log:
2007-05-15 Jerry DeLisle <[EMAIL PROTECTED]>
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 #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
Sta
--- 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 #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 #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=13563&action=view)
sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31943
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 #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 the
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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 #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=13562&action=view)
Removes HAVE_ICONV_H from source code.
Added libcpp/configure and libcpp/configure.ac to the patch.
--
serg at vost
--- 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 unr
--- 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 #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 #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 dot
--- 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 #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=13561&action=view)
patch for testsuite infrastructure
This patch overrides dg-error and dg-warning if gcc_error_prefix and
gcc_warn
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) { ; retur
--- 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
--- 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=13560&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
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
/home/tbm/src/digikam-0.9.1/./digikam/libs/widg
--- 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 "NO
--- 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=13559&action=view)
A hack to use UCS-2-INTERNAL instead of plain UCS-2
For subject 1.
Works only for those who actually have UCS-2-INTERNA
--- 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 us
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 ‘f2’:
trapv-ice.c:3: internal compiler error: Segmentation fault
Please submit a ful
--- 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, r
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 #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=13558&action=view)
Patch
> Since PR 30498 is fixed, gfortran supports backtraces. However, they are only
> displayed for library er
--- 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 onl
--- 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 #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...
--
http://g
--- 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
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 4.1.2
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 fr
--- 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 i
--- 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 #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 #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
--
The option -fbacktrace gives a backtrace on various library and check errors.
If used in conjunction with -ffpe-trap=, 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 #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
--- 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 #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)
**
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 wi
--- 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
--
http://gcc.gnu.org/bugzilla/s
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 #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 comm
--- 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
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 /lib64
--- 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=13557&action=view)
Removes HAVE_ICONV_H from source code.
This should fix the bug. And, probably, some other problems with gcc not using
i
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 usel
--- 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=gcc&view=rev&rev=124741
Log:
2007-05-15 Tobias Burnus <[EMAIL PROTECTED]>
PR libf
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 al
--- 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 b
--- 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 (BROKE
--- 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 patc
F95, 7.1.5, Conformability rules for elemental operations
"An elemental operation is an intrinsic operation or a defined 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 allowed:
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];
_gfortran_set_
--- 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
-
--- 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(wo
--- 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
69 matches
Mail list logo