--- Comment #12 from pault at gcc dot gnu dot org 2008-11-08 08:39 ---
Fixed on trunk and 4.3
Thanks for the report
Paul and Mikael
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pault at gcc dot gnu dot org 2008-11-08 08:40 ---
Subject: Bug 35820
Author: pault
Date: Sat Nov 8 08:38:42 2008
New Revision: 141707
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141707
Log:
2008-11-08 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-08 14:18 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2008-11-08 14:19 ---
Subject: Bug 37597
Author: pault
Date: Sat Nov 8 14:17:35 2008
New Revision: 141708
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141708
Log:
2008-11-08 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from danglin at gcc dot gnu dot org 2008-11-08 17:28 ---
(gdb) r
Starting program: /test/gnu/gcc/objdir/gcc/testsuite/gcc/builtin-apply4.xg
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-08 17:50 ---
(In reply to comment #2)
(In reply to comment #1)
...and this comes about because gfc_apply_interface_mapping is failing to add
the formal arguments to the new symbol used to evaluate expression for asz(y).
I
I have been using the last gfortran trunk snapshot (Nov 7, 2008), from
www.equation.com.
My matrix code is unable to converge using the -O3 flag. Unfortunately I can't
send the code so this is likely not very useful except for me to say that the
code generated through using -O3 did not work
When the pymol/layer0/Triangle.c source file is compiled with -O3 -fgraphite,
the gcc compiler in current gcc trunk (r141700) has the following ICE
Triangle.c: In function FollowActives:
Triangle.c:1436: internal compiler error: in build_graphite_scops, at
graphite.c:1852
Please submit a
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-08
18:45 ---
Created an attachment (id=16634)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16634action=view)
preprocessed source for Triangle.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38061
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-11-08
18:46 ---
This bug can be reproduced with the attached preprocessed source for Triangle.c
using the command...
gcc-Wmissing-prototypes -Wno-long-double -O3 -fgraphite -D_HAVE_LIBPNG
-D_PYMOL_MODULE -D_PYMOL_NUMPY
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-08
18:59 ---
Subject: Re: [4.4 Regression] __builtin_apply
failures
On Sat, 08 Nov 2008, danglin at gcc dot gnu dot org wrote:
0x40002b18 bar+120: std r0,10(r3)
0x40002b1c bar+124: ldd
is not privately mapped will not work. See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.
warning: Loadable segment .tbss outside of ELF segments
warning: Loadable segment .tbss outside of ELF segments
GNU C (GCC) version 4.4.0 20081108 (experimental) [trunk revision 141703
--- Comment #5 from grosser at gcc dot gnu dot org 2008-11-08 19:46 ---
Subject: Bug 37883
Author: grosser
Revision: 141599
Modified property: svn:log
Modified: svn:log at Sat Nov 8 19:46:18 2008
--
---
--- Comment #15 from grosser at gcc dot gnu dot org 2008-11-08 19:46
---
Subject: Bug 37833
Author: grosser
Revision: 141599
Modified property: svn:log
Modified: svn:log at Sat Nov 8 19:46:18 2008
--
---
--- Comment #16 from grosser at gcc dot gnu dot org 2008-11-08 19:50
---
Subject: Bug 37833
Author: grosser
Revision: 141600
Modified property: svn:log
Modified: svn:log at Sat Nov 8 19:50:32 2008
--
---
--- Comment #6 from grosser at gcc dot gnu dot org 2008-11-08 19:50 ---
Subject: Bug 37883
Author: grosser
Revision: 141600
Modified property: svn:log
Modified: svn:log at Sat Nov 8 19:50:32 2008
--
---
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-11-08
19:55 ---
The same problem is seen compiling pymol/layer3/Executive.c with -fgraphite
although in that case you have to regress to -O0 to eliminate the failure...
Executive.c: In function ExecutiveGetExtent:
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2008-11-08
19:56 ---
Created an attachment (id=16636)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16636action=view)
preprocessed source for Executive.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38061
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-11-08
19:59 ---
Compile line for Executive.i to reproduce the failure is...
gcc -Wmissing-prototypes -Wno-long-double -O3 -fgraphite -D_HAVE_LIBPNG
-D_PYMOL_MODULE -D_PYMOL_NUMPY -D_PYMOL_FINK -c -o Executive.o
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-11-08
20:04 ---
Created an attachment (id=16637)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16637action=view)
preprocessed source for champ.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38061
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-11-08
20:05 ---
Another example which produces this failure in pymol is contrib/champ/champ.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38061
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-11-08 20:19
---
The test pr35729.c also fails on hppa64-hp-hpux11.11.
Same on the SPARC.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-08 21:12 ---
Created an attachment (id=16638)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16638action=view)
A draft patch for the PR
This bootstraps and regtests on FC9/x86_i64
I'll clean it up tomorrow, add the
--- Comment #7 from danglin at gcc dot gnu dot org 2008-11-08 21:29 ---
It seems the insn to initialize reg:DI 69 is being emitted, but it appears
that it is done too early and gets lost.
Breakpoint 8, emit_insn (x=0x83fffdfc5c80)
at ../../gcc/gcc/emit-rtl.c:4415
4415 rtx
--- Comment #8 from danglin at gcc dot gnu dot org 2008-11-08 21:40 ---
It seems the insn to initialize reg:DI 69 is being emitted, but it appears
that it is done too early and gets lost.
No, it's not lost. Insn 27 has been inserted before insn 2:
[...]
(insn 27 26 28 2
--- Comment #1 from ghazi at gcc dot gnu dot org 2008-11-08 21:44 ---
This bug is not darwin specific. it happens on x86-linux-gnu with -m32 AND
either -fpic or -fPIC. See:
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg00717.html
--
ghazi at gcc dot gnu dot org changed:
--- Comment #9 from danglin at gcc dot gnu dot org 2008-11-08 21:46 ---
This seems wrong:
/* Put the insns after the NOTE that starts the function.
If this is inside a start_sequence, make the outer-level insn
chain current, so the code is placed at the start of the
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-08 22:10 ---
1) Report your problem to www.equation.com. We have no idea
what changes may have been made to that distribution.
2) Yes, it is a useless bug report if you're not willing to
provide access to the code.
--
--- Comment #2 from rich dot otero at gmail dot com 2008-11-08 22:23
---
And they will just say that they built from the trunk on that date.
If I run across the compiler error without compiling over a MB of code; I'll
send it. Otherwise we'll both just have to live with it.
--
Executing on host: /xxx/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/
xxx/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/xxx/gnu/gcc/gcc/gcc/testsuite/
gfortran.dg/include_2.f90 -O -fpreprocessed -g3
-L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libgfortran/.libs
On IA32, operator new returns an address multiple of 8 in all cases, even if
called on a type with strict alignment (16).
typedef double double2 __attribute__ ((vector_size(16)));
int main() {
std::cout __alignof__(double2) ((void*) new double2)
std::endl;
}
returns:
16 0x8107008
--
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #6 from danglin at gcc dot gnu dot org 2008-11-09 00:59 ---
The same errors appear with gmp-4.2.4 and mpfr-2.3.2 built with
--enable-assert.
All tests pass with make check for both.
Breakpoint 1, 0x7aff9f40 in kill () from /usr/lib/libc.1
(gdb) bt
#0 0x7aff9f40 in kill ()
--- Comment #8 from danglin at gcc dot gnu dot org 2008-11-09 02:01 ---
(gdb) c
Continuing.
/xxx/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/integer_exponentiation_4.f90:9.12:
print *, 0**(-1) ! { dg-error Division by zero }
1
Error: Division by zero at (1)
--- Comment #2 from rbuergel at web dot de 2008-11-09 04:22 ---
ok, even for the case i misunderstood the proposal: there are still some
problems with it, making it unuseable.
enum class E { elem };
inline bool operator== (E c1, E c2)
{
return (int) c1 == (int) c2;
}
int
enum class E { elem };
int main()
{
E e = E::elem;
if (e == E::elem);
return 1;
}
g++ -std=c++0x tc1.cpp
tc1.cpp: In function 'int main()':
tc1.cpp:6: error: invalid operands of types 'E' and 'E' to binary 'operator=='
--
Summary: [c++0x] operator== doesn't
--- Comment #7 from danglin at gcc dot gnu dot org 2008-11-09 01:37 ---
(gdb) p *op1
$2 = {expr_type = EXPR_CONSTANT, ts = {type = BT_INTEGER, kind = 4,
derived = 0x0, cl = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN}, rank = 0, shape = 0x0, symtree = 0x0, ref =
--- Comment #9 from danglin at gcc dot gnu dot org 2008-11-09 02:06 ---
(gdb) p *op1-value.integer[0]._mp_d
$15 = 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584
--- Comment #10 from danglin at gcc dot gnu dot org 2008-11-09 02:20
---
It looks like ~ 256 MB is needed to hold the result of the power
operation being requested (2 ** 0x1fff). This is too much
for this machine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584
--- Comment #1 from rbuergel at web dot de 2008-11-09 04:11 ---
extended testcase, this fails for other operators, too
enum class E { elem };
int main()
{
E::elem == E::elem;
E::elem != E::elem;
E::elem E::elem;
E::elem = E::elem;
E::elem
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-11-09 07:46
---
According to the g77 documentation, system_clock uses the times(2) function.
gfortran uses either the time(2) (note no 's' on the end of the name) or the
gettimeofday function. When I revise the gfortran
41 matches
Mail list logo
