Re: Subject gcc testsuite testcase gcc.c-torture/compile/20010327-1.c

[Kai Tietz]

"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 
reference
> >  and will produce a warning.
> 
> gcc.c-torture/compile is compiled with -w so the warnings are ignored.

I see, the reason for the failure on x86_64-pc-mingw32 is that gcc 
reports, that the initializer element is not constant. For some reason it 
assumes, that the address of the extern variable has no fixed address.

  Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Andreas Schwab]

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
does not carry out that side effect.  On powerpc the side effect must be
encoded through the update form of the load/store insns.  If you don't
use a load or store insn with the operand the you must use the "o"
constraint to avoid the side effect.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

GCC 4.2.4 Status Report (2008-03-31)

[Richard Guenther]

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 release.


Quality Data


Priority   #   Change from Last Report
 ---   ---
P123 0
P2   135   + 9
P341   - 7
 ---   ---
Total199   + 2

Of the 199 important regressions in 4.2 119 are fixed or never occured
on the 4.3 branch.

There are no known regressions on the 4.2 branch towards previous
4.2.x releases.


Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-03/msg00706.html


The next status report for the 4.2 branch will be sent by Joseph.

Richard.

-- 
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

4.3.1 Status Report (2008-03-31)

[Richard Guenther]

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 release following about a week later subject to no
problems requiring 4.3.1-rc2 to be built.


Quality Data


Priority   #   Change from Last Report
 ---   ---
P1 1   + 1
P293   + 9
P322   - 3
 ---   ---
Total116   + 7

There are no known regressions on the 4.3 branch against a previous
4.3.x release.

34 of the 116 serious regressions for 4.3 are not present on the 4.2
branch.  10 of the 116 serious regressions for 4.3 are fixed for 4.4.


Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-03/msg00703.html


The next report for the 4.3 branch will be sent by Jakub.

Richard.

-- 
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: wot to do with the Maverick Crunch patches?

[Joseph S. Myers]

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 processor has already been written
> and there is proper documentation.  Currently iwmmxt is only enabled in
> certain applications in openembedded (rather than system-wide) because
> of this reason.  I am not sure if it is only exception unwinding that
> isn't working on iWMMXt, or if there is something else that also needs
> to be written.

iWMMXt unwind support has been in GCC since my patch 
.

That illustrates the sort of thing that needs changing to implement unwind 
support for a new coprocessor.  Obviously you need to get the unwind 
specification in the official ARM EABI documents first before implementing 
it in GCC, and binutils will also need to support generating correct 
information given .save directives for the coprocessor registers.

For setjmp/longjmp support in glibc you also need to get an HWCAP value 
allocated in the kernel.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Daniel Jacobowitz]

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 can
> match memory addresses with side effects (auto inc/dec), but the insn
> does not carry out that side effect.  On powerpc the side effect must be
> encoded through the update form of the load/store insns.  If you don't
> use a load or store insn with the operand the you must use the "o"
> constraint to avoid the side effect.

Should asm "m" be required to carry out the side effect?  It seems
like this would break every end-user use of inline assembly; you'd
never know whether a memory argument should be used for lwz or lwzu.

I think treating =m as generating the output address is unhelpful.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Andreas Schwab]

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 asm statement has a bug.  The "m" constraint can
>> match memory addresses with side effects (auto inc/dec), but the insn
>> does not carry out that side effect.  On powerpc the side effect must be
>> encoded through the update form of the load/store insns.  If you don't
>> use a load or store insn with the operand the you must use the "o"
>> constraint to avoid the side effect.
>
> Should asm "m" be required to carry out the side effect?

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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Daniel Jacobowitz]

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, so it's possible to get that right.  Still - how many people
writing inline assembly do we think will do so?

This is back to something the S/390 maintainers were working on a few
months ago; in short the useful definition of "m" to GCC is not the
useful one for users, I don't think.  Especially when it changes.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Andreas Schwab]

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.  The ia64 target has a
>> similar issue.
>
> OK, so it's possible to get that right.  Still - how many people
> writing inline assembly do we think will do so?
>
> This is back to something the S/390 maintainers were working on a few
> months ago; in short the useful definition of "m" to GCC is not the
> useful one for users, I don't think.  Especially when it changes.

There are many pitfalls when you use inline asm.  Another example is the
difference between "r" and "b" on powerpc, where you can silently get
bad code if you use "r" when "b" would be needed (in some insns 0 means
constant 0 instead of register 0).

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GSOC Student application

[J.C. Pizarro]

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 gigant size of the project.
>
>
> [EMAIL PROTECTED]:~/gcc/src/include$ grep XNEW libiberty.h
>  #define XNEW(T) ((T *) xmalloc (sizeof (T)))
>  #define XNEWVEC(T, N)   ((T *) xmalloc (sizeof (T) * (N)))
>  #define XNEWVAR(T, S)   ((T *) xmalloc ((S)))
>
>  [EMAIL PROTECTED]:~/gcc/src/libiberty$ grep -A 11 '^xmalloc ('  xmalloc.c
>  xmalloc (size_t size)
>  {
>   PTR newmem;
>
>   if (size == 0)
> size = 1;
>   newmem = malloc (size);
>   if (!newmem)
> xmalloc_failed (size);
>
>   return (newmem);
>  }
>
>  So, you can see that XNEW* macro are now exactly the same as just
>  malloc function and they were added only for possible future change of
>  the memory allocator.
>  Any malloc function should be repalced with this macro AFAIK.
>  And the worst thing I can see in the code is freeing the memory
>  allocated with XNEW macro. It works fine now but it's wrong as I
>  understand.
>
>  [EMAIL PROTECTED]:~/gcc/src/libcpp$ grep XNEW * | wc -l
>  66
>  [EMAIL PROTECTED]:~/gcc/src/libcpp$ grep XDELETE * | wc -l
>  6
>  [EMAIL PROTECTED]:~/gcc/src/libcpp$ grep free * | wc -l
>  153
>  [EMAIL PROTECTED]:~/gcc/src/libcpp$ grep malloc * | wc -l
>  13
>
>
>
>  > You must know that before optimizing anything, you must profile the
>  >  whole code (-pg, gprof, ...) and study the beautiful formula of
>  >  "Amdahl's Law" for sequential machines in some books.
>  >
>  >  Studied this law, you can optimize better than your previous knowledge.
>
>
> I know what profiling is. And I know how parallel programs work,
>  thanks. I'm just talknig here about distinct improvements I can do,
>  not about some abstract optimizing.
>
>
>  >
>  > Luck U.S.S.R. boy ;)
>  >
>
> Yes, I've been living in USSR for 2 first years of my life :)
>

$ objdump -t libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1 | cut -c48- | \
   grep -i alloc | sort -u

There are aprox. 95 symbols related to *alloc* as by example
malloc, calloc, ealloc, ecalloc, etc.

 It's good idea to deforest some different symbols from this
forest of *alloc* to use common symbols.

Re: [linux-cirrus] Re: wot to do with the Maverick Crunch patches?

[Andrew McKay]

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 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.


I guess we'll go after our supplier as well to see what availability on the 
existing parts will be like


Andrew McKay
Iders Inc.

Re: [linux-cirrus] Re: wot to do with the Maverick Crunch patches?

[Brian Austin]

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

On Sun, 30 Mar 2008 13:45:30 +0100, "Martin Guy" <[EMAIL PROTECTED]>
said:
> Ok, so we all have dozens of these EP93xx ARM SoCs on cheap boards,
> with unusable floating point hardware.
> 
> What do we have to do to get the best-working GCC support for Maverick
> Crunch FPU?
> 
> Suggest: make open-source project with objective:."to get the
> best-working GCC support for Maverick Crunch FPU". Anyone wanna run
> one, create repositories, set up mailing list etc a la
> producingoss.com, or is the current infrastructure sufficient for a
> coordinated effort?

Honestly, there is little reward in setting up a new mailing list since
no-one has really tried to look into the issue that much.  Traffic is so
low on this list (linux-cirrus), so there is little reason to start a
new one.

Reading documentation and working out why things aren't working is a
much better use of time.  Running the full C and C++ tests (in gcc) on
the current MaverickCrunch gcc would be a good start.  

We need to figure out what bugs are actually introduced by
MaverickCrunch (in C, C++ and std libraries), and fix them.

There is also a floating point testsuite for glibc:

glibc-2.5/math/gen-libm-test.pl

There should be one for uclibc, too...

> As I understand it, mailline GCC with patches in various versions can
> give:

> futaris-4.1.2/-4.2.0: Can usually use floating point in hardware for C
> and C++, maybe problems with exception unwinding in C++. In generated
> ASM code, all conditional execution of instructions is disabled except
> for jump/branch. Loss of code speed/size: negligable.
> Passes most FP tests but does not produce a fully working glibc (I
> gather from the Maverick OpenEmbedded people)

This is probably mainly due to the lack of exception unwinding, i.e.
what is detailed in ARM IHI 0038A.  It could also be due to bugs in the
MaverickCrunch engine, which aren't easy to pick up / debug.  I suggest
disabling MaverickCrunch double instructions, and working from there. 
If you or someone can get it working 100% with glibc then we can move
forward from there.
 
> Thoughts on a postcard please... any further progress in OE land?

At the moment we only MaverickCrunch in certain parts of our code, by
setting the relevant CFLAGS / CXXFLAGS.  We specifically only use float
rather than double, and it all works as it should.

Unfortunately, I haven't gotten glibc working with MaverickCrunch.  Lack
of time / motivation / documentation.

I think glibc EABI doesn't support MaverickCrunch, since no-one has
written "working" patches for this yet, e.g.
glibc-2.5/ports/sysdeps/arm/eabi

I'm pretty sure that the old patches that I did write, are incomplete:
http://files.futaris.org/glibc/glibc-crunch.patch

I don't think that ever ended up in the OE tree, since it was never
working correctly.  Additionally I don't think the binutils patch has
gone in.

> Cirrus also have a hand-coded Maverick libm that you can link with
> old-ABI binaries - can we incorporate this asm code in mainline?

Is this uClibc libm or glibc libm?

You might be able to use MaverickCrunch with uClibc but the patch
http://mail.busybox.net/lists/uclibc/2007-November/018723.html won't
compile a 100% working uClibc.  It compiles but doesn't work as
expected.  Not sure if it works correctly with OABI.

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.

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 processor has already been written
and there is proper documentation.  Currently iwmmxt is only enabled in
certain applications in openembedded (rather than system-wide) because
of this reason.  I am not sure if it is only exception unwinding that
isn't working on iWMMXt, or if there is something else that also needs
to be written.

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Till Straumann]

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 effects (auto inc/dec), but the insn
does not carry out that side effect.

I'm sorry - that's a bit too brief for me to understand. Are you
talking about the memory-input or memory-output operand?
Could you please elaborate a little bit?

Also, did you look at my other example?

void
test(volatile unsigned *base)
{
  volatile unsigned *reg_p = base + IEVENT_REG/sizeof(*base);
  unsigned   val;

  /* tell gcc that the asm needs/looks at *reg_p */
  asm volatile ("lwz %0, 16(%1)":"=r"(val):"b"(base),"m"(*reg_p));

  while ( ! (val & IEVENT_GRSC) )
  val = *reg_p;
  ;
}

Thanks
-- Till



  On powerpc the side effect must be
encoded through the update form of the load/store insns.  If you don't
use a load or store insn with the operand the you must use the "o"
constraint to avoid the side effect.

Andreas.

  

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Till Straumann]

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 itself, unlike m68k, for example.  The ia64 target has a
similar issue.
  

OK, so it's possible to get that right.  Still - how many people
writing inline assembly do we think will do so?

This is back to something the S/390 maintainers were working on a few
months ago; in short the useful definition of "m" to GCC is not the
useful one for users, I don't think.  Especially when it changes.



There are many pitfalls when you use inline asm.  Another example is the
difference between "r" and "b" on powerpc, where you can silently get
bad code if you use "r" when "b" would be needed (in some insns 0 means
constant 0 instead of register 0).
  

Sure - but that is at least (minimally) documented. One sentence
more in the gcc manual wouldn't hurt though...

T.

Andreas.

  

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Andreas Schwab]

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 fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GSOC Student application

[Joe Buck]

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.  He's an attention-seeking troll,
who has just enough technical knowledge to derail conversation.
His technical objections carry no weight with anyone but himself.

No one who is proposing a contribution to GCC should bother trying to
refute any objection J.C. Pizarro raises.  If, like a stopped clock that
is right twice a day, he's accidentally right about something, someone else
will raise the issue.

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

[Till Straumann]

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 to be updated, right?

How am I supposed to know that my version is wrong
(and it used to work with older gccs)? I just followed the manual
which states:

> If your assembler instructions access memory in an unpredictable
>fashion, add `memory' to the list of clobbered registers.  This will
>cause GCC to not keep memory values cached in registers across the
>assembler instruction and not optimize stores or loads to that memory.
>You will also want to add the `volatile' keyword if the memory affected
>is not listed in the inputs or outputs of the `asm', as the `memory'
>clobber does not count as a side-effect of the `asm'.  If you know how
>large the accessed memory is, you can add it as input or output but if
>this is not known, you should add `memory'.  As an example, if you
>access ten bytes of a string, you can use a memory input like:
>
> {"m"( ({ struct { char x[10]; } *p = (void *)ptr ; *p; }) )}.
>
> Note that in the following example the memory input is necessary,
>otherwise GCC might optimize the store to `x' away:
> int foo ()
> {
>   int x = 42;
>   int *y = &x;
>   int result;
>   asm ("magic stuff accessing an 'int' pointed to by '%1'"
> "=&d" (r) : "a" (y), "m" (*y));
>   return result;
> }


IMHO my example is pretty close to this...

Also, the manual doesn't say that 'm' can only match
memory addresses with side effects; it says 'a memory
operand is allowed, with any kind of address that the
machine supports in general'.

Thanks

-- Till


Andreas.

  

Re: GCC 4.3.0 compilation error

[Jim Wilson]

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.0/gcc/config/host-linux.c: In function `linux_gt_pch_use_address':
../../gcc-4.3.0/gcc/config/host-linux.c:207: `SSIZE_MAX' undeclared
(first use in this function)


GCC is expecting SSIZE_MAX to be defined by the glibc headers, which is 
true with current versions of glibc.  Assuming ssize_t is a long, then 
SSIZE_MAX should be LONG_MAX.


Jim

Re: GSOC Student application

[Tom Tromey]

> "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 posts, then that someone
ought to simply be banned.

I know this is extreme, and as far as I know we've never done it
before.  But, in my opinion, we've been more than tolerant here.
There's no benefit that I can see to putting up with this kind of bad
behavior.

Tom

Thread starvation and resource saturation in atomicity functions?

[Chad Attermann]

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 
to CPU utilization shooting to 100%, with the __gnu_cxx::__exchange_and_add 
function frequently making appearances at the top of the stack trace of 
several threads.


I believe I have made a break-through recently and wanted to solicit the 
opinion of some experts on this.  I seem to have narrowed the problem down 
to running my application as root versus an unprivileged user, and further 
isolated the suspected cause to varying thread priorities in my application. 
I have theorized that spin-locks in gcc, particularly in the atomicity 
__gnu_cxx::__exchange_and_add function, are causing higher priority threads 
to consume all available cpu cycles while spinning indefinitely waiting for 
a lower priority thread that holds the lock.  Now I am already aware that 
messing with thread priorities is dangerous and often an excercise in 
futility, but I am surprised that something so elemental as an atomic 
test-and-set operation that may be used extensively throughout gcc could 
possibly be the culprit for all of the trouble I have been experiencing.


More than anything I'm hoping for a sanity check on this, even if it's just 
to confirm what may be obvious to others; that modifying thread priorities 
is strictly off-limits except in extreme circumstances with careful control 
over what operations are performed.  Or perhaps there's another solution 
that has eluded my searches, maybe a bug fix or some way of avoiding such 
spin-locks in gcc making varying thread-priorities viable and safe.


Thanks in advance for any insight, and at the very least I hope that this 
will serve as a warning to others who might find themselves in the same 
situation.


Cheers,

Chad Attermann

Re: Thread starvation and resource saturation in atomicity functions?

[David Daney]

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 
application hanging due to CPU utilization shooting to 100%, with the 
__gnu_cxx::__exchange_and_add function frequently making appearances at 
the top of the stack trace of several threads.


I believe I have made a break-through recently and wanted to solicit the 
opinion of some experts on this.  I seem to have narrowed the problem 
down to running my application as root versus an unprivileged user, and 
further isolated the suspected cause to varying thread priorities in my 
application. I have theorized that spin-locks in gcc, particularly in 
the atomicity __gnu_cxx::__exchange_and_add function, are causing higher 
priority threads to consume all available cpu cycles while spinning 
indefinitely waiting for a lower priority thread that holds the lock.  
Now I am already aware that messing with thread priorities is dangerous 
and often an excercise in futility, but I am surprised that something so 
elemental as an atomic test-and-set operation that may be used 
extensively throughout gcc could possibly be the culprit for all of the 
trouble I have been experiencing.


More than anything I'm hoping for a sanity check on this, even if it's 
just to confirm what may be obvious to others; that modifying thread 
priorities is strictly off-limits except in extreme circumstances with 
careful control over what operations are performed.  Or perhaps there's 
another solution that has eluded my searches, maybe a bug fix or some 
way of avoiding such spin-locks in gcc making varying thread-priorities 
viable and safe.


Thanks in advance for any insight, and at the very least I hope that 
this will serve as a warning to others who might find themselves in the 
same situation.




I wonder if you are seeing either priority inversion or a deadlock.

As always, a small testcase would be useful.

David Daney

Re: Thread starvation and resource saturation in atomicity functions?

[Ian Lance Taylor]

"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 experiencing with my
> application hanging due to CPU utilization shooting to 100%, with the
> __gnu_cxx::__exchange_and_add function frequently making appearances
> at the top of the stack trace of several threads.
>
> I believe I have made a break-through recently and wanted to solicit
> the opinion of some experts on this.  I seem to have narrowed the
> problem down to running my application as root versus an unprivileged
> user, and further isolated the suspected cause to varying thread
> priorities in my application. I have theorized that spin-locks in gcc,
> particularly in the atomicity __gnu_cxx::__exchange_and_add function,
> are causing higher priority threads to consume all available cpu
> cycles while spinning indefinitely waiting for a lower priority thread
> that holds the lock.  Now I am already aware that messing with thread
> priorities is dangerous and often an excercise in futility, but I am
> surprised that something so elemental as an atomic test-and-set
> operation that may be used extensively throughout gcc could possibly
> be the culprit for all of the trouble I have been experiencing.

You explicitly mentioned x86.  For x86, __gnu_cxx::__exchange_and_add
does not use a spin-lock.

If you mean that other code may use spin locks built on top of
__exchange_and_add, then, yes, in that case you could be getting a
priority inversion.  But gcc itself does not use any such code.  So if
you are seeing a problem of this sort, it is not a problem with gcc.

Ian

Re: [linux-cirrus] Re: wot to do with the Maverick Crunch patches?

[Martin Guy]

> 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 a broken FPU, a
display engine that can only do up to 800x600x16 or 1024x768x8 without
getting jumpy (2.6.2X fbdev), and a raster graphic operations unit
that appears to be slower than doing the corresponding bitops in ARM
software.

Don't get me wrong, the thing still bristles with peripherals and
delievers lots of poke for sexto to no energy, and we are working on
making the most of what we have.

Has anyone tried the NetBSD armevb port on an ep93XX and added the
frame driver patch I've seen lurking around? Could its frame buffer do
stable higher-res full-colour graphics? The Linux one does them but
the frame jitters about, as if the VDU is being locked out of the RAM
for too long.

>  I guess we'll go after our supplier as well to see what availability on the
>  existing parts will be like

Well, leave some for us :) No, it's still a solid chip that runs for
hundreds of days without a blip and barely gets warm, so I wouldn't
redesign unless you wanted those specific features or are early enough
in the design cycle.

   M

Re: please add DFP to gcc-4.3/changes.html

[Janis Johnson]

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
--- changes.html28 Mar 2008 15:57:51 -  1.108
+++ changes.html31 Mar 2008 20:05:19 -
@@ -357,6 +357,16 @@
 Currently, only MIPS targets are supported.
 
 
+
+Decimal floating-point arithmetic based on draft ISO/IEC TR 24732,
+N1241, is now supported as a GCC extension to C for targets
+i[34567]86-*-linux-gnupowerpc*-*-linux-gnu,
+s390*-ibm-linux-gnu, and x86_64-*-linux-gnu.
+The feature introduces new data types _Decimal32,
+_Decimal64, and _Decimal128 with constant
+suffixes DF, DD, and DL.
+
+
   
 
 C++

Re: [RFH] Uninitialized warning as error is disabled on the trunk

[Jim Wilson]

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.

Jim

Re: Implementing a restrictive addressing mode for a gcc port

[Jim Wilson]

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.


One thing you could try is generating a double-word pseudo-reg at RTL 
expand time, and then using subreg 0 for the source and subreg 1 for the 
dest (or vice versa depending on endianness/word order).  This will get 
you a register pair you can use from the register allocator.  This 
doesn't help at reload time though.


You probably have to define a constraint for every register, and then 
write an alternative for every register pair matching the correct even 
register with the correct odd register.  That gets you past reload.


Another alternative might be to have a pattern (e.g. reload_insi) that 
generates secondary reloads that request the register pair you need. 
This is unlikely to get good code, but would not be hard to do.


Jim

Re: [linux-cirrus] Re: wot to do with the Maverick Crunch patches?

[Ben Elliston]

> 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

Re: genattrtab segfault on RH 7.3 (powerpc cross)

[Jim Wilson]

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 reproducible, then it usually isn't a gcc problem.

There are some rare cases where a bug is only reproducible with the 
right environment.  Different sized environments can cause changes in 
how stack frames get allocated, which can result in different behavior 
in the presence of stray pointer reads/writes.  If it fails inside make, 
but not from the command line, it could be such a case.


Jim

Re: please add DFP to gcc-4.3/changes.html

[Benjamin Kosnik]

> 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
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/changes.html,v
> retrieving revision 1.108
> diff -u -r1.108 changes.html
> --- changes.html  28 Mar 2008 15:57:51 -  1.108
> +++ changes.html  31 Mar 2008 20:05:19 -
> @@ -357,6 +357,16 @@
>  Currently, only MIPS targets are supported.
>  
>  
> +
> +Decimal floating-point arithmetic based on draft ISO/IEC TR
> 24732,
> +N1241, is now supported as a GCC extension to C for targets
> +i[34567]86-*-linux-gnu powerpc*-*-linux-gnu,
> +s390*-ibm-linux-gnu, and
> x86_64-*-linux-gnu.
> +The feature introduces new data types _Decimal32,
> +_Decimal64, and _Decimal128 with
> constant
> +suffixes DF, DD, and DL.
> +
> +
>
>  
>  C++
> 

Re: GCC : how to add VFPU to PSP Allegrex (MIPS target) ?

[Jim Wilson]

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 
different "float" types, which in turn may cause other problems.



   * Another way to distinguish a VFPU scalar is to use "typedef  float
 __attribute__((vector_size(4))) V1SF;". Is that difficult to make
 it possible (right now, gcc refuses it) ?


See the code in make_vector_modes in genmodes.c.
  /* Do not construct vector modes with only one element, or 

 vector modes where the element size doesn't divide the full 


 size evenly.  */
That is only the first step though.  I'm not sure what the rest of gcc 
will do for single element vectors.



   * Same question for V3SF, is that difficult to make it possible ?


Not obvious what the problem is here, seems like it should already be 
possible to do this.



 first 32 registers, would it be difficult to have combined V2V1SF,
 V3V1SF, V4V1SF to define column vectors of two, three or four
 components ? and to have V2V2SF, V3V3SF, V4V4SF as matrixes ?


The gcc support was designed to handle SIMD instructions.  There is some 
support for stride on memory accesses, but not within the register set. 
 I don't think there is any way to support column or matrix vectors at 
this time.


You might get better responses if you put something obvious like 
"autovectorization" in the subject line.  The people doing this work 
might not have realized that this message was relevant to them.


Jim

gcc-4.1-20080331 is now available

[gccadmin]

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/gcc-4_1-branch 
revision 133774

You'll find:

gcc-4.1-20080331.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20080331.tar.bz2 C front end and core compiler

gcc-ada-4.1-20080331.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20080331.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20080331.tar.bz2  C++ front end and runtime

gcc-java-4.1-20080331.tar.bz2 Java front end and runtime

gcc-objc-4.1-20080331.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20080331.tar.bz2The GCC testsuite

Diffs from 4.1-20080324 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: please add DFP to gcc-4.3/changes.html

[Janis Johnson]

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 and added a comment
to the PR about other changes we should make to the section about
decimal floating-point support in the GCC Manual.  Thanks for the
reminder, I had planned to do this long ago and then forgot all
about it.

Janis

Re: please add DFP to gcc-4.3/changes.html

[Ben Elliston]

Looks good to me.

Thanks,
Ben

Re: wot to do with the Maverick Crunch patches?

[Hasjim Williams]

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 the best person to ask for most of these questions.
 
> > 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 processor has already been written
> > and there is proper documentation.  Currently iwmmxt is only enabled in
> > certain applications in openembedded (rather than system-wide) because
> > of this reason.  I am not sure if it is only exception unwinding that
> > isn't working on iWMMXt, or if there is something else that also needs
> > to be written.
> 
> iWMMXt unwind support has been in GCC since my patch 
> .

Thanks for that.  I think I saw this patch a while ago, but of course
forgot that it wasn't merged into 4.2.2, only 4.3.0.
 
> That illustrates the sort of thing that needs changing to implement
> unwind 
> support for a new coprocessor.  Obviously you need to get the unwind 
> specification in the official ARM EABI documents first before
> implementing 
> it in GCC

Any idea of who to contact and/or how to get this done?

> and binutils will also need to support generating correct 
> information given .save directives for the coprocessor registers.

http://files.futaris.org/gcc/binutils-crunch.patch almost covers this,
but I don't quite follow your binutils patch:
http://sourceware.org/ml/binutils/2006-08/msg00207.html

Am I reading this right (according to sec 9.3 from ARM IHI 0038A):

unwind.d /  unwind_vxwords.d patch tests:
d0c6c1c1 -> [d0] Pop VFP D[8]-D[8], [c6c1] Pop iWMMXt wR[10]-wR[11],
[c1] Pop iWMMXt wR[10]-wR[11]
b0b0c0c6|c1c1c6d0 -> Haven't decoded this, but it hasn't changed since
before your patch
c6c0b0b0 -> [c6c0] Pop iWMMXt wR[10]-wR[10], [b0] Finish, [b0] Finish
 
unwind.s is a simple test to save iWMMXt, and unwind.d does the unwind
for it?  Your patch adds code to test for the incorrect merging test?

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 IHI 0038A), what function in binutils gas/config/tc-arm.c is
called?

I think my problem was that I didn't know what opcode, to use when
calling add_unwind_opcode from within s_arm_unwind_save_mv in the above
binutils-crunch.patch, so I incorrectly used the code (i.e. copy/paste)
to unwind a mmxwr data reg.

Also should aebi_set_public_attributes in binutils/gas/config/tc-arm.c
be setting an EABI attr for MaverickCrunch?

Can we use gas or its testsuite to test each MaverickCrunch operation
easily?  I've disabled certain MaverickCrunch operations from gcc,
because I found them to be buggy.  I am not sure if this is because the
instruction is incorrectly encoded, or because of some inherit flaw with
MaverickCrunch.

> For setjmp/longjmp support in glibc you also need to get an HWCAP value 
> allocated in the kernel.

arch/arm/mach-ep93xx/core.c:
#ifdef CONFIG_CRUNCH
elf_hwcap |= HWCAP_CRUNCH;
#endif

The cirrus kernel patches from arm.cirrus.com add the necessary kernel
support, but I think it is also in mainstream linux.

Also, can I assume that running the testsuites (binutils, gcc and glibc)
is the best way to determine what is missing from the current
MaverickCrunch support?

binutils - http://sourceware.org/binutils/docs/
 - "make check" from gas build directory, eg:
binutils-cross-2.18-r1/binutils-2.18/build.i686-linux.arm-angstrom-linux-gnueabi/gas

gcc - http://gcc.gnu.org/testing/
- http://gcc.gnu.org/install/test.html 
- "make check-gcc" and "make check-gcc-c++"  from gcc build
directory, eg:
gcc-cross-4.1.2-r13/gcc-4.1.2/build.i686-linux.arm-angstrom-linux-gnueabi

glibc -
http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html#Configuring-and-compiling
  - "make check" from glibc build directory, eg:
glibc-2.5-r9/build-arm-angstrom-linux-gnueabi

And of course your paths need to be setup along with dejagnu, etc...
e.g. http://lists.gnu.org/archive/html/dejagnu/2006-04/msg8.html

Re: Implementing a restrictive addressing mode for a gcc port

[Mohamed Shafi]

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 for the source address to depend on the
>  destination address, or vice versa.
>
>  One thing you could try is generating a double-word pseudo-reg at RTL
>  expand time, and then using subreg 0 for the source and subreg 1 for the
>  dest (or vice versa depending on endianness/word order).  This will get
>  you a register pair you can use from the register allocator.  This
>  doesn't help at reload time though.
>
>  You probably have to define a constraint for every register, and then
>  write an alternative for every register pair matching the correct even
>  register with the correct odd register.  That gets you past reload.
>
>  Another alternative might be to have a pattern (e.g. reload_insi) that
>  generates secondary reloads that request the register pair you need.
>  This is unlikely to get good code, but would not be hard to do.
>
  Thank you for your reply.

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_offset pattern if the addressing mode is
found. In the pattern i will have the 8 similar constraints for the
base register and the source/destination register. This way gcc will
automatically do reload if its required in order to match the
constraints. (store,load)_offset pattern should come above the normal
load or store pattern as the order of the patterns are important. This
is working for me now. Won't this be a better solution ?

Regards,
Shafi

Re: wot to do with the Maverick Crunch patches?

[Hasjim Williams]

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 IHI 0038A), what function in binutils gas/config/tc-arm.c is
> called?

To answer my own question:

gcc/gcc/config/arm/pr-support.c -> __gnu_unwind_execute

uws is the GNU unwinding state as defined in unwind-arm.h

e.g. for VFP
gnu_Unwind_Save_VFP in libunwind.S called from unwind-arm.c /
_Unwind_VRS_Pop

I'm not sure at the moment, what regclass (UVRSC) MaverickCrunch
registers are being classed as.  I guess with my invalid
binutils-crunch.patch they would be classed as UVRSC_WMMXD...  Which
never "worked" (or even compiled) in gcc 4.2.2 or gcc 4.1.2 since
Joseph's patch hadn't been merged in, and so the opcode c6 or c1 etc
would fail.

I suppose we need a DEMAND_SAVE_MAVERICK like DEMAND_SAVE_VFP WMMXD etal
...

Re: Thread starvation and resource saturation in atomicity functions?

[Chad Attermann]

"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 to solve persistent problems I have been experiencing with my
application hanging due to CPU utilization shooting to 100%, with the
__gnu_cxx::__exchange_and_add function frequently making appearances
at the top of the stack trace of several threads.

I believe I have made a break-through recently and wanted to solicit
the opinion of some experts on this.  I seem to have narrowed the
problem down to running my application as root versus an unprivileged
user, and further isolated the suspected cause to varying thread
priorities in my application. I have theorized that spin-locks in gcc,
particularly in the atomicity __gnu_cxx::__exchange_and_add function,
are causing higher priority threads to consume all available cpu
cycles while spinning indefinitely waiting for a lower priority thread
that holds the lock.  Now I am already aware that messing with thread
priorities is dangerous and often an excercise in futility, but I am
surprised that something so elemental as an atomic test-and-set
operation that may be used extensively throughout gcc could possibly
be the culprit for all of the trouble I have been experiencing.


You explicitly mentioned x86.  For x86, __gnu_cxx::__exchange_and_add
does not use a spin-lock.

If you mean that other code may use spin locks built on top of
__exchange_and_add, then, yes, in that case you could be getting a
priority inversion.  But gcc itself does not use any such code.  So if
you are seeing a problem of this sort, it is not a problem with gcc.



I doubted at first too, but from what I can tell, the version of gcc that 
ships with Solaris 10 x86 is gcc 3.4.3 for i386.  Below is the output of the 
pre-installed gcc given the -v switch:


   Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
   Configured with: 
/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas 
--with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ 
--enable-shared

   Thread model: posix
   gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)


Below is a snippet of code from gcc 3.4.3 source 
./libstdc++-v3/config/cpu/i386/atomicity.h:


 _Atomic_word
 __attribute__ ((__unused__))
 __exchange_and_add(volatile _Atomic_word* __mem, int __val)
 {
   register _Atomic_word __result, __tmp = 1;

   // Obtain the atomic exchange/add spin lock.
   do
 {
   __asm__ __volatile__ ("xchg{l} {%0,%1|%1,%0}"
 : "=m" 
(_Atomicity_lock<0>::_S_atomicity_lock),

 "+r" (__tmp)
 : "m" 
(_Atomicity_lock<0>::_S_atomicity_lock));

 }
   while (__tmp);

   __result = *__mem;
   *__mem += __val;

   // Release spin lock.
   _Atomicity_lock<0>::_S_atomicity_lock = 0;

   return __result;
 }

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 instead that does not use spin-locks?

Re: Implementing a restrictive addressing mode for a gcc port

[Jim Wilson]

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_offset pattern if the addressing mode is
> found.

This sounds similar to what I suggested, so it may work.

However, having a separate pattern for certain kinds of loads/stores may
not work.  reload doesn't re-recognize an insn while it is fixing it,
hence you need to have a single movsi (or whatever) pattern that can
handle any kind of operand.  If you have a movsi pattern that doesn't
accept load/store offset, then probably what will happen is that any fp
+offset addresses generated during reload will get reloaded into a
register, and you may not get very good code.  Of course, with your
address register restrictions, there is only one register that can be
used with fp+offset, so you might not get good code for that regardless
of what you do.

Jim

Re: Thread starvation and resource saturation in atomicity functions?

[Ian Lance Taylor]

"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 instead that does not use
> spin-locks?

Yes, barring the extremely unlikely case that you need to run a plain
i386, you should use the i486 code from libstdc++-v3/config/cpu/i486.
There are various difficulties with the i386 atomicity code.
Fortunately the i486 was released almost 20 years ago, and it's
generally safe to use the i486 instructions today.

Ian