--- Comment #11 from spiridenok at tut dot by 2007-11-22 08:39 ---
Since when are or/and/xor C++ keywords?
(In reply to comment #1)
In C++ or is a keyword for |, so this is invalid.
Also the follow are keywords:
and
xor^
--
spiridenok at tut dot by changed:
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-22 08:56
---
Erik, Paul, as authors of the original patch and testcases, can you confirm my
conclusion that the code in comment #4 (and thus, the
gfortran.dg/alloc_comp_constructor_1.f90 testcase) is not legal, for the reason
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-22 09:09
---
It's not even MERGE-related:
$ cat a.f90
integer :: i(1) = 0
write(*,*) foo([1]+i)
end
$ gfortran a.f90
a.f90: In function MAIN__:
a.f90:1: internal compiler error: in gfc_trans_create_temp_array, at
--- Comment #11 from rsandifo at gcc dot gnu dot org 2007-11-22 09:28
---
Subject: Bug 33848
Author: rsandifo
Date: Thu Nov 22 09:27:55 2007
New Revision: 130344
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130344
Log:
gcc/
PR rtl-optimization/33848
* reload.c
--- Comment #12 from rsandifo at gcc dot gnu dot org 2007-11-22 09:30
---
Subject: Bug 33848
Author: rsandifo
Date: Thu Nov 22 09:30:02 2007
New Revision: 130345
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130345
Log:
gcc/testsuite/
PR rtl-optimization/33848
*
--- Comment #9 from pault at gcc dot gnu dot org 2007-11-22 09:30 ---
Note that I posted an example to comp.lang.fortran that fails because of this
bug:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6fea2c0227d1d430#657c2f8659a0024e
I'll get the patch submitted
--- Comment #13 from rsandifo at gcc dot gnu dot org 2007-11-22 09:32
---
Patch applied to 4.2. Mainline was already OK,
so only the testcase went there.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenther at suse dot de 2007-11-22 09:35 ---
Subject: Re: [4.3 Regression] SCCVN breaks
gettext
On Thu, 22 Nov 2007, dberlin at dberlin dot org wrote:
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-11-22 04:48
---
Subject: Re: [4.3
--- Comment #5 from markus dot heigl at fme dot fujitsu dot com 2007-11-22
09:39 ---
When trying to build a cross compiler with this patch I get following error:
dp-bit.c: In function â__muldf3â:
dp-bit.c:964: internal compiler error: in change_address_1, at emit-rtl.c:1783
build
I had trouble building firefox on alpha. In the first moment I thought it's a
binutils bug, since when I add --no-relax to ld, the build goes trough.
However, the produced result doesn't actually work.
In http://sources.redhat.com/bugzilla/show_bug.cgi?id=5276#c6, H.J.Lu tought it
might be a
--- Comment #9 from burnus at gcc dot gnu dot org 2007-11-22 09:56 ---
Subject: Bug 34079
Author: burnus
Date: Thu Nov 22 09:55:47 2007
New Revision: 130346
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130346
Log:
2007-11-22 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-22 10:11 ---
Testing a patch which does that.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-22 10:11 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from singler at gcc dot gnu dot org 2007-11-22 10:13 ---
Subject: Bug 33893
Author: singler
Date: Thu Nov 22 10:13:08 2007
New Revision: 130347
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130347
Log:
2007-11-22 Johannes Singler [EMAIL PROTECTED]
PR
--- Comment #2 from singler at gcc dot gnu dot org 2007-11-22 10:15 ---
Fixed by patch.
--
singler at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from singler at gcc dot gnu dot org 2007-11-22 10:22 ---
Subject: Bug 33893
Author: singler
Date: Thu Nov 22 10:22:08 2007
New Revision: 130348
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130348
Log:
Closing branch, corresponding patch to fix PR libstdc++/33893
gfortran -fdump-parse-tree crashes for the following program as
ts-cl == NULL for dump-parse-tree.c's gfc_show_typespec
case BT_CHARACTER:
gfc_show_expr (ts-cl-length);
break;
After disabling the gfc_show_expr if ts-cl == NULL, there is an internal error
shown unless one adds:
As reported by Chris:
For the following code, the bind(C) is ignored when calling the private
specific subroutine test via calling the generic procedure gen.
Result: The procedure test_ is called and the linker complains.
If one makes test public, it works. As -fdump-parse-tree shows (after
make[4]: *** [i686-pc-linux-gnu/bits/extc++.h.gch/O2g.gch] Error 1
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2
--- Comment #1 from rene at gsse dot at 2007-11-22 11:44 ---
Created an attachment (id=14601)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14601action=view)
config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34188
--
rene at gsse dot at changed:
What|Removed |Added
Severity|blocker |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34188
Hello all,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17.50, gcc-4.3-20071012, glibc-2.6) for Renesas SH target
I am facing problem while booting the Linux kernel on SH target.
Targets Used for Testing: SH7751R2D+ and SH7780 Highlander RP
I
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-22 11:56 ---
Some more debugging. The problem is that in gfc_conv_function_call /
gfc_sym_mangled_function_id of main, is_bind_c=1 but binding_label = '\0'.
Actually, already for gfc_search_interface, I get sym=test and bind=
In file included from
/iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/char_traits.h:48,
from
/iuehome/heinzl/Download/gcc-4.3-20071116_obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/string:47,
from
--- Comment #1 from rene at gsse dot at 2007-11-22 11:58 ---
Created an attachment (id=14602)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14602action=view)
config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34190
--- Comment #2 from rene at gsse dot at 2007-11-22 11:59 ---
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2
The gcc (at least versions 3.3.2 till 4.2.1) on Solaris 5.9 issues an internal
error message while compiling a trivial programme (attached):
[EMAIL PROTECTED]/usr/local/gcc-4.2.1/bin/gcc -v -mptr64 -W -Wall -Wextra
-pedantic -std=c99 -I. -o sizeof3 sizeof3.c
Using built-in specs.
Target:
--- Comment #1 from pmendez at orga-systems dot com 2007-11-22 12:10
---
Created an attachment (id=14603)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14603action=view)
Complete compiler output as required by the guidelines
Output from
/usr/local/gcc-4.2.1/bin/gcc -v -mptr64 -W
--- Comment #2 from pmendez at orga-systems dot com 2007-11-22 12:13
---
Created an attachment (id=14604)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14604action=view)
the preprocessed file (*.i*) that triggers the bug as required by the
guidelines
Please notice that when using
--- Comment #3 from pcarlini at suse dot de 2007-11-22 12:13 ---
This must be a Gentoo-only issue: literally tens if not hundreds of GCC
developers are daily bootstrapping multiple times on x86_64-linux and
everything works fine. I would suggest searching Bugzilla a little more, may
--- Comment #6 from rask at gcc dot gnu dot org 2007-11-22 12:31 ---
Created an attachment (id=14605)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14605action=view)
patch v1 for GCC 4.2.2
Here's a different patch which hopefully doesn't ICE on GCC 4.2.2.
--
--- Comment #7 from markus dot heigl at fme dot fujitsu dot com 2007-11-22
12:50 ---
Building with this patch produces following error.
Same build options as last time.
../../gcc-4.2.2/gcc/libgcc2.c: In function â__udivmoddi4â:
../../gcc-4.2.2/gcc/libgcc2.c:1054: error: insn does not
--- Comment #29 from pcarlini at suse dot de 2007-11-22 12:58 ---
*** Bug 34190 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2007-11-22 12:58 ---
*** This bug has been marked as a duplicate of 30915 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #25 from jakub at gcc dot gnu dot org 2007-11-22 13:05 ---
Don't see the point of keeping this bug open for the trunk:
with g++ -O2 -m32 pr25505.ii from #c1 on ppc64-linux
g++ 3.2.3
sed -n 's/^[[:blank:]]*stwu 1,//p' pr25505.s | sort -nur
-16(1)
-32(1)
-48(1)
-64(1)
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-22 13:06 ---
Current mainline shows the same symptoms. I didn't verify the regression is
fixed
by reverting r126198.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-11-22 13:18 ---
(In reply to comment #4)
The Intel and Sun compilers complain that this code is not legal, because you
can't do x = mytype(yy, bar) if yy is not allocated.
I cannot reproduce this with the Sun Compiler, only with
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-22 13:28 ---
Created an attachment (id=14606)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14606action=view)
patch doing TBAA pruning on the access site
But this patch makes the regression in the particular function go
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-22 13:29 ---
I'll make this just a non-regression enhancement PR for now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
PROGRAM test
WRITE(*,*) NEAREST(0.d0,1.d0)
END
gfortran test.f90
t.f90:3.21:
WRITE(*,*) NEAREST(0.d0,1.d0)
1
Error: Result of NEAREST underflows its kind at (1)
--
Summary: problem with NEAREST intrinsic function
Product: gcc
Version:
--- Comment #8 from rask at gcc dot gnu dot org 2007-11-22 13:54 ---
Created an attachment (id=14607)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14607action=view)
patch v2 for GC 4.2.2
Weird. I don't understand why GCC 4.2.2 is having problems with that. This
patch tries to fix
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-22 13:56 ---
Alternative patch posted:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01161.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from danglin at gcc dot gnu dot org 2007-11-22 13:57 ---
Currently, with the trunk on hppa64-hp-hpux11.11, we have an ICE:
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/obj-c++/../../g++
-B/test/
gnu/gcc/objdir/gcc/testsuite/obj-c++/../../
--- Comment #7 from matz at suse dot de 2007-11-22 13:58 ---
Subject: Re: [4.3 Regression] SCCVN breaks
gettext
Hi,
On Thu, 22 Nov 2007, dberlin at dberlin dot org wrote:
Right, but this is the optimistic set of hash tables, so that is okay.
I initially thought so too, but it
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-22 14:00 ---
If you go through the SCCVN dump you realize that Michas analysis of the
problem
is correct btw:
SCC consists of: nitems_21 nitems_1 new_max_9 dest_10 destptr_3 destptr.2_16
dest.3_17 D.1581_18 D.1582_19 nitems_20
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
--- Comment #1 from danglin at gcc dot gnu dot org 2007-11-22 14:01 ---
Also now failing on hppa64-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from matz at suse dot de 2007-11-22 14:03 ---
Subject: Re: [4.3 Regression] SCCVN breaks
gettext
[sorry for the breakage in last response]
It does not. The RPO algorithm (the one proven) uses hash table deletes
per iteration. About the SCC algorithm they have to
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-22 14:06 ---
Subject: Bug 34094
Author: jakub
Date: Thu Nov 22 14:06:06 2007
New Revision: 130351
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130351
Log:
PR c++/34094
* decl2.c
--- Comment #2 from danglin at gcc dot gnu dot org 2007-11-22 14:07 ---
Also, see these on hppa64-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-22 14:07 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from matz at gcc dot gnu dot org 2007-11-22 14:07 ---
Created an attachment (id=14608)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14608action=view)
my dump (without patch)
This is the dump I'm talking about. Richard uses a different compiler, so
our SSA version
--- Comment #2 from danglin at gcc dot gnu dot org 2007-11-22 14:08 ---
Execution fails on hppa64-hp-hpux11.11.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27232
--- Comment #1 from danglin at gcc dot gnu dot org 2007-11-22 14:10 ---
Also fails on hppa64.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
GCC build
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/obj-c++/../../g++
-B/test/
gnu/gcc/objdir/gcc/testsuite/obj-c++/../../
/test/gnu/gcc/gcc/gcc/testsuite/obj-
c++.dg/gnu-runtime-2.mm -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/
libstdc++-v3/include/hppa64-hp-hpux11.11
--- Comment #11 from matz at gcc dot gnu dot org 2007-11-22 14:13 ---
Btw. canonicalization/rewriting on INSERT is indeed okay. As long as the hash
tables are deleted after every iteration (or otherwise invalidated). At least
the now provably false information needs to be removed,
--- Comment #9 from danglin at gcc dot gnu dot org 2007-11-22 14:18 ---
Currently, obj-c++.dg/try-catch-9.mm fails with an ICE on hppa64-hp-hpux11.11:
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/obj-c++/../../g++
-B/test/
gnu/gcc/objdir/gcc/testsuite/obj-c++/../../
--- Comment #26 from dje at gcc dot gnu dot org 2007-11-22 14:52 ---
Shall we declare that we won't backport the changes and close the bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
--- Comment #5 from doko at gcc dot gnu dot org 2007-11-22 15:34 ---
Subject: Bug 34130
Author: doko
Date: Thu Nov 22 15:34:03 2007
New Revision: 130352
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130352
Log:
2007-11-22 Matthias Klose [EMAIL PROTECTED]
Backport from
--- Comment #13 from dberlin at gcc dot gnu dot org 2007-11-22 15:35
---
Subject: Re: [4.3 Regression] SCCVN breaks gettext
On 22 Nov 2007 14:03:35 -, matz at suse dot de
[EMAIL PROTECTED] wrote:
--- Comment #9 from matz at suse dot de 2007-11-22 14:03 ---
Subject:
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-11-22 15:32
---
I cannot reproduce this with
# g++ -c -O3 t.ii -v
Using built-in specs.
Target: ia64-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info
The following loop does not get vectorized
on powerpc64-linux, r130275, GCC 4.3.0:
#define M 10
struct S
{
float x;
float y;
} pS[100];
float a[1000];
float b[1000];
void
foo (int n)
{
int i, j;
for (i = 0; i n; i++)
{
pS[i].x = 0;
pS[i].y = 0;
for (j = 0; j
--- Comment #16 from rguenther at suse dot de 2007-11-22 15:24 ---
Subject: Re: [4.3 Regression] ICE verify_ssa
failed (missing definition for SSA_NAME)
On Thu, 22 Nov 2007, dorit at gcc dot gnu dot org wrote:
--- Comment #15 from dorit at gcc dot gnu dot org 2007-11-22 15:17
--- Comment #14 from dorit at gcc dot gnu dot org 2007-11-22 15:22 ---
closed, given recent feedback
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from dorit at gcc dot gnu dot org 2007-11-22 15:17 ---
(In reply to comment #12)
...
Richard, is this related to the issue you reported in
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01127.html
(looks like the same error)?
...
Yes, these are likely similar
--- Comment #14 from dorit at gcc dot gnu dot org 2007-11-22 15:14 ---
(In reply to comment #13)
Dorit, can you please take a look again?
I will not be able to look into this in the next couple of weeks, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
--- Comment #12 from rguenther at suse dot de 2007-11-22 15:08 ---
Subject: Re: [4.3 Regression] SCCVN breaks
gettext
On Thu, 22 Nov 2007, matz at gcc dot gnu dot org wrote:
--- Comment #11 from matz at gcc dot gnu dot org 2007-11-22 14:13 ---
Btw.
PROGRAM test
WRITE(*,*) NEAREST(0.d0,1.d0)
END
gfortran test.f90
t.f90:3.21:
WRITE(*,*) NEAREST(0.d0,1.d0)
1
Error: Result of NEAREST underflows its kind at (1)
--
Summary: problem with NEAREST intrinsic function
Product: gcc
Version:
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-22 15:19 ---
On the simplified:
extern int s;
void
foo (int *x, int y, int z)
{
int m, n;
int o;
int p = x[0];
o = s;
for (m = 0; m s; m++)
for (n = 0; n s; n++)
{
if (x[n] != p)
continue;
--- Comment #32 from jakub at gcc dot gnu dot org 2007-11-22 15:52 ---
Or alternatively make sure to gimplify all inputs which allow reg or mem
first, then gimplify those that don't allow either, which for -O0 should
hopefully mean all such expressions stay in the same basic block as
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-22 15:53 ---
*** This bug has been marked as a duplicate of 34192 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-22 15:53 ---
*** Bug 34194 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34192
--- Comment #18 from tbm at cyrius dot com 2007-11-22 15:58 ---
(In reply to comment #17)
neither with the original nor with the reduced testcase. Martin, can you
confirm that this is fixed?
Works for me with 20071116 too.
I just checked again and the problem is there with
--- Comment #9 from markus dot heigl at fme dot fujitsu dot com 2007-11-22
15:59 ---
Seems to work for this testcase.
I think the else path of if (reverse) should also be changed in the same way.
Do you agree?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-22 16:01 ---
Actually the refined patch at
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02550.html should be more
up-to-date.
Still the idea of an alias oracle needs to be done elsewhere. We'll be working
on it.
--
rguenth
--- Comment #31 from jakub at gcc dot gnu dot org 2007-11-22 15:41 ---
Could we perhaps for !optimize allow in ASM input operands arbitrary
tree expressions if TREE_CONSTANT for operands which !allows_mem
!allows_reg?
Then we'd just need to make sure the few -O0 passes are able to cope
--- Comment #19 from rguenther at suse dot de 2007-11-22 16:09 ---
Subject: Re: [4.3 Regression] ICE verify_ssa
failed (missing definition for SSA_NAME)
On Thu, 22 Nov 2007, tbm at cyrius dot com wrote:
--- Comment #18 from tbm at cyrius dot com 2007-11-22 15:58 ---
(In
#include string
template class _Tp class AutoPtr {
_Tp* _M_ptr;
public:
explicit AutoPtr(_Tp* __p = 0) : _M_ptr(__p) {}
~AutoPtr() { delete _M_ptr; }
_Tp* operator-() const {
return _M_ptr;
}
};
struct A {
virtual ~A();
virtual A * unserialise(const std::string s)
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-22 16:27 ---
Seemingly the problem was introduced by the following patch, which fixed
another NEAREST problem.
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00249.html
http://gcc.gnu.org/viewcvs?view=revrevision=117584
2006-10-09
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-22 16:11 ---
I believe there is indeed a bug in gfortran. The standard says that the the
nearest different machine-representable number is returned.
However, gfortran returns a number which is not representable (denormal or
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-22 16:41 ---
On x86_64-linux -m64 with -O2 gcc doesn't hoist movabsq insns out of the loops,
which can give some performance back:
time ./pr23305-slow
real0m4.028s
user0m4.023s
sys 0m0.003s
time ./pr23305-slow2
real
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-22 16:11 ---
On the trunk there is no difference between -O2 and -O2 -finline-functions
(the latter is perhaps 1% better), both are as bad as 4.1/4.2 with -O2
-finline-functions. Compiling with -O2 -fno-inline-small-functions
--- Comment #20 from tbm at cyrius dot com 2007-11-22 16:12 ---
The failure is gone.
--
tbm at cyrius dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-22 17:04 ---
The remaining difference is register allocation issue:
time ./pr23305-vanilla; time ./pr23305-fixed
real0m4.030s
user0m4.028s
sys 0m0.002s
real0m1.593s
user0m1.592s
sys 0m0.001s
with
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-22 17:08 ---
Regarding the range check: We need to disable the check for denormal numbers;
as overflow etc. cannot occur, this boils down to check only for NaN.
Regarding the result, I think we have a problem with MPFR. The
--- Comment #33 from stsp at users dot sourceforge dot net 2007-11-22
17:27 ---
For -O0 expecting
int i = 1;
asm ( :: i (i));
to work is certainly bad assumption
Btw, even the
static const int i = 1;
asm ( :: i (i));
doesn't work with both -O0 and -O1. :(
--
--- Comment #5 from burnus at gcc dot gnu dot org 2007-11-22 18:05 ---
Hmm, this does not seem to be easily possible in MPFR.
http://websympa.loria.fr/wwsympa/arc/mpfr/2007-11/msg00026.html
Possible implementation (as of 2005) by Tobias Schlüter:
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:45 ---
Created an attachment (id=14611)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14611action=view)
assembly file generated from testsub.f on i386-redhat-linux (Fedora 8)
--
--- Comment #1 from marcus at jet dot franken dot de 2007-11-22 18:48
---
Created an attachment (id=14612)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14612action=view)
relay16.i
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34197
--- Comment #21 from patchapp at dberlin dot org 2007-11-22 19:00 ---
Subject: Bug number PR16350
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-11/msg00362.html
--
--- Comment #10 from patchapp at dberlin dot org 2007-11-22 19:01 ---
Subject: Bug number PR34079
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-11/msg01109.html
--
--- Comment #3 from patchapp at dberlin dot org 2007-11-22 19:02 ---
Subject: Bug number PR c/23722
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-11/msg01159.html
--
--- Comment #2 from patchapp at dberlin dot org 2007-11-22 19:03 ---
Subject: Bug number PR34187
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-11/msg01165.html
--
--- Comment #7 from kargl at gcc dot gnu dot org 2007-11-22 19:00 ---
(In reply to comment #6)
Created an attachment (id=14609)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14609action=view) [edit]
Patch (reverted Rev 117584) plus test case
Initial implementation by reverting
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:54 ---
Created an attachment (id=14614)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14614action=view)
assembly file generated from testbd.f on i386-redhat-linux (Fedora 8)
--
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:42 ---
Created an attachment (id=14610)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14610action=view)
assembly file generated from testsub.f on i686-apple-darwin9
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-22 19:28 ---
The expression warned about is
call_5(D)-ret[5]
and I suspect the mapped locations make the location information wrong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:55 ---
Added assembly files from testbd.f for i386-redhat-linux and
i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2007-11-22
18:53 ---
Created an attachment (id=14613)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14613action=view)
assembly file generated from testbd.f on i686-apple-darwin9
--
LANG=C /home/marcus/projects/gcc/BIN/bin/gcc -c -O2 -Wall -g -o xx.o
relay16.i -m32
relay16.i: In function 'f':
cc1: warning: array subscript is above array bounds
-m32 seems necessary
--
Summary: array overflow warning without line number
Product: gcc
1 - 100 of 160 matches
Mail list logo
