--- Comment #4 from cnstar9988 at gmail dot com 2007-07-20 07:31 ---
On HPPA64, there are some warning.
/home/beans/gcc-build/build/./gcc/xgcc -B/home/beans/gcc-build/build/./gcc/
-B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/bin/
-B/opt/gcc-4.2.1/lp64/hppa64-hp-hpux11.11/lib/ -isystem
This meta-bug tries to list all rejects-valid and ice-on-valid-code that can be
triggered with standard Fortran 95 conforming code, are not arch specific, and
can not reasonably be called a limit of the compiler. In full agreement with
pault, I think fixing these should be a priority.
--
Hi!
I have lately been unable to build Gcc from developpment sources under SGI
Irix: it fails at bootstrap with
[...]
rm -f stage_current
make[3]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
--- Comment #1 from jv244 at cam dot ac dot uk 2007-07-20 08:20 ---
only 1 open since 2005, 2 open since 2006, others are 2007.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
--- Comment #15 from uros at gcc dot gnu dot org 2007-07-20 09:44 ---
Subject: Bug 19910
Author: uros
Date: Fri Jul 20 09:43:52 2007
New Revision: 126799
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126799
Log:
PR tree-optimization/19910
* gcc.dg/pr19910.c: New
This is Fedora 7.
$ gcj -v
Using built-in specs.
Reading specs from /usr/lib/gcc/i386-redhat-linux/4.1.2/libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--- Comment #1 from artem at bizlink dot ru 2007-07-20 10:00 ---
In fact, I have two cores with this infinite loop, and they both are very
large:
$ l
total 304808
drwxr-xr-x 2 artemgr artemgr 4096 2007-07-20 11:58 ./
drwxr-xr-x 8 artemgr artemgr 4096 2007-07-20 11:57 ../
copy of my mail
http://gcc.gnu.org/ml/gcc/2007-07/msg00515.html
The test gcc.dg/pragma-darwin.c fails with
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 15)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 16)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 17)
FAIL:
--- Comment #1 from ro at gcc dot gnu dot org 2007-07-20 10:28 ---
As of r126744, I observe the same problem. With ada included, I get two
additional differences:
./ada/b_gnat1.o differs
./ada/b_gnatb.o differs
My last successful mainline bootstrap was on 20070622, on 20070702 it
--- Comment #2 from artem at bizlink dot ru 2007-07-20 10:38 ---
In fact, I have two cores with this infinite loop,
and they both are very large
12 mb when compressed with p7zip, so I can still deliver upon request.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
--- Comment #2 from P dot Schaffnit at access dot rwth-aachen dot de
2007-07-20 10:55 ---
This is actually known (I missed it...): see Richard Sandiford's answer at
http://gcc.gnu.org/ml/fortran/2007-07/msg00389.html
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32835
--- Comment #3 from artem at bizlink dot ru 2007-07-20 11:27 ---
To clarify:
this is a buffer overflow, catched by the GCJ SIGSEGV handler.
GCJ then tries to build a strack trace, but stack is obviously broken.
Still, it's not pretty that GCJ goes into an infinite loop via SIGSEGV
--- Comment #4 from artem at bizlink dot ru 2007-07-20 11:34 ---
I think the best JVM-compatible action then would be to shutdown the failed
thread, but let the other threads continue...
--
artem at bizlink dot ru changed:
What|Removed |Added
--- Comment #5 from artem at bizlink dot ru 2007-07-20 11:39 ---
I think the best JVM-compatible action then would be
to shutdown the failed thread,
but let the other threads continue...
E... I wasn't really going to post this. Forgot to clear the textarea.
Sorry.
I don't think
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-07-20 11:48
---
For current mainline I get (-O2)
foo:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %ecx
movl12(%ebp), %edx
popl%ebp
movl8(%ecx,%edx,4), %eax
When using nested functions, the trampoline code will destroy register 9 while
loading the static chain. This is even noted in gcc/config/arm/arm.h:
XXX FIXME: When the trampoline returns, r8 will be clobbered.
(it will be r9 and not r8...).
The attached patch avoids clobbering r9.
--
--- Comment #1 from leo at marco dot de 2007-07-20 11:53 ---
Created an attachment (id=13943)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13943action=view)
fix for the reported bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
--- Comment #15 from zippel at gcc dot gnu dot org 2007-07-20 11:58 ---
In the examples I used -fomit-frame-pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
--- Comment #2 from CyrusOmega at gmail dot com 2007-07-20 11:56 ---
Subject: Re: Seg fault on member function that does not return a val
Is there ANY case where this action would NOT result in a segfault!?
Specifically, it is segfaulting because something is being freed that
was
--- Comment #2 from leo at marco dot de 2007-07-20 11:55 ---
(In reply to comment #0)
I forgot to mention that this happens only for thumb mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Yesterday, one of my collegues ran into an internal compiler error when playing
with some template code.
Although she ran into the ICE on Mac OS X with an Apple gcc 4.01 build, it was
easy enough to reproduce it on a linux box with a GNU gcc build. I'm logging
this against 4.2.1, but it seems
--- Comment #1 from danny dot boelens at artwork-systems dot com
2007-07-20 12:41 ---
Created an attachment (id=13944)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13944action=view)
Test case that triggers the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32839
--- Comment #2 from brian dot sidebotham at gmail dot com 2007-07-20 13:16
---
Earlier in the build, I get a line which I've just noticed scanning through
some logs:
CONFIGURE:14040: test - Too many arguments
I suspect this is the cause of the problem, as it checks the version of as
--- Comment #3 from brian dot sidebotham at gmail dot com 2007-07-20 13:18
---
appologies, in my previous post:
CONFIGURE:14040: test - Too many arguments
should more accurately read -
${srcdir}/gcc/configure:14040: test - Too many arguments
--
--enable-targets=all --disable-werror --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
checking if /home/packages/gcc/snap/gcc-snapshot-20070720/build/./gcc/xgcc
-B/home/packages/gcc/snap/gcc-snapshot-20070720/build/./gcc/
-B/usr/lib/gcc-snapshot/i486-linux-gnu/bin/
-B/usr/lib/gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-20 14:54 ---
You need to set LD_LIBRARY_PATH to the correct location to include the newest
version of libgcc_s. libgcc_s is backwards compatiable but not fowards
compatiable.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #13 from aph at gcc dot gnu dot org 2007-07-20 15:11 ---
Do you have copyright assignment?
If you do, please submit these patches to [EMAIL PROTECTED] and
[EMAIL PROTECTED]
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from aph at gcc dot gnu dot org 2007-07-20 15:15 ---
Actually, forget that last message. Most of these patches seem to be gcc 4.2
based and the libffi and gij patches are already done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
--- Comment #10 from bonzini at gnu dot org 2007-07-20 15:47 ---
Andrew, could you make a C testcase maybe?...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-07-20 16:05
---
That makes it
foo:
movl4(%esp), %ecx
movl8(%esp), %edx
movl8(%ecx,%edx,4), %eax
addl4(%ecx,%edx,4), %eax
addl12(%ecx,%edx,4), %eax
ret
for me.
--- Comment #17 from zippel at gcc dot gnu dot org 2007-07-20 16:21 ---
Which claim?
It's exactly the third code example in comment #13
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-20 16:22 ---
Not architecture specific.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
GCC
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-07-20 16:35
---
I mean
cite
Current gcc finally produces:
*p = (a + 1) * 4;
*(p + 4) = (a + 2) * 4;
*(p + 8) = (a + 3) * 4;
movl8(%esp), %eax
movl4(%esp), %ecx
leal4(,%eax,4), %edx
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-20 16:41 ---
*** Bug 32816 has been marked as a duplicate of this bug. ***
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-20 16:41 ---
*** This bug has been marked as a duplicate of 28397 ***
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from patchapp at dberlin dot org 2007-07-20 16:43 ---
Subject: Bug number PR 30814
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-07/msg01597.html
--
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-07-20 16:42 ---
Should we open another PR for wrong-code errors?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
--- Comment #3 from jv244 at cam dot ac dot uk 2007-07-20 17:02 ---
(In reply to comment #2)
Should we open another PR for wrong-code errors?
no, I overlooked that keyword, and they belong to this category (though I'll
again ignore arch specific ones). I'll add them to the list
--- Comment #15 from s_j_newbury at yahoo dot co dot uk 2007-07-20 17:16
---
(In reply to comment #14)
Actually, forget that last message. Most of these patches seem to be gcc 4.2
based and the libffi and gij patches are already done.
I'm not sure what the current status of all
--- Comment #4 from jv244 at cam dot ac dot uk 2007-07-20 17:17 ---
from the 19 wrong code bugs I've only retained 8 that I judged as user visible,
F95, and triggered without additional options.
--
jv244 at cam dot ac dot uk changed:
What|Removed
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-07-20 17:22
---
Whoops ;) I missed that.
I have a counter-example that is better with the patch in the same way yours
is worse with it.
void f(unsigned int *p, unsigned int a)
{
p[0] = a * 4 + 4;
p[1] = a * 8 + 8;
p[2] =
--- Comment #19 from zippel at gcc dot gnu dot org 2007-07-20 17:06 ---
There is another small source example inbetween, which is used to produce all
code examples following it. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
--- Comment #3 from patchapp at dberlin dot org 2007-07-20 19:05 ---
Subject: Bug number PR32823
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-07/msg01601.html
--
--- Comment #6 from jv244 at cam dot ac dot uk 2007-07-20 19:35 ---
should one add a mingw maintainer to the CC?
BTW, this one misses the wrong-code keyword (and I don't have permission to add
it, which is annoying).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23272
--- Comment #1 from jv244 at cam dot ac dot uk 2007-07-20 19:55 ---
this misses rejects-valid keyword
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31265
Copy of http://gcc.gnu.org/ml/fortran/2007-07/msg00388.html
I have finally decided to give a shot to OSX 10.4 on my G5 and I do
see the edit_real_1.f90 failure. The culprit is:
write (s, '(1PE10.3,A)') huge(0d0), z
The follwoing reduced code:
! { dg-do run }
! Check real value edit
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-07-20 20:54
---
The WTITEing of Infinity is dependent on the following C code in io/write.c
res = isfinite (n);
if (res == 0)
So if the isfinite function is broken on this system, that would explain this
problem.
--- Comment #2 from dominiq at lps dot ens dot fr 2007-07-20 21:00 ---
Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on
Darwin8
Can you test with a C program to see if indeed this is the problem?
My knowledge of C it very limited, you know!-(
Could you send me some canvas to
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-20 21:01
---
Additional note: isfinite may be getting redefined in libgfortran.h
/* The isfinite macro is only available with C99, but some non-C99
systems still provide fpclassify, and there is a `finite' function
in
--- Comment #4 from dominiq at lps dot ens dot fr 2007-07-20 21:20 ---
Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on
Darwin8
I don't know if the following code is correct, but it returns 1:
#include math.h
#include stdio.h
int main()
{
double x;
x =
From the ISO_VARYING_STRING testsuite (vst_2.f90)
The following program prints an empty string instead of Hello.
PROGRAM VST_2
USE ISO_VARYING_STRING
IMPLICIT NONE
CHARACTER(LEN=5) :: char_arb(2)
type(VARYING_STRING) :: str_ara(2)
char_arb(1)= Hello
char_arb(2)= World
str_ara =
--- Comment #9 from chris at cdnorthamerica dot com 2007-07-20 21:22
---
This fails for me too on HPUX 11.11, gcc 4.1.1:
[EMAIL PROTECTED]:121uname -a
HP-UX wendy B.11.11 U 9000/785 1681839108 unlimited-user license
[EMAIL PROTECTED]:122make
/opt/hp-gcc64-4.1.1/bin/g++ -pthread
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-07-20 21:41
---
Try this:
#include stdio.h
#include stdlib.h
#include math.h
int
main ()
{
double x, y;
x = 1.79769313486231570814527423731704356798070567526e+308;
printf(%52.47e\n, x);
printf(isfinite = %d\n,
--- Comment #6 from dominiq at lps dot ens dot fr 2007-07-20 22:08 ---
Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on
Darwin8
Try this: ...
I get
1.79769313486231570814527423731704356798070567526e+308
isfinite = 1
isfinite = 0
There is something I don't understand:
in
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-07-20 22:21
---
Can you post the config.h file from your build directory?
blddir/archdir/libgfortran/config.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
--- Comment #8 from dominiq at lps dot ens dot fr 2007-07-20 22:28 ---
Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on
Darwin8
Can you post the config.h file from your build directory?
Unfortunately, it is gone (fink install) and I'll be away for two days.
So not before Monday
--- Comment #6 from patchapp at dberlin dot org 2007-07-21 04:44 ---
Subject: Bug number PR 32668
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-07/msg01594.html
--
59 matches
Mail list logo
