On Mon, 31 Mar 2008 15:46:52 +1000, Hasjim Williams
[EMAIL PROTECTED] said:
I don't think glibc compiles/runs if MaverickCrunch is enabled, because
of the lack of support in the glibc-2.5/ports/sysdeps/arm directory.
Yep, just tried building it again then... glibc-intermediate fails
Andrew Pinski [EMAIL PROTECTED] wrote on 31.03.2008 07:13:02:
On Fri, Mar 28, 2008 at 7:17 AM, Kai Tietz [EMAIL PROTECTED]
wrote:
Hello,
This testcase seems to be broken, because it will fail everytime for
the
static variable x. gcc detects, that this static variable has no
Till Straumann [EMAIL PROTECTED] writes:
/* Powerpc I/O barrier instruction */
#define EIEIO(pmem) do { asm volatile(eieio:=m(*pmem):m(*pmem)); }
while (0)
Looking closer, your asm statement has a bug. The m constraint can
match memory addresses with side effects (auto inc/dec), but the insn
Status
==
The GCC 4.2 branch is open for commits under normal release branch
rules. All fixes going on that branch should first have gone on trunk
and 4.3 branch.
GCC 4.2.4 was due around 2008-04-02, which we will miss by at least
a week. No release manager did yet volunteer to handle
Status
==
The GCC 4.3 branch is open for commits under normal release branch
rules.
GCC 4.3.1 is due around 2008-05-05. If a workaround for the
x86 direction flag issue is agreed and committed then 4.3.1-rc1
may come around a week after such a workaround is committed to the
branch, with
On Mon, 31 Mar 2008, Hasjim Williams wrote:
If someone can get iwmmxt support working in everything, then we might
be able to do the same for MaverickCrunch, since it is very similar work
to get one ARM coprocessor working as it is to get another working.
Half of the support for the iWMMXt
On Mon, Mar 31, 2008 at 11:19:29AM +0200, Andreas Schwab wrote:
Till Straumann [EMAIL PROTECTED] writes:
/* Powerpc I/O barrier instruction */
#define EIEIO(pmem) do { asm volatile(eieio:=m(*pmem):m(*pmem)); }
while (0)
Looking closer, your asm statement has a bug. The m constraint
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Mon, Mar 31, 2008 at 11:19:29AM +0200, Andreas Schwab wrote:
Till Straumann [EMAIL PROTECTED] writes:
/* Powerpc I/O barrier instruction */
#define EIEIO(pmem) do { asm volatile(eieio:=m(*pmem):m(*pmem)); }
while (0)
Looking closer, your
On Mon, Mar 31, 2008 at 03:06:24PM +0200, Andreas Schwab wrote:
The side effect is carried out by using %U0, which expands to u for a
PRE_{INC,DEC,MODIFY} operand. There is no way to encode that in the
insn operand itself, unlike m68k, for example. The ia64 target has a
similar issue.
OK,
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Mon, Mar 31, 2008 at 03:06:24PM +0200, Andreas Schwab wrote:
The side effect is carried out by using %U0, which expands to u for a
PRE_{INC,DEC,MODIFY} operand. There is no way to encode that in the
insn operand itself, unlike m68k, for example.
On 2008/3/30, Alexey Salmin [EMAIL PROTECTED] wrote:
There are issues of Garbage Collection from libgcc or Boehms's GC
that you possibly can't use another allocators that these defaults,
unless you have control of the manager of the whole memory,
and it's too complex due to the
Brian Austin wrote:
As some of you know, Cirrus is now out of the ARM business,. Officially
April 1st. (No joke). We still have however arm.cirrus.com.
What a great day to announce that. Is there an official announcement available
somewhere now? The company I work for is about to release
The libm patch is for uClibc.
-Original Message-
From: Hasjim Williams [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Martin Guy [EMAIL PROTECTED], [EMAIL PROTECTED], GCC
gcc@gcc.gnu.org
Subject: [linux-cirrus] Re: wot to do with the Maverick Crunch patches?
Date: Mon, 31 Mar 2008
Andreas Schwab wrote:
Till Straumann [EMAIL PROTECTED] writes:
/* Powerpc I/O barrier instruction */
#define EIEIO(pmem) do { asm volatile(eieio:=m(*pmem):m(*pmem)); }
while (0)
Looking closer, your asm statement has a bug. The m constraint can
match memory addresses with side
Andreas Schwab wrote:
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Mon, Mar 31, 2008 at 03:06:24PM +0200, Andreas Schwab wrote:
The side effect is carried out by using %U0, which expands to u for a
PRE_{INC,DEC,MODIFY} operand. There is no way to encode that in the
insn operand
Till Straumann [EMAIL PROTECTED] writes:
asm volatile (lwz %0, 16(%1):=r(val):b(base),m(*reg_p));
asm volatile (lwz%U1%X1 %0, %1:=r(val):m(*reg_p));
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key
J.C.,
Please stop harrassing people who, unlike you, are trying to contribute
to making GCC better. You were safe to ignore when you were merely
annoying. If you start driving contributors away, that will be a more
serious problem.
Alexey and everyone else,
It's best to ignore J.C. Pizarro.
Andreas Schwab wrote:
Till Straumann [EMAIL PROTECTED] writes:
asm volatile (lwz %0, 16(%1):=r(val):b(base),m(*reg_p));
asm volatile (lwz%U1%X1 %0, %1:=r(val):m(*reg_p));
Hmm - that is beyond me. What exactly do %U1 and %X1 mean?
I suspect that %U1 means that operand #1 is
Wirawan Purwanto wrote:
I tried to compile GCC 4.3.0 on a Red Hat Linux 9.0 box, it stopped at stage 1:
Compiling new gcc versions on old linux versions may not always work,
and is unlikely to be fixed. You are probably on your own here if you
run into a non-trivial problem.
Joe == Joe Buck [EMAIL PROTECTED] writes:
Joe It's best to ignore J.C. Pizarro. He's an attention-seeking troll,
Joe who has just enough technical knowledge to derail conversation.
I think that if we've reached the point where an SC member feels the
need to post disclaimers about someone's
Hello all. Late last year I posted a couple of questions about
multi-threaded application hangs in Solaris 10 for x86 platforms, and about
thread-safety of std::basic_string in general. This was an attempt to solve
persistent problems I have been experiencing with my application hanging due
Chad Attermann wrote:
Hello all. Late last year I posted a couple of questions about
multi-threaded application hangs in Solaris 10 for x86 platforms, and
about thread-safety of std::basic_string in general. This was an
attempt to solve persistent problems I have been experiencing with my
Chad Attermann [EMAIL PROTECTED] writes:
Hello all. Late last year I posted a couple of questions about
multi-threaded application hangs in Solaris 10 for x86 platforms, and
about thread-safety of std::basic_string in general. This was an
attempt to solve persistent problems I have been
The company I work for is about to release a board to PCB fab
with a Cirrus part on it. If this is the case we may want to hold back on
the
release and switch ARM parts.
If it's the EP93xx, you'd be well-advised to do so; I gather there is
one similar competitor that doesn't waste silicon
On Fri, 2008-03-28 at 17:10 -0500, Benjamin Kosnik wrote:
Still waiting on this...
How's this?
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/changes.html,v
retrieving revision 1.108
diff -u -r1.108 changes.html
Andrew Pinski wrote:
/src/gcc/local/gcc/gcc/cp/pt.c: In function 'subst_copy':
/src/gcc/local/gcc/gcc/cp/pt.c:9919: warning: 'len' may be used
uninitialized in this function
This was introduced by your patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01675.html
Please suggest a
Mohamed Shafi wrote:
For the source or the destination register Rd/Ra, the restriction is
that it should be one more than the base register . So the following
instructions are valid:
GCC doesn't provide any easy way for the source address to depend on the
destination address, or vice versa.
The libm patch is for uClibc.
This thread is now off-topic for the GCC list. Please take up the
discussion on a more appropriate list.
Thanks, Ben
Sergei Poselenov wrote:
I'm building a powerpc cross of gcc-4.2.2 on RH 7.2 host and ran into this:
RHL 7.2 is very old. It is unlikely that we can help you here.
The bug is very hardly reproducable; on FC6 I was unable to reproduce after
running test loop overnight.
If the bug isn't
How's this?
Hey Janis! Sorry, I missed your first email.
This looks great, thanks for your quick response. Can you check this
in? I filed 35777 about this, so this may fix that PR.
thanks,
benjamin
Index: changes.html
===
Christophe Avoinne wrote:
* How can I make coexist the SF mode between the FPU registers and
the VFPU registers in the argument list of a function ?
You probably don't want to use VFPU registers for argument passing.
That will complicate the ABI. If you really do, then you need two
Snapshot gcc-4.1-20080331 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080331/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Mon, 2008-03-31 at 16:47 -0500, Benjamin Kosnik wrote:
How's this?
Hey Janis! Sorry, I missed your first email.
This looks great, thanks for your quick response. Can you check this
in? I filed 35777 about this, so this may fix that PR.
I checked in the change to gcc-4.3/changes.html
Looks good to me.
Thanks,
Ben
On Mon, 31 Mar 2008 11:31:01 + (UTC), Joseph S. Myers
[EMAIL PROTECTED] said:
On Mon, 31 Mar 2008, Hasjim Williams wrote:
Joseph,
First of all thanks for replying to this e-mail. You seem to be the one
who has written most of the ARM coprocessor patches in the past, so
logically you're
On Tue, Apr 1, 2008 at 2:10 AM, Jim Wilson [EMAIL PROTECTED] wrote:
Mohamed Shafi wrote:
For the source or the destination register Rd/Ra, the restriction is
that it should be one more than the base register . So the following
instructions are valid:
GCC doesn't provide any easy way
On Tue, 01 Apr 2008 12:10:54 +1000, Hasjim Williams
[EMAIL PROTECTED] said:
gcc uses the code in unwind-arm.c etal to call the functions
(create_unwind_entry, unwind_save_mv etc) binutils gas/config/tc-arm.c
to do the frame unwinding, right? To do the unwind parsing (of table 4
from 9.3 in
Ian Lance Taylor [EMAIL PROTECTED] writes:
Chad Attermann [EMAIL PROTECTED] writes:
Hello all. Late last year I posted a couple of questions about
multi-threaded application hangs in Solaris 10 for x86 platforms, and
about thread-safety of std::basic_string in general. This was an
attempt
On Tue, 2008-04-01 at 09:48 +0530, Mohamed Shafi wrote:
What i did was to have 8 register class with each class having two
registers, an even register and an odd register then in define expand
look for the register indirect with offset addressing mode and emit
gen_store_offset or
Chad Attermann [EMAIL PROTECTED] writes:
I can not confirm that it was the i386 code included in the gcc build
but it appears that way from the signature. Is this perhaps a problem
with the way that gcc 3.4.3 shipping with Solaris 10 x86 was built?
Should it have opted for the i486 version
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-31 06:30 ---
retmeN is being miscompiled by SRA, at least for powerpc-darwin with a changed
MOVE_RATIO.
retmeN (x)
{
unnamed-unsigned:29 x$i;
unnamed-unsigned:23 x$j;
long long unsigned int SR.21;
bb 2:
x$j = x.j;
x$i
--- Comment #1 from herwig at gdsys dot de 2008-03-31 06:41 ---
Hi yuri,
I think, this is perfectly correct code and GCC is right in accepting it. First
of all, see Effective C++ issue 14 about the pure virtual destructor. Then
see here:
--- Comment #2 from yuriry at gmail dot com 2008-03-31 07:10 ---
Hi Björn,
Thank you for the link and setting me straight. You are correct,
implementation of a pure virtual function by the class that declares it makes
sense. It is just the class itself remains abstract.
Earlier today
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-31 09:46 ---
Fixed at least on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-31 09:46 ---
Subject: Bug 35431
Author: pinskia
Date: Mon Mar 31 09:45:53 2008
New Revision: 133749
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133749
Log:
2008-03-31 Andrew Pinski [EMAIL PROTECTED]
PR
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35650
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.2.0 |4.2.0 4.3.0
Priority|P3 |P2
--- Comment #16 from dominiq at lps dot ens dot fr 2008-03-31 10:12 ---
With patch from http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00824.html, the
failures for gcc.c-torture/compile/pr11832.c and
gcc.c-torture/compile/pr33009.c disappear on (powerpc|i686)-apple-darwin9, 32
and 64 bit
--- Comment #11 from manu at gcc dot gnu dot org 2008-03-31 11:03 ---
Actually as a user I would find clearer a warning such:
warning: initialization of 'signed char *' from incompatible pointer type 'char
*'
so CONFIRMED.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #8 from jakub at gcc dot gnu dot org 2008-03-31 11:11 ---
I think this shows that vector_size attribute can't be a late template
attribute whenever processing_template_decl, it can be only a late template
attribute if the decl is actually type or value dependent.
So I
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
CC||rwild at gcc dot gnu dot org
AssignedTo|unassigned at gcc dot
--- Comment #2 from schwab at suse dot de 2008-03-31 11:50 ---
Marking as regression.
--
schwab at suse dot de changed:
What|Removed |Added
Summary|gcc.c-
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-31 12:05 ---
Regressions should have a target milestone. Since when does this fail? Please
update the known to work and known to fail fields.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from schwab at suse dot de 2008-03-31 12:34 ---
The testcase from #35454 does not need -mcpu=5485 which did not exist in 4.2,
but is bigger.
--
schwab at suse dot de changed:
What|Removed |Added
The following example (which is a cut-down version of some code which passes a
std::auto_ptr through a forwarding function using boost::ref) compiles fine on
4.1.2 and 4.2.3, but fails on 4.3.0 with the error:
ap_ref.cc: In function 'void g(reference_wrapperauto_ptrX )':
ap_ref.cc:23: error: no
--- Comment #2 from oblivian at users dot sourceforge dot net 2008-03-31
13:06 ---
Ok, I've now recompiled about a million times with multiple sets of configure
flags and cannot get a stage 1 gcc to compile stage 2 ld correctly. I've got
some runs that exhibit the problem of infinite
--- Comment #6 from hjl at gcc dot gnu dot org 2008-03-31 13:33 ---
Subject: Bug 32000
Author: hjl
Date: Mon Mar 31 13:32:38 2008
New Revision: 133753
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133753
Log:
gcc/
2008-03-31 H.J. Lu [EMAIL PROTECTED]
PR target/32000
--- Comment #4 from hjl dot tools at gmail dot com 2008-03-31 13:49 ---
Reopen it since it is a different bug.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from rakdver at gcc dot gnu dot org 2008-03-31 14:20 ---
Subject: Bug 35729
Author: rakdver
Date: Mon Mar 31 14:19:52 2008
New Revision: 133755
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133755
Log:
PR rtl-optimization/35729
* loop-invariant.c
In the main function there is a cast casting int result to signed char.
typedef int int32_T;
typedef unsigned int uint32_T;
typedef signed char int8_T;
#include stdio.h
int main(void)
{
int32_T i;
uint32_T numerator;
for (i = 126; i 256; i++) {
numerator =
At -Os, the two popl %ebp instructions
in the alternate branches could have been collapsed.
$ cat tailcall.c
void foo(int a)
{
if (a)
bar();
else
baz();
}
$ gcc -Os -S tailcall.c
$ cat tailcall.s
.file tailcall.c
.text
.globl foo
.type foo, @function
--- Comment #2 from dominiq at lps dot ens dot fr 2008-03-31 15:14 ---
The dump shows:
rg0025 (lda, nf1, nf2, nf3, nf5, nf6, mf1, mf2)
{
integer(kind=4) ubound.9;
...
D.979 = *nf6;
D.980 = *nf3;
D.981 = *nf6;
D.982 = *nf3;
D.983 = (1 - D.979) + *nf3;
num.12 =
--- Comment #5 from schwab at suse dot de 2008-03-31 15:27 ---
First bad revision r125624 (dataflow merge).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32424
--- Comment #5 from hjl dot tools at gmail dot com 2008-03-31 15:57 ---
Can you use
[EMAIL PROTECTED] tmp]$ cat v.c
#include emmintrin.h
__m128i load1( char const* buf )
{
return _mm_loadu_si128 ((__m128i const *) buf);
}
__m128i load2( char const* buf )
{
return _mm_load_si128
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-31
16:06 ---
Subject: Re: gcc.c-torture/compile/20010226-1.c:22: ICE: in do_output_reload,
at reload1.c:7331
This was introduced in revision 133531.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35768
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-31 16:10 ---
GCC 4.0 is no longer maintained. Fixed in 4.1.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rsandifo at nildram dot co dot uk 2008-03-31 16:11
---
Subject: Re: gcc.c-torture/compile/20010226-1.c:22: ICE: in do_output_reload,
at reload1.c:7331
danglin at gcc dot gnu dot org [EMAIL PROTECTED] writes:
Richard, does match_scratch now require a mode? The
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-31 16:11 ---
Collapsed how?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35775
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-31 16:12 ---
Err, nevermind. Confirmed. This prologue code is inserted too late to be
optimized I guess.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
I have a C code:
void f();
void i(unsigned n) {
while (n-- 0) {
f();
}
}
Which when compiled with -O3 on i586 produces the assembly:
i:
pushl %ebp
movl%esp, %ebp
pushl %esi
movl8(%ebp), %esi
pushl %ebx
testl %esi, %esi
--- Comment #3 from rwild at gcc dot gnu dot org 2008-03-31 17:07 ---
Is this the same as bug 35752?
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from schwab at suse dot de 2008-03-31 17:08 ---
First bad revision on dataflow branch r124548.
2007-05-08 Kenneth Zadeck [EMAIL PROTECTED]
* regrename.c (regrename_optimize): Renamed df_ri_add_problem to
df_note_add_problem.
--
schwab
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-31 17:44 ---
*** Bug 35451 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2008-03-31 17:44 ---
*** This bug has been marked as a duplicate of 35752 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-31 17:48 ---
This is introduced by revision 123775:
http://gcc.gnu.org/ml/gcc-cvs/2007-04/msg00387.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2008-03-31 17:53 ---
Patch seems fine, but before approving it I would like a description of why
tries to [...] relink itself (important part is *re*link itself), and that
description should also go in exec-tool.in.
Thanks!
--
--- Comment #5 from hjl dot tools at gmail dot com 2008-03-31 18:16 ---
(In reply to comment #4)
Patch seems fine, but before approving it I would like a description of why
tries to [...] relink itself (important part is *re*link itself), and that
description should also go in
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-31 18:22 ---
Subject: Bug 30186
Author: pinskia
Date: Mon Mar 31 18:22:05 2008
New Revision: 133766
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133766
Log:
2008-03-31 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-31 18:22 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Filing this so that the multiple requests to add DFP docs don't continue to be
ignored.
First asked here:
http://gcc.gnu.org/ml/gcc/2007-06/msg00048.html
Asked again 9 months later:
http://gcc.gnu.org/ml/gcc/2008-03/msg01025.html
Janis indicates that some patch was proposed, but then not
Greetings:
It should be possible to override all fundamental pointers with a given class.
This is very important and can save a lot of trouble. How about:
template typename T
struct T *
{
...
};
--
Summary: Wishlist: To override all C pointers with C++ wrappers
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-31 19:22 ---
If the actual argument is an array section having a vector subscript, the
dummy argument is not definable and shall not have the INTENT (OUT), INTENT
(INOUT), VOLATILE, or ASYNCHRONOUS attributes.
gfortran has
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-31 19:38
---
Subject: Bug 35750
Author: reichelt
Date: Mon Mar 31 19:37:45 2008
New Revision: 133771
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133771
Log:
PR c/35750
* c-decl.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-03-31 19:39
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from Georg dot Baum at post dot rwth-aachen dot de
2008-03-31 19:41 ---
Subject: Re: return type of complex functions not C
compatible
--- Comment #4 from burnus at gcc dot gnu dot org 2008-03-30
21:18 ---
Not all. I gave two counter examples: pvf and
--- Comment #1 from bangerth at dealii dot org 2008-03-31 19:45 ---
Maybe so, but gcc only tries to implement what the C++ standard describes.
Please take your idea for this extension to the relevant standards committees.
--
bangerth at dealii dot org changed:
What
The error message thingo points to the wrong place in the
bad line and/or gives a misleading diagnostic. This isn't
all that important. I only found it because I'm trying to
find the source of an internal compiler error and if I mess
around with things, this one crops up and hides the other.
--- Comment #4 from bangerth at dealii dot org 2008-03-31 19:51 ---
(In reply to comment #3)
I believe that the main problem here is that GCC allows defining pure virtual
functions.
No, that's perfectly legal.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33878
--- Comment #6 from wilson at gcc dot gnu dot org 2008-03-31 19:52 ---
Subject: Bug 35695
Author: wilson
Date: Mon Mar 31 19:51:50 2008
New Revision: 133772
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133772
Log:
PR target/35695
* config/ia64/div.md (recip_approx_rf): Use
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-31 19:52 ---
I can tell you that OpenMP has similar issues and nobody complained about that
except for me. DFP is actually already documented in the correctly place:
--- Comment #5 from bangerth at dealii dot org 2008-03-31 19:54 ---
(In reply to comment #0)
The following stripped down code shows pure virtual method definitions for
both
a normal base class and a templated base class. To my surprise, the templated
class' body is not generated,
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-31 19:56 ---
Confirm.
NAG f95 has:
Error: ITS_BAD is not permitted in an initialisation expression
ifort:
Error: This symbol must be a defined parameter or an argument of an inquiry
function that evaluates to a compile-time
--- Comment #6 from yuriry at gmail dot com 2008-03-31 20:01 ---
Yes, it is legal, sorry confusion.
Yuri
(In reply to comment #4)
(In reply to comment #3)
I believe that the main problem here is that GCC allows defining pure
virtual
functions.
No, that's perfectly legal.
W.
--- Comment #1 from bangerth at dealii dot org 2008-03-31 20:07 ---
I tend to think that this should indeed work. Nice self-contained testcase!
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #22 from joel at gcc dot gnu dot org 2008-03-31 20:16 ---
(In reply to comment #21)
Best think would be to trace rtems calls on a platform where it works vs on
the
simulator. On a platform where it works, look at the backtrace of the task
creation call and try to find
--- Comment #23 from laurent at guerby dot net 2008-03-31 20:21 ---
pthread create and context switch should be the first to look at, in comparison
with a platform where it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot
|dot org
--- Comment #6 from oblivian at users dot sourceforge dot net 2008-03-31
20:29 ---
Hi guys, I'm moving over from 35451 since it was marked as a duplicate and
marked as resolved. I'm glad I'm not nuts and this is a problem someone else
has, but...
I've got a problem with the
--- Comment #2 from pault at gcc dot gnu dot org 2008-03-31 20:36 ---
This is fixed by my patch for PR35759. I am holding off on this for 24 hours
because (i) I know that there is an issue with derived types with allocatable
components and (ii) I've spent a bit too long looking at some
1 - 100 of 126 matches
Mail list logo
