Thread safe functions from the C standard library

[David Livshin]

Hi,

What functions from the GNU's C standard library ( libc ) are thread 
safe? Of a particular interest are transcendental functions ( like 
'exp', 'sin' etc. ) - are they thread safe?


Are there any requirements/guidelines/assurances regarding thread safety 
of functions from the  C library?


Thanks in advance.

--
David Livshin

http://www.dalsoft.com

Re: TLS on darwin

[IainS]

On 8 Dec 2008, at 21:09, Andrew Pinski wrote:

On Mon, Dec 8, 2008 at 1:04 PM, IainS <[EMAIL PROTECTED] 
acoustics.co.uk> wrote:

following on from http://gcc.gnu.org/ml/gcc/2008-05/msg00202.html


As I mentioned; it is emulated.  So it works, by default, though it is


hm.  At the moment it doesn't appear to work.

with configure options   "--enable-threads"(or default options)  
we get the situation described below.
with configure options   "--enable-threads --enable-tls" we get an  
assembler fault instead.


= with "--enable-threads" (and also default options).

(see also PR32765 and http://gcc.gnu.org/ml/fortran/2008-12/ 
msg00118.html)


___emutls_get_address is defined in libgcc_s.1.dylib (and libgcc_eh.a)

As you suggest in the PR32765 thread, the problem is that libgcc_s.1  
is not searched unless this is forced on the options line.


However, the problem is much wider than those two tests.

check_effective_target_tls_runtime in target-supports.exp also fails  
with the same error - this "UNSUPPORTS" pretty much all TLS tests  
across gcc on darwin8/9.


The only reason that the PR32765 issue was visible is that the two  
test cases do not use { dg-require-effective-target tls_runtime }




The workaround used to close PR32765 no longer functions on darwin8  
(unless the the compiler is installed before checking) - although it  
does still work on darwin9.


The  ___emutls_get_address in libgcc_s.1 also appears to have some  
issues on 64bit processors, both PPC and Intel (at least when running  
32 bit code).


The version in libgcc_eh does work (which is why the --static-libgcc  
approach is succeeding on darwin9).


so a more closely targeted workaround is to use -lgcc_eh in any  
darwin code that requires TLS (this works on darwin8 and darwin9).


However, this seems like a pretty messy solution - and prone to all  
sorts of symbol conflicts when more than ___emutls_get_address is  
involved.


=

I'm afraid I'm out of my depth here gcc has quite a learning  
curve...


... is the problem one of SPECs ?
.. or does every single TLS case need a darwin-specific addition to  
reference -lgcc_eh ?
.. I guess also that target-supports.exp would need some modification  
to account for this...


cheers,
Iain

Re: [ARM] Implement __builtin_bswap32() via ARMv6 "rev" instruction

[Alexandre Pereira Nunes]

2008/12/8 Ian Lance Taylor <[EMAIL PROTECTED]>:
> "Alexandre Pereira Nunes" <[EMAIL PROTECTED]> writes:
>
>>  I can provide these, tough as for the copyright assignment, the
>>  document mentions I can declare the changes in public domain, and
>>  since I already published something (which may or may not be used by
>>  someone in the future), I hereby do so.
>
> Unfortunately we need more than that: we need a signed piece of paper
> disclaiming copyright.  This is not just to be difficult, it's because
> of some unfortunate legal issues which have arisen in the past.  If
> you want to proceed along these lines, I can send you the appropriate
> form.
>
> Ian
>

The (apparently outdated) document I was pointed to by Paul also
mentions the possibility of disclaiming copyright for "all future
changes", via a specific form.  I would prefer this option, if it's
available. You can mail me the form and/or additional information
privately, if you wish.


Alexandre

Re: gcc -r

[Ian Lance Taylor]

Ralf Corsepius <[EMAIL PROTECTED]> writes:

> 1) Is "gcc -r" officially supported by gcc?
>
> It apparently works, but I can't find it documented anywhere in GCC's
> documentation.

When invoking the linker, a -r option on the command line will be
passed to the linker.  The same is true of -A, -d, -eSYM, -m, -N, -n,
-s, -t, -uSYM, -x, -z, -Z.  This is not well documented.

> 2) Is "gcc -r" any different from using "gcc -Wl,-r"?

No.

Ian

Re: gcc -r

[Ralf Corsepius]

On Tue, 2008-12-09 at 07:19 -0800, Ian Lance Taylor wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> 
> > 1) Is "gcc -r" officially supported by gcc?
> >
> > It apparently works, but I can't find it documented anywhere in GCC's
> > documentation.
> 
> When invoking the linker, a -r option on the command line will be
> passed to the linker.  The same is true of -A, -d, -eSYM, -m, -N, -n,
> -s, -t, -uSYM, -x, -z, -Z.  This is not well documented.

OK, thanks for the explanation.

> > 2) Is "gcc -r" any different from using "gcc -Wl,-r"?
> 
> No.

So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ?

Ralf

Re: Thread safe functions from the C standard library

[Ian Lance Taylor]

David Livshin <[EMAIL PROTECTED]> writes:

> What functions from the GNU's C standard library ( libc ) are thread
> safe? Of a particular interest are transcendental functions ( like
> exp', 'sin' etc. ) - are they thread safe?
>
> Are there any requirements/guidelines/assurances regarding thread
> safety of functions from the  C library?

I'm sorry, this is the wrong mailing list.  This is a mailing list for
gcc developers.  Questions about using gcc should be sent to
[EMAIL PROTECTED]  However, this is a question about glibc; glibc
is not part of gcc.  For glibc, please see
http://sourceware.org/glibc/ .

As far as I know the functions like exp and sin are all thread safe.

Ian

Re: gcc -r

[Ian Lance Taylor]

Ralf Corsepius <[EMAIL PROTECTED]> writes:

> So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ?

Ah, when you put the question like that, I would recommend "ld -r".
This is the one case where you get no advantage from using the gcc
driver to invoke the linker, and it can actually mess you up by adding
unexpected files to the command line.

Ian

inlining a virtual function

[Marco Correia]

hi,

The following is a simplification of my problem:

struct Base { virtual void func() = 0; };

struct Derived : Base { inline void func() {...} };

Derived& d = ...;
d.func();

This last call is not being inlined. Is this normal? (As I said my example is 
more complex, I didn't check if the above is inlined or not). Also in my 
example, compiling with -Winline does not warn me that it is not inlined. I 
discovered it only by profiling the executable.

I can provide more details, in case this does not have a trivial answer.

Thanks! (please email me directly as I'm not subscribed)
-- 
Marco Correia <[EMAIL PROTECTED]>

Re: Thread safe functions from the C standard library

[David Livshin]

Ian Lance Taylor wrote:

David Livshin <[EMAIL PROTECTED]> writes:

  

What functions from the GNU's C standard library ( libc ) are thread
safe? Of a particular interest are transcendental functions ( like
exp', 'sin' etc. ) - are they thread safe?

Are there any requirements/guidelines/assurances regarding thread
safety of functions from the  C library?



I'm sorry, this is the wrong mailing list.  This is a mailing list for
gcc developers.  Questions about using gcc should be sent to
[EMAIL PROTECTED]  However, this is a question about glibc; glibc
is not part of gcc.  For glibc, please see
http://sourceware.org/glibc/ .

As far as I know the functions like exp and sin are all thread safe.

Ian

  


Thank you for the pointer - I will redirect my question to the 
"libc-help" mailing list.


I thought that "gcc" mailing list is appropriate as I need this 
information in order to implement auto-parallelizer for the 
gcc-generated code. How the gcc-supported parallelizer (  
"-ftree-parallelize-loops=n" ) treats the calls to library routines?


--
David Livshin

http://www.dalsoft.com

Re: inlining a virtual function

[Ian Lance Taylor]

Marco Correia <[EMAIL PROTECTED]> writes:

> The following is a simplification of my problem:
>
> struct Base { virtual void func() = 0; };
>
> struct Derived : Base { inline void func() {...} };
>
> Derived& d = ...;
> d.func();
>
> This last call is not being inlined. Is this normal? (As I said my example is 
> more complex, I didn't check if the above is inlined or not). Also in my 
> example, compiling with -Winline does not warn me that it is not inlined. I 
> discovered it only by profiling the executable.

This question would be more appropriate for the [EMAIL PROTECTED]
mailing list.  Please direct any followups to that list.  Thanks.

In general it is not possible to inline a virtual function.  There
might be a subclass of Derived which itself has an implementation of
func.  Declaring func inline in Derived does not make it non-virtual.

Ian

Re: inlining a virtual function

[Sebastian Redl]

Marco Correia wrote:

hi,

The following is a simplification of my problem:

struct Base { virtual void func() = 0; };

struct Derived : Base { inline void func() {...} };

Derived& d = ...;
d.func();

This last call is not being inlined. Is this normal?
Yes. The compiler cannot know that d doesn't reference an object whose 
type is a class derived from Derived, which overrides func() again. 
Virtual calls can only be inlined if the compiler can statically 
determine the dynamic type of the expression.
 (As I said my example is 
more complex, I didn't check if the above is inlined or not). Also in my 
example, compiling with -Winline does not warn me that it is not inlined. I 
discovered it only by profiling the executable.
  

This might be considered a bug.

Sebastian

Re: gcc -r

[Adam Nemet]

Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
>> So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ?
>
> Ah, when you put the question like that, I would recommend "ld -r".
> This is the one case where you get no advantage from using the gcc
> driver to invoke the linker, and it can actually mess you up by adding
> unexpected files to the command line.

If a different linker emulation needs to be selected you're still better off
using gcc.  E.g., on linux64 n64 this:

  gcc -nostdlib -Wl,-r -mabi=64 ...

is probably easier to remember than this:

  ld -melf64btsmip -r ...

Adam

Re: gcc -r

[Ralf Corsepius]

On Tue, 2008-12-09 at 08:10 -0800, Adam Nemet wrote:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > Ralf Corsepius <[EMAIL PROTECTED]> writes:
> >
> >> So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ?
> >
> > Ah, when you put the question like that, I would recommend "ld -r".
> > This is the one case where you get no advantage from using the gcc
> > driver to invoke the linker, and it can actually mess you up by adding
> > unexpected files to the command line.
I know - We've recently been bitten by it ;)

> If a different linker emulation needs to be selected you're still better off
> using gcc.  E.g., on linux64 n64 this:
> 
>   gcc -nostdlib -Wl,-r -mabi=64 ...
> 
> is probably easier to remember than this:
> 
>   ld -melf64btsmip -r ...

I guess, I need to provide some background information:

In RTEMS, for historical reasons, we have been using: 
  gcc ... -nostdlib -Wl,-r ...

So, my questions actually were aiming at

* whether
 "gcc ... -nostdlib -r" 
and 
"gcc ... -nostdlib -Wl,-r"
are equivalent 

* if the fact that "gcc -r" appears to work, can be exploited or whether
this is a "random accident" and/or intentionally undocumented feature,
which may go away at any time.

Ralf

Re: gcc -r

[Adam Nemet]

Ralf Corsepius writes:
> So, my questions actually were aiming at
> 
> * whether
>  "gcc ... -nostdlib -r" 
> and 
> "gcc ... -nostdlib -Wl,-r"
> are equivalent 
> 
> * if the fact that "gcc -r" appears to work, can be exploited or whether
> this is a "random accident" and/or intentionally undocumented feature,
> which may go away at any time.

Right and Ian has already answered this.  I just wanted to add that AFAIC the
most portable way to specify a partial link is still through the gcc driver.

(Whether you use -Wl,-r or -r depends on your belief if this switch would ever
be used for something else in GCC.)

Adam

Re: Thread safe functions from the C standard library

[Ian Lance Taylor]

David Livshin <[EMAIL PROTECTED]> writes:

> I thought that "gcc" mailing list is appropriate as I need this
> information in order to implement auto-parallelizer for the
> gcc-generated code. How the gcc-supported parallelizer (
> "-ftree-parallelize-loops=n" ) treats the calls to library routines?

Sorry, I didn't realize that this was directly connected to gcc
development.  Within gcc, see gcc/builtins.defs.  A function which is
marked const or pure is thread-safe by definition.  Otherwise the
function must be presumed to be not thread-safe.

Ian

Re: TLS on darwin

[Richard Henderson]

... is the problem one of SPECs ?


I don't think so, unless we can key off -pthread or something.

.. or does every single TLS case need a darwin-specific addition to 
reference -lgcc_eh ?


We can add that via tls.exp.

.. I guess also that target-supports.exp would need some modification to 
account for this...


Yes, that would require changes.


r~

GCC 4.4.0 Status Report (2008-11-27)

[Mark Mitchell]

Status
==

The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.

As stated previously, the GCC 4.4 branch will be created when there
are no open P1s and the total number of P1, P2, and P3 regressions is
under 100.  We're close -- there are 5 P1s, and 105 total regressions.

(I see that one of the P1s is assigned to me; I will be trying to fix
that today.)

The other issue that remains is removing the old register allocator.
Vladimir, it's time to do this.  What -- if anything -- is preventing
that?

Quality Data


Priority  # Change from Last Report
--- ---
P15 -  4
P2  100 -  5
P30 - 11
--- ---
Total   105 - 20

Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-11/msg00343.html

The next report for 4.4.0 will be sent by Richard.

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: TLS on darwin

[IainS]

A little additional info:

PPC darwin8 (if configured --enable-tls --enable-threads) fails the  
check_effective_target_{tls, tls_runtime, tls_native} with a compiler  
ICE

viz, for example:
tls_native7888.c:3: internal compiler error: in  
rs6000_legitimize_tls_address, at config/rs6000/rs6000.c:4080


if configured (--enable-threads, or default) it behaves as described  
previously.


On 9 Dec 2008, at 19:14, Richard Henderson wrote:


... is the problem one of SPECs ?


I don't think so, unless we can key off -pthread or something.


one could conceive of making the TLS emulation specific with, say "- 
femulate-tls" (for those platforms that require it).


.. or does every single TLS case need a darwin-specific addition  
to reference -lgcc_eh ?

We can add that via tls.exp.


This needs to be included from places like libgomp - and possibly  
others.


I guess I'm also concerned about how one communicates this "need" to  
end-users.


Presumably, one should ideally use the version in libgcc_s.1?

There are also a whole other bunch of things in libgcc_eh (or  
libgcc_s.1) which, ultimately, leads to a worry about different parts  
of the same code ending up linked against different versions of the lib.


.. I guess also that target-supports.exp would need some  
modification to account for this...


Yes, that would require changes.


OK, thanks,
Iain

Re: GCC 4.4.0 Status Report (2008-11-27)

[Joel Sherrill]

Hi,

Is this one in the list?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440

Can Ada build on any Arm platform?  arm-rtems had
good test results for 4.3.2 but broke a few months ago.
I suspect it doesn't build targeting any Arm.

And I doubt this one is on the list but I am convinced
something is broken on x86_64-linux.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387

--joel

Mark Mitchell wrote:

Status
==

The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.

As stated previously, the GCC 4.4 branch will be created when there
are no open P1s and the total number of P1, P2, and P3 regressions is
under 100.  We're close -- there are 5 P1s, and 105 total regressions.

(I see that one of the P1s is assigned to me; I will be trying to fix
that today.)

The other issue that remains is removing the old register allocator.
Vladimir, it's time to do this.  What -- if anything -- is preventing
that?

Quality Data


Priority  # Change from Last Report
--- ---
P15 -  4
P2  100 -  5
P30 - 11
--- ---
Total   105 - 20

Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-11/msg00343.html

The next report for 4.4.0 will be sent by Richard.

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

�dv

[Anita]

Szia

Pár napja kérdezted hogy nem e tudok egy jó letöltős oldalt. És én
most találtam egyet.

Tele van jobbnál jobb filmekkel, és olcsó! 1 db sms elküldése után 500
kb/sec-el töltöttem napokig a legújabb premier filmeket és meséket!



Küldj most SMS-t,és 5 nap helyet,25-öt adunk,ez jelenlegi akciónk!



http://href.hu/x/7k7e

http://href.hu/x/7k7e



__

E-mail címed a Country jóvoltából került bele hírlevél rendszerünkbe.

Ha nem szeretnél több ilyet kapni. Írj a [EMAIL PROTECTED] email címre!

A küldő Fiktív, kitalált személy, de az e-mail címen elérsz
bennünket. 

Re: GCC 4.4.0 Status Report (2008-11-27)

[Richard Guenther]

On Tue, Dec 9, 2008 at 9:12 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is this one in the list?
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
>
> Can Ada build on any Arm platform?  arm-rtems had
> good test results for 4.3.2 but broke a few months ago.
> I suspect it doesn't build targeting any Arm.

To get on the radar regressions have to be marked [4.4 Regression],
with the target milestone set to 4.4.0, not [regression] at the end.

But with Ada it's going to be P4 anyway ;)

Richard.

> And I doubt this one is on the list but I am convinced
> something is broken on x86_64-linux.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
>
> --joel
>
> Mark Mitchell wrote:
>>
>> Status
>> ==
>>
>> The trunk remains Stage 4, so only fixes for regressions (and changes
>> to documentation) are allowed.
>>
>> As stated previously, the GCC 4.4 branch will be created when there
>> are no open P1s and the total number of P1, P2, and P3 regressions is
>> under 100.  We're close -- there are 5 P1s, and 105 total regressions.
>>
>> (I see that one of the P1s is assigned to me; I will be trying to fix
>> that today.)
>>
>> The other issue that remains is removing the old register allocator.
>> Vladimir, it's time to do this.  What -- if anything -- is preventing
>> that?
>>
>> Quality Data
>> 
>>
>> Priority  # Change from Last Report
>> --- ---
>> P15 -  4
>> P2  100 -  5
>> P30 - 11
>> --- ---
>> Total   105 - 20
>>
>> Previous Report
>> ===
>>
>> http://gcc.gnu.org/ml/gcc/2008-11/msg00343.html
>>
>> The next report for 4.4.0 will be sent by Richard.
>>
>> --
>> Mark Mitchell
>> CodeSourcery
>> [EMAIL PROTECTED]
>> (650) 331-3385 x713
>>
>>
>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> [EMAIL PROTECTED]On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>  Support Available (256) 722-9985
>
>
>

Re: GCC 4.4.0 Status Report (2008-11-27)

[Joel Sherrill]

Richard Guenther wrote:

On Tue, Dec 9, 2008 at 9:12 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
  

Hi,

Is this one in the list?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440

Can Ada build on any Arm platform?  arm-rtems had
good test results for 4.3.2 but broke a few months ago.
I suspect it doesn't build targeting any Arm.



To get on the radar regressions have to be marked [4.4 Regression],
with the target milestone set to 4.4.0, not [regression] at the end.

But with Ada it's going to be P4 anyway ;)
  

:)  Thanks for correcting the subjects and taking a
2nd look at the psim one.

Richard.

  

And I doubt this one is on the list but I am convinced
something is broken on x86_64-linux.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387

--joel


Mark Mitchell wrote:


Status
==

The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.

As stated previously, the GCC 4.4 branch will be created when there
are no open P1s and the total number of P1, P2, and P3 regressions is
under 100.  We're close -- there are 5 P1s, and 105 total regressions.

(I see that one of the P1s is assigned to me; I will be trying to fix
that today.)

The other issue that remains is removing the old register allocator.
Vladimir, it's time to do this.  What -- if anything -- is preventing
that?

Quality Data


Priority  # Change from Last Report
--- ---
P15 -  4
P2  100 -  5
P30 - 11
--- ---
Total   105 - 20

Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-11/msg00343.html

The next report for 4.4.0 will be sent by Richard.

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713


  

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
 Support Available (256) 722-9985







--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: GCC 4.4.0 Status Report (2008-11-27)

[Martin Guy]

On 12/9/08, Joel Sherrill <[EMAIL PROTECTED]> wrote:
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
>
>  Can Ada build on any Arm platform?

The only existing GNAT Ada compiler I could find for ARM (while
thinking about doing it for the new Debian eabi port) is Adacore's
Windows->Nucleus OS crosscompiler for Xscale CPUs, though they don't
say what version of GCC they use. Then my funding ran out.
  My impression at the time, and that of the Debian Ada maintainer,
was that it is a case of no one ever having made the effort to
cross-bootstrap a native linux compiler but that it "should just go".

If anyone cares enough I'm open to offers to try it...

M

Re: GCC 4.4.0 Status Report (2008-11-27)

[Joel Sherrill]

Martin Guy wrote:

On 12/9/08, Joel Sherrill <[EMAIL PROTECTED]> wrote:
  

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440

 Can Ada build on any Arm platform?



The only existing GNAT Ada compiler I could find for ARM (while
thinking about doing it for the new Debian eabi port) is Adacore's
Windows->Nucleus OS crosscompiler for Xscale CPUs, though they don't
say what version of GCC they use. Then my funding ran out.
  My impression at the time, and that of the Debian Ada maintainer,
was that it is a case of no one ever having made the effort to
cross-bootstrap a native linux compiler but that it "should just go".

If anyone cares enough I'm open to offers to try it...

  

It would be good to put another arm OS on it to show it
isn't OS specific.

FWIW arm-rtems Ada built fine for  gcc 4.3.2 and
there are ACATS results here:

http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01305.html

=== acats Summary ===
# of expected passes 2305
# of unexpected failures 7
# of unsupported tests 3

These were run using the edb7312 RTEMS BSP on the
Skyeye simulator.


M
  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: GCC 4.4.0 Status Report (2008-11-27)

[Vladimir Makarov]

Mark Mitchell wrote:

Status
==

The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.

As stated previously, the GCC 4.4 branch will be created when there
are no open P1s and the total number of P1, P2, and P3 regressions is
under 100.  We're close -- there are 5 P1s, and 105 total regressions.

(I see that one of the P1s is assigned to me; I will be trying to fix
that today.)

The other issue that remains is removing the old register allocator.
Vladimir, it's time to do this.  What -- if anything -- is preventing
that?

  
Today Jeff Law (many thanks to him!) approved a big patch I wanted to 
commit before submitting patch removing the old register allocator.  So 
nothing prevents to remove the old RA.


I am going to submit the patch removing the old RA for review today.  
Sorry for long waiting.

Re: GCC 4.4.0 Status Report (2008-11-27)

[Hans-Peter Nilsson]

On Tue, 9 Dec 2008, Vladimir Makarov wrote:
> Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit
> before submitting patch removing the old register allocator.  So nothing
> prevents to remove the old RA.
>
> I am going to submit the patch removing the old RA for review today.  Sorry
> for long waiting.

Vladimir, have you had chance to look at supporting
LOAD_EXTEND_OP (implicit sign-extension) in IRA?



I'm guessing no, but hope it's not forgotten.

I intend to write a PR this weekend if you need specific
information.

(I'm still ok with removing support for it, but combine needs
fixing too, to not (ab)use it.)

brgds, H-P

Re: GCC 4.4.0 Status Report (2008-11-27)

[Vladimir Makarov]

Hans-Peter Nilsson wrote:

On Tue, 9 Dec 2008, Vladimir Makarov wrote:
  

Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit
before submitting patch removing the old register allocator.  So nothing
prevents to remove the old RA.

I am going to submit the patch removing the old RA for review today.  Sorry
for long waiting.



Vladimir, have you had chance to look at supporting
LOAD_EXTEND_OP (implicit sign-extension) in IRA?



I'm guessing no, but hope it's not forgotten.

  

It seems I missed that, sorry.  I'll look at the problem on this week.

May be a patch I committed today solves the problem (it permits to work 
IRA without defining IRA_COVER_CLASSES).  I'll check it later.

I intend to write a PR this weekend if you need specific
information.

(I'm still ok with removing support for it, but combine needs
fixing too, to not (ab)use it.)

  

Re: GCC 4.4.0 Status Report (2008-11-27)

[Hans-Peter Nilsson]

On Tue, 9 Dec 2008, Vladimir Makarov wrote:
> Hans-Peter Nilsson wrote:
> > Vladimir, have you had chance to look at supporting
> > LOAD_EXTEND_OP (implicit sign-extension) in IRA?
> > 
> > I'm guessing no, but hope it's not forgotten.
> It seems I missed that, sorry.  I'll look at the problem on this week.
>
> May be a patch I committed today solves the problem (it permits to work IRA
> without defining IRA_COVER_CLASSES).  I'll check it later.

For the record, the issue there, isn't really how to define
IRA_COVER_CLASSES, (so I guess "no"), it's whether the
transformations combine does, that uses LOAD_EXTEND_OP (i.e.
whether reads from memory are implicitly extended), are handled
by the register allocator.

brgds, H-P

Re: GCC 4.4.0 Status Report (2008-11-27)

[Steven Bosscher]

On Tue, Dec 9, 2008 at 8:39 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> The other issue that remains is removing the old register allocator.
> Vladimir, it's time to do this.  What -- if anything -- is preventing
> that?

What about sched-ebb?  Wasn't that supposed to be removed after the
selective scheduler merge?

Gr.
Steven

Re: GCC 4.4.0 Status Report (2008-11-27)

[Jeff Law]

Hans-Peter Nilsson wrote:

On Tue, 9 Dec 2008, Vladimir Makarov wrote:
  

Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit
before submitting patch removing the old register allocator.  So nothing
prevents to remove the old RA.

I am going to submit the patch removing the old RA for review today.  Sorry
for long waiting.



Vladimir, have you had chance to look at supporting
LOAD_EXTEND_OP (implicit sign-extension) in IRA?



I'm guessing no, but hope it's not forgotten.

I intend to write a PR this weekend if you need specific
information.
Yes, please create a PR to track this issue so that it doens't get 
completely lost.


jeff