--- Comment #2 from irar at il dot ibm dot com 2008-12-11 08:02 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #8 from jv244 at cam dot ac dot uk 2008-12-11 08:27 ---
(In reply to comment #6)
Created an attachment (id=16881)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16881action=view) [edit]
memory measurement tool
Of course! Try the attached with just
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-11 08:45 ---
You do not to warn for:
void foo (int c)
{
int a;
switch (c)
{
foo:
a = 1;
break;
case 5:
goto foo;
}
}
(any label should stop the search).
You ICE on:
void foo (int c)
{
--- Comment #7 from jakub at gcc dot gnu dot org 2008-12-11 09:16 ---
Subject: Bug 38253
Author: jakub
Date: Thu Dec 11 09:15:17 2008
New Revision: 142674
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142674
Log:
PR c++/38253
* gimplify.c
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-11 09:17 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #16 from pault at gcc dot gnu dot org 2008-12-11 09:38 ---
Hah! My VMware Fedora catches the bug and demonstrates that my simple fix of
comment #5 does the job; ie. unconditionally do the constant fold to a
gfc_charlen_type_node. This can never do any harm!
I will fix it
--- Comment #17 from dominiq at lps dot ens dot fr 2008-12-11 10:00 ---
Hah! My VMware Fedora catches the bug and demonstrates that my simple fix of
comment #5 does the job; ie. unconditionally do the constant fold to a
gfc_charlen_type_node. This can never do any harm!
I have
--- Comment #6 from jakub at gcc dot gnu dot org 2008-12-11 10:02 ---
I think this should be P1. While a workaround (such as STAGE1_CFLAGS=-g -O1)
exists, not being able to bootstrap on a primary platform is very severe.
--
jakub at gcc dot gnu dot org changed:
What
--- Comment #4 from burnus at gcc dot gnu dot org 2008-12-11 10:12 ---
integer, dimension(:), pointer :: ipn
ipn=sorb%i%j
I tried it with ipn being no dummy argument and it crashes as well.
And I forgot to write the name of the initial reporter in comment 0. The credit
for
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2008-12-11 10:39
---
(In reply to comment #17)
var = gfc_create_var (TREE_TYPE (expr), NULL);
is replaced with
+ tree tmp = gfc_create_var (gfc_charlen_type_node, slength);
Has slength any chance to make a
--- Comment #5 from pault at gcc dot gnu dot org 2008-12-11 10:52 ---
Tobias,
It's a bit tough to call it a regression, since the earlier versions of
gfortran produced wrong code.
Is this worth fixing for 4.4? If we get the array descriptor business sorted
out, it should go away.
Here is the code:
#include iostream
struct Reader { virtual ~Reader() {} };
struct Writer: virtual Reader {};
void func(Reader *r)
{
std::cout dynamic_castWriter *(r) std::endl;
}
struct AccessorReader: virtual Reader {};
struct Accessor: AccessorReader, private Writer {};
int main()
{
--- Comment #2 from J dot J dot vanderHeijden at gmail dot com 2008-12-11
11:07 ---
Subject: Re: Acats faillures due to undefined pthread_setrunon_np
On Wed, Dec 10, 2008 at 12:54 PM, laurent at guerby dot net
[EMAIL PROTECTED] wrote:
Could you try to add in gcc/ada/adaint.c the
The offending piece of code is pretty useless btw, even on IRIX 6.5.
The cpu# in question is always initialized in s-tasinf-irix.ads with
CPU_ANY so the end result is the same as when you wouldn't call
pthread_setrunon_np() at all. So my initial fix was to simply remove
this functionality
--- Comment #3 from charlet at adacore dot com 2008-12-11 11:15 ---
Subject: Re: Acats faillures due to undefined
pthread_setrunon_np
The offending piece of code is pretty useless btw, even on IRIX 6.5.
The cpu# in question is always initialized in s-tasinf-irix.ads with
--- Comment #6 from pault at gcc dot gnu dot org 2008-12-11 11:21 ---
This cures the ICE and allows correct code within the subroutine. 'span' is
not transferred in the call and so wrong code is produced if the pointer is
subsequently used in the caller.
I can apply it if you like.
--- Comment #1 from kristian dot spangsege at gmail dot com 2008-12-11
11:27 ---
Totally BOGUS - sorry!
--
kristian dot spangsege at gmail dot com changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-12-11 11:28 ---
I tried to reproduce this but ran into a different error on powerpc-linux:
/usr/src/packages/BUILD/gcc-4.4.0-20081204/obj-powerpc64-suse-linux/./gcc/xgcc
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-12-11 11:33 ---
The script only has received testing on linux systems, so if you are running
somewhere else it is likely that either the regexps do not match or that
you require different/additional syscalls to be traced. It's not
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-11 11:35 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-12-11 11:41 ---
Lowering priority - this is not a regression on the branches and trunk is fixed
now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-12-11 11:45 ---
Janis, can we have your regression hunting services to look what fixed this
on the mainline?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jv244 at cam dot ac dot uk 2008-12-11 12:02 ---
(In reply to comment #9)
The script only has received testing on linux systems, so if you are running
somewhere else it is likely that either the regexps do not match or that
you require different/additional
=athlon64 --disable-multilib
--enable-__cxa_atexit --enable-libada --enable-gtk-cairo
--enable-libgcj-multifile --with-long-double-128 --disable-nls
Thread model: posix
gcc version 4.4.0 20081211 (experimental) (GCC)
The problem is at line 9355 of the .ii: (comment it out and it works)
void
--- Comment #1 from gcc at spatium dot org 2008-12-11 12:35 ---
Created an attachment (id=16883)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16883action=view)
the faulty .ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38485
--- Comment #33 from ebotcazou at gcc dot gnu dot org 2008-12-11 12:44
---
Eric, you would add a blurb about that in the platform-specific installation
notes (comment #25). Did that happen?
No, it didn't, IIRC I wasn't sure of my analysis at all.
What do you, as a SPARC port
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-12-11 12:45
---
See PR 10353.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
When compiling the attached source code with -Wall -O3 -UWARN, no warning on
type punning is printed.
If I compile with -Wall -O3 -DWARN, a warning is printed.
ff.C:31: warning: dereferencing type-punned pointer will break strict-aliasing
rules
While in the attached example, everything seems to
--- Comment #1 from dominik dot strasser at onespin-solutions dot com
2008-12-11 12:57 ---
Created an attachment (id=16884)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16884action=view)
Source code which illustrates the problem.
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-11 13:16 ---
The complication is that we optimize the code into a form that no longer
violates aliasing rules which effectively disables the warning that happens
after inlining. IMHO we can issue alias warnings from the code
--- Comment #13 from paolo dot carlini at oracle dot com 2008-12-11 15:37
---
Hi HJ: I'm not sure to understand, you mean this is actually a C++ / compiler
bug?!?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Hi,
somewhere between gfortran 4.3.1 and 4.3.3/4.4.0 the following bogus warning
crept in:
% cat gfcbug82.f90
module gfcbug82
implicit none
type t
real, pointer :: q(:) =NULL()
real, pointer :: r(:) =NULL()
end type t
type (t), save :: x, y
contains
elemental subroutine add (q,
--- Comment #14 from hjl dot tools at gmail dot com 2008-12-11 15:41
---
(In reply to comment #13)
Hi HJ: I'm not sure to understand, you mean this is actually a C++ / compiler
bug?!?
I can't say if C++ standard requires
const_T1_reference
extract_key_imp(const_pair_reference
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-12-11 15:48
---
it's an rvalue, so a temporary is allowed (not sure if required). Using an
rvalue reference would be an option here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
To find out more about Twitter, visit the link below:
http://twitter.com/i/bd75f71ddaf51d2058c69ca2f6a44aa437b3ce72
Thanks,
-The Twitter Team
About Twitter
Twitter is a unique approach to communication and networking based on the
simple concept of status. What are you doing? What are your
To find out more about Twitter, visit the link below:
http://twitter.com/i/530c00e32b934bb17cc91435bb8c7859cdd509ac
Thanks,
-The Twitter Team
About Twitter
Twitter is a unique approach to communication and networking based on the
simple concept of status. What are you doing? What are your
To find out more about Twitter, visit the link below:
http://twitter.com/i/d8738f8074200dd9c1c74beab4022a559a34f664
Thanks,
-The Twitter Team
About Twitter
Twitter is a unique approach to communication and networking based on the
simple concept of status. What are you doing? What are your
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-11 16:07 ---
Mikael added this as part of PR 35681 with check in
http://gcc.gnu.org/viewcvs?view=revrevision=141931
See:
http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/dependency.c?r1=141931r2=141930pathrev=141931
I think the
/ 0.48852 sec CPU
average: 1.476243858 sec real / 0.25087 sec CPU
stdev : 0.222421870 sec real / 0.01019 sec CPU
$ ~/timing ./test-4.4 # 4.4.0 20081211
Strip out best and worst realtime result
minimum: 1.729227419 sec real / 0.21394 sec CPU
maximum: 1.746533792 sec real / 0.42904 sec CPU
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #10 from burnus at gcc dot gnu dot org 2008-12-11 16:13 ---
As fj pointed out: PR 38471 might be a duplicate of this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
--- Comment #16 from paolo dot carlini at oracle dot com 2008-12-11 16:17
---
At the moment, I don't know this code well enough, but note that:
typedef const pair const_pair_reference;
therefore, I don't really follow your reasoning. By the way, rvalrefs I don't
think are an
--- Comment #7 from burnus at gcc dot gnu dot org 2008-12-11 16:18 ---
Created an attachment (id=16885)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16885action=view)
pointer_assign_7.f90 - a test cae
As fj pointed out: This PR might be a duplicate of PR 34640. The patch looks
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-11 16:12
---
Hi. Given the specifications for uflow() (27.5.2.4.3/16), I don't see how this
code can work because I don't think *gptr() can work in this unbuffered case.
Can you explain in better detail what are you
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Priority|P3
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-11 16:31 ---
Testing a patch...
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from marbertone at gmail dot com 2008-12-11 16:36 ---
(In reply to comment #1)
a)
GNU Fortran (GCC) 4.4.0 20080603 (experimental) [trunk revision 136333]
Copyright (C) 2008 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by
--- Comment #3 from marbertone at gmail dot com 2008-12-11 16:38 ---
(In reply to comment #2)
Hello,
I attach you the problematic lines. Gfortran for windows doesn't work. It
crashes in the two cases (native and cygwin). I repeat, on linux it works
perfectly with gfortran. On Vista it
--- Comment #17 from paolo dot carlini at oracle dot com 2008-12-11 16:39
---
In any case, I don't really understand your snippet: you are comparing x.i to
t1.i, but x comes from p, and p *copies* t1 at construction time, in other
terms p.first.i != t1.i to begin with.
--
--- Comment #18 from hjl dot tools at gmail dot com 2008-12-11 16:46
---
(In reply to comment #17)
In any case, I don't really understand your snippet: you are comparing x.i to
t1.i, but x comes from p, and p *copies* t1 at construction time, in other
terms p.first.i != t1.i to
--- Comment #19 from hjl dot tools at gmail dot com 2008-12-11 16:49
---
1081{
1082 m_alloc.set_throw_prob(0);
1083 value_type v = test_traits::generate_value(m_g, m_m);
1084 m_alloc.set_throw_prob(m_tp);
1085 const_key_reference r_k =
int main() {
auto t = 0r;
}
Compile with -std=c++0x
error: fixed-point constants are a GCC extension
In function 'int main(int, char**)':
internal compiler error: in digest_init_r, at cp/typeck2.c:821
--
Summary: [c++0x] ICE in digest_init_r, at cp/typeck2.c:821 on
--- Comment #7 from hjl dot tools at gmail dot com 2008-12-11 17:20 ---
It is fixed by revision 133519:
http://gcc.gnu.org/ml/gcc-cvs/2008-03/msg00738.html
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01285.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-11 17:25 ---
That looks very invasive for the branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
--- Comment #8 from mmitchel at gcc dot gnu dot org 2008-12-11 17:27
---
Richard --
This is still marked as a 4.2/4.3 regression. So, why shouldn't this remain P1
for 4.3?
Thanks,
-- Mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37971
--- Comment #5 from hjagasia at gcc dot gnu dot org 2008-12-11 17:27
---
Subject: Bug 38446
Author: hjagasia
Date: Thu Dec 11 17:26:28 2008
New Revision: 142685
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142685
Log:
2008-12-11 Harsha Jagasia harsha.jaga...@amd.com
--- Comment #20 from hjl dot tools at gmail dot com 2008-12-11 17:33
---
We created a temporary because
(gdb) bt
#0 pairconst __gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type (
this=0x7fffc6c0, _...@0x7fffc750)
at
--- Comment #64 from mmitchel at gcc dot gnu dot org 2008-12-11 17:37
---
I agree that the most practical short-term solution is to avoid transforming
the loop into a division.
However, I'm also interested in what we think the right long-term solution is.
I'm not convinced that our
--- Comment #21 from hjl dot tools at gmail dot com 2008-12-11 17:57
---
Here is a new testcase:
[...@gnu-6 37144]$ cat y.cc
#include stdlib.h
#include stdio.h
struct T1
{
int i;
T1 () { i = 0; }
T1 (int x) { i = x; }
T1 (const T1 x) { i = x.i; }
T1
operator=(T1 __p)
--- Comment #22 from paolo dot carlini at oracle dot com 2008-12-11 18:13
---
Therefore, are you coming to the conclusion that something in the testing
infrastructure is wrong (mismatched types), *not* in the ext/pb_ds code itself?
--
--- Comment #23 from hjl dot tools at gmail dot com 2008-12-11 18:32
---
I am testing this patch:
Index: testsuite/util/regression/trait/assoc/type_trait.hpp
===
--- testsuite/util/regression/trait/assoc/type_trait.hpp
--- Comment #13 from danglin at gcc dot gnu dot org 2008-12-11 18:35
---
Subject: Bug 35677
Author: danglin
Date: Thu Dec 11 18:33:48 2008
New Revision: 142687
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142687
Log:
PR testsuite/35677
* emutls.c
--- Comment #24 from hjl dot tools at gmail dot com 2008-12-11 18:39
---
Created an attachment (id=16886)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16886action=view)
A patch
John, can you try this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-11
18:47 ---
Subject: Re: A bug in
include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
John, can you try this patch?
Later, this evening.
Dave
--
--- Comment #26 from hjl dot tools at gmail dot com 2008-12-11 18:49
---
(In reply to comment #22)
Therefore, are you coming to the conclusion that something in the testing
infrastructure is wrong (mismatched types), *not* in the ext/pb_ds code
itself?
--- Comment #27 from paolo dot carlini at oracle dot com 2008-12-11 18:55
---
Ah, yes, that, I saw it some time ago. Thus, the patch you and John are testing
(which makes sense, first blush) avoids failures in normal mode, but in fact
another, latent, issue is uncovered in DEBUG_MODE?
--- Comment #28 from hjl dot tools at gmail dot com 2008-12-11 18:58
---
(In reply to comment #27)
Ah, yes, that, I saw it some time ago. Thus, the patch you and John are
testing
(which makes sense, first blush) avoids failures in normal mode, but in fact
another, latent, issue is
I just tried to compile the package Coin-2.5.0-1.pm.3
with the GNU C++ compiler version 4.4 snapshot 20081205.
The compiler said
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
The preprocessed source
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-11 18:58 ---
Change subject line.
Reduced test case
troutmask:sgk[204] cat pr38312.f90
SUBROUTINE S1(t1,t2,c0,n)
REAL :: t1(n),c0(n)
INTEGER :: i,j,k
DO i=1,n
co(i)=t1(i)*2
ENDDO
END SUBROUTINE S1
--
--- Comment #4 from kargl at gcc dot gnu dot org 2008-12-11 18:59 ---
*** Bug 37793 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dcb314 at hotmail dot com 2008-12-11 19:02 ---
Created an attachment (id=16887)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16887action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38490
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-11 18:59 ---
PR 38312 has a short testcase.
*** This bug has been marked as a duplicate of 38312 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-11 19:16 ---
fixed with the current graphite branch.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-11 19:17 ---
I can't reproduce it with gcc 4.4 revision 142654 on Linux/x86-64.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #8 from jv244 at cam dot ac dot uk 2008-12-11 19:19 ---
(In reply to comment #7)
with current graphite, i see 4 files failing with -fgraphite
-fgraphite-identity:
lebedev.F, colvar_types.F, qs_linres_nmr_shift.F, constraint_clv.F
all fixed with current graphite
--- Comment #6 from spop at gcc dot gnu dot org 2008-12-11 19:37 ---
Subject: Bug 38446
Author: spop
Date: Thu Dec 11 19:35:41 2008
New Revision: 142688
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142688
Log:
2008-12-11 Harsha Jagasia harsha.jaga...@amd.com
PR
--- Comment #12 from spop at gcc dot gnu dot org 2008-12-11 19:37 ---
Subject: Bug 38459
Author: spop
Date: Thu Dec 11 19:35:41 2008
New Revision: 142688
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142688
Log:
2008-12-11 Harsha Jagasia harsha.jaga...@amd.com
PR
--- Comment #7 from spop at gcc dot gnu dot org 2008-12-11 19:39 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from hjl at gcc dot gnu dot org 2008-12-11 19:49 ---
Subject: Bug 38006
Author: hjl
Date: Thu Dec 11 19:48:16 2008
New Revision: 142689
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142689
Log:
2008-12-11 H.J. Lu hongjiu...@intel.com
PR libgcj/38006
--- Comment #9 from jakub at gcc dot gnu dot org 2008-12-11 19:55 ---
Created an attachment (id=16888)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16888action=view)
gcc43-pr37582.patch
Given:
// N.B. The conversions to bool are needed due to the issue
// explained in
--- Comment #5 from spop at gcc dot gnu dot org 2008-12-11 19:57 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #13 from spop at gcc dot gnu dot org 2008-12-11 19:58 ---
Subject: Bug 38459
Author: spop
Date: Thu Dec 11 19:57:18 2008
New Revision: 142690
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142690
Log:
2008-12-11 Sebastian Pop sebastian@amd.com
PR
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-11 19:59 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from paolo dot carlini at oracle dot com 2008-12-11 20:04
---
(In reply to comment #9)
So, either IMHO we should cast to bool there, or as done in this patch
use __traitor instead.
For the branch, I pre-approve a patch adding and using __traitand.
--
--- Comment #1 from spop at gcc dot gnu dot org 2008-12-11 20:04 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from spop at gcc dot gnu dot org 2008-12-11 20:13 ---
All testcases work on trunk rev 142690 and on graphite branch with
-O2 -floop-block,
-O2 -fgraphite-identity
-O2 -fgraphite
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-11 20:17 ---
For some reason, init_flag in gfc_match_iterator is set to zero.
So when the matcher hits
m = init_flag ? gfc_match_init_expr (e1) : gfc_match_expr (e1);
gfc_match_expr() is executed instead of
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 20:16 ---
Trunk compiles Polyhedron with
-O2 -fgraphite-identity,
-O2 -floop-block.
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jv244 at cam dot ac dot uk 2008-12-11 20:17 ---
Unfortunately, '-fgraphite -fgraphite-identity -floop-block -floop-strip-mine
-floop-interchang' goes generate an executable, but it is miscompiled and
segfaults.
It can be reproduced with the testcase in the initial
--- Comment #2 from spop at gcc dot gnu dot org 2008-12-11 20:20 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-11 20:21 ---
Subject: Bug 38413
Author: spop
Date: Thu Dec 11 20:19:54 2008
New Revision: 142691
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142691
Log:
2008-12-11 Sebastian Pop sebastian@amd.com
PR
--- Comment #2 from spop at gcc dot gnu dot org 2008-12-11 20:21 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-11 20:32 ---
Created an attachment (id=16889)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16889action=view)
gcc43-pr37582.patch
Thanks for pointing the difference between || and , embarrassing.
--
jakub at gcc dot gnu
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-11 21:02 ---
Subject: Bug 38409
Author: spop
Date: Thu Dec 11 21:01:14 2008
New Revision: 142693
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142693
Log:
2008-12-11 Sebastian Pop sebastian@amd.com
PR
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 21:08 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 21:13 ---
I would consider this at a very low priority right now: I'm thus marking it as
enhancement level.
If you can get a fix for this one that would be great, otherwise let's fix this
one in GCC4.5.
Sebastian
--
spop at
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-12-11 21:22 ---
This is still active with gcc -cx-complex-rules:
bb 2:
foo (c);
D.2256 = (double) REALPART_EXPR c;
D.2258 = (double) IMAGPART_EXPR c;
if (ABS_EXPR D.2256 ABS_EXPR D.2258 != 0)
goto bb 3;
else
I just tried to compile the package geotiff-1.2.5-0.pm.1
with the GNU C++ compiler version 4.4 snapshot 20081205.
The compiler appears to get into a long or possibly infinite loop.
gcc -c -fstack-protector -Wall -fPIC -DCSV_DATA_DIR=\/usr/share/epsg_csv\ -I.
-I../geo_print.c./geo_print.c: In
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-11 21:28 ---
Still doesn't work with current trunk:
$ gcc -march=i386 -O2 -m32 hh.c
hh.c: In function 'foo':
hh.c:19: error: can't find a register in class 'GENERAL_REGS' while reloading
'asm'
hh.c:19: error: 'asm' operand has
--- Comment #1 from dcb314 at hotmail dot com 2008-12-11 21:30 ---
Created an attachment (id=16890)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16890action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38491
1 - 100 of 168 matches
Mail list logo
