"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 ha
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),
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 this
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 the
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 iWMMX
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. Th
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)
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
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
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
Subject: [linux-cirrus] Re: wot to do with the Maverick Crunch patches?
Date: Mon, 31 Mar 2008 15:46:52 +1000
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 s
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 it
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, Germa
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. H
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
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.
../../gcc-4.3
> "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 som
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 b
> 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 sili
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 fix
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 repro
> 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.
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'r
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
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
"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
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 gen_load_o
"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 ve
39 matches
Mail list logo
