headers
Janis Johnson | 1 Apr 2008 01:08
Picon
Favicon

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

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
Permalink | Reply | 1 comment |
headers
Hasjim Williams | 1 Apr 2008 04:10

Re: wot to do with the Maverick Crunch patches?

On Mon, 31 Mar 2008 11:31:01 +0000 (UTC), "Joseph S. Myers"
<joseph <at> codesourcery.com> 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 
> <http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00049.html>.

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
(Continue reading)

Permalink | Reply | 13 comments |
headers
Mohamed Shafi | 1 Apr 2008 06:18
Picon
Gravatar

Re: Implementing a restrictive addressing mode for a gcc port

On Tue, Apr 1, 2008 at 2:10 AM, Jim Wilson <wilson <at> tuliptree.org> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hasjim Williams | 1 Apr 2008 07:00

Re: wot to do with the Maverick Crunch patches?


On Tue, 01 Apr 2008 12:10:54 +1000, "Hasjim Williams"
<linux-cirrus <at> lists.futaris.org> 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
...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chad Attermann | 1 Apr 2008 07:12

Re: Thread starvation and resource saturation in atomicity functions?


"Ian Lance Taylor" <iant <at> google.com> writes:

> "Chad Attermann" <chad <at> broadmind.com> 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.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Wilson | 1 Apr 2008 07:11

Re: Implementing a restrictive addressing mode for a gcc port

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
Permalink | Reply | 0 comments |
headers
Ian Lance Taylor | 1 Apr 2008 07:56
Picon
Favicon
Gravatar

Re: Thread starvation and resource saturation in atomicity functions?

"Chad Attermann" <chad <at> broadmind.com> 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
Permalink | Reply | 1 comment |
headers
Alex Turjan | 1 Apr 2008 11:22
Picon
Favicon

RTL alias analysis

Hi everybody,
Im interested whether there is gcc support (at the RTL
level) after unrolling which allows to disambiguate
memory accesses present in RTL constructs (specially
among memory accesses generated due to unrolling) for
machines that do not support indexed addressing modes.

I am aware of an article by Sanjiv Gupta and Naveen
Sharma on alias analysis at the RTL level, which was
published in the GCC 2003 summit. Are there any
further gcc developments of this work or is there a
patch concerning this work? 

thanks in advance,
Alex Turjan

      ____________________________________________________________________________________
No Cost - Get a month of Blockbuster Total Access now. Sweet deal for Yahoo! users and friends. 
http://tc.deals.yahoo.com/tc/blockbuster/text1.com
Permalink | Reply | 4 comments |
headers
Diego Novillo | 1 Apr 2008 14:39
Picon
Favicon

Re: GSOC Student application

2008/3/31 Tom Tromey <tromey <at> redhat.com>:
> >>>>> "Joe" == Joe Buck <Joe.Buck <at> synopsys.COM> 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.

Agreed.  I don't mind tolerating abusive behaviour, but this has been
going on for a long enough time.

Diego.
Permalink | Reply | 6 comments |
headers
Swapna Pawar | 1 Apr 2008 15:17
Favicon

RE: gcc4.3 configuring problems with mpfr

Hi,

I am facing the same problem as mentioned by you. Is there any solution
or workaround? Please guide.

I have successfully built the mingw native compiler with the following
sources,

mingw-runtime-3.12
w32api-3.9
binutils-2.17.50-20060824-1-src
gcc-3.4.5-20060117-1

I want to build the mingw cross compiler for m32c-elf. The sources used
for this cross
compiler are as follows:

gcc-4.3.0
binutils-2.18
newlib-1.15.0

GCC-4.3.0 requires pre-built GMP and MPFR libraries. I get the following
error
while configuring the mingw cross compiler for m32c-elf,

configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.0+.

I have used GMP 4.2.2 and MPFR 2.3.0 sources.

I have specified the paths of GMP and MPFR install directories as
(Continue reading)

Permalink | Reply | 1 comment |

Gmane