On Linux/ia32, this patch
http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00336.html
caused
FAIL: libffi.call/return_sc.c -O0 -W -Wall execution test
FAIL: libffi.call/return_sc.c -O2 execution test
FAIL: libffi.call/return_sc.c -O3 execution test
--
Summary: [4.3 Regression] : libffi.cal
--- 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
--
http://gcc.gnu.org/bugzilla/s
--- 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 ev
--- 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 #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 libgfort
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-07-20 21:41
---
Try this:
#include
#include
#include
int
main ()
{
double x, y;
x = 1.79769313486231570814527423731704356798070567526e+308;
printf("%52.47e\n", x);
printf("isfinite = %d\n", isfinite(x));
printf("
--- 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]:121>uname -a
HP-UX wendy B.11.11 U 9000/785 1681839108 unlimited-user license
[EMAIL PROTECTED]:122>make
/opt/hp-gcc64-4.1.1/bin/g++ -pthread cras
>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
--- 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
#include
int main()
{
double x;
x = 1.7976931348623157081452742373170435679
--- 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 B
--- 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 star
--- 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.
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 descript
--- 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
--- 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 #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
--
http://gcc.gnu.org/bugzilla/sh
--- 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 #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 #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 #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 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 short
--- 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
--
http://gcc.gnu.org/bugzilla/s
--- 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 #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 #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 #18 from rguenth at gcc dot gnu dot org 2007-07-20 16:35
---
I mean
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:22 ---
Not architecture specific.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
GCC bui
--- 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 #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 #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 #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 #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 #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:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--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
--- 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
--
http://gcc.gnu.org/bugzilla/show_
--- 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
b
--- 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=13944&action=view)
Test case that triggers the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32839
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 ever
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywo
--- 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 never
--- 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
--- 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=13943&action=view)
fix for the reported bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
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 #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
--- 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 thin
--- 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 #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 handle
--- 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 #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 #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 alre
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: gcc.dg/pragm
--- 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 ../
-rw
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
--infodir=/usr/share/
--- 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=gcc&view=rev&rev=126799
Log:
PR tree-optimization/19910
* gcc.dg/pr19910.c: New
--- 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
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!
/fort
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.
--
--- 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
60 matches
Mail list logo
