> I believe the following should fix this for you, at least for libgomp.
> If you have a system for which the thread-id 0 is actually used, would
> you mind testing it?
This code is dead, it was only used for Solaris 2.5.1 and 2.6 and we don't
support these versions any longer, see config.gcc. I
Snapshot gcc-4.5-20100107 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100107/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
I am almost convinced I had tried that already but apparently not.
This seems to have fixed my problem, thank you :-)
Jc
On Thu, Jan 7, 2010 at 4:14 PM, Richard Henderson wrote:
> On 01/07/2010 12:58 PM, Jean Christophe Beyler wrote:
>>
>> Dear all,
>>
>> I've gone to using unspec and I think I
On 01/07/2010 12:58 PM, Jean Christophe Beyler wrote:
Dear all,
I've gone to using unspec and I think I know why I have a problem. It
seems that actually, the problem lies with the fact that these
instructions are touching an internal register and how I am handling
that register.
Since I don't
On 01/07/2010 01:59 AM, Takis Psarogiannakopoulos wrote:
The right thing to do is use the depth (count above) of the mutex to
decide if the mutex is free. The owner shoud be valid only if the mutex is
locked.
I believe the following should fix this for you, at least for libgomp.
If you have a s
Dear all,
I've gone to using unspec and I think I know why I have a problem. It
seems that actually, the problem lies with the fact that these
instructions are touching an internal register and how I am handling
that register.
Since I don't want the register allocator to use that register, I put
On 01/06/10 12:54:21, Ian Lance Taylor wrote:
> I think you need to make sure that the script removes any existing
> config.cache files.
Ian, thanks. This turned out to be a cockpit error on my part.
The reghunt tools apparently expect the checked out gcc source tree
to have the form /gcc; thus t
Paulo J. Matos wrote:
> The problem with this is that I only want to sibcall when it happens
> to reduce my code size.
>
> I noticed (in the internals manual) we cannot actually fallback to a
> normal call once we decide to sibcall through FUNCTION_OK_FOR_SIBCALL,
> however, FUNCTION_OK_FOR_SIBCA
Paulo J. Matos wrote:
> This case is interesting because it seems that callee is being inlined
> into caller. Still intriguing is that the same happens with: -Os
> -fno-inline -fno-inline-small-functions
> -fno-inline-functions-called-once
There are loads of other inline-related -f options apar
On Thu, Jan 7, 2010 at 11:46 AM, Paulo J. Matos wrote:
> Hi all,
>
> With the code:
> -
> extern void display(unsigned int);
>
> void callee(int z) // Sibcall worth it
> {
> display(z);
> }
>
> void caller(int x, int y) // Sibcall not worth it
> {
> display(x);
>
On 01/07/2010 11:42 AM, Richard Guenther wrote:
> On Thu, Jan 7, 2010 at 12:29 PM, Andrew Haley wrote:
>> On 01/06/2010 07:24 PM, Joshua Haberman wrote:
>>
>> The response I think you may get is that this is already settled.
>> I've seen this same argument many times (in mailing lists and in
>> c
Hi all,
With the code:
-
extern void display(unsigned int);
void callee(int z) // Sibcall worth it
{
display(z);
}
void caller(int x, int y) // Sibcall not worth it
{
display(x);
display(y);
callee(x*y);
}
-
I have put a f
On Thu, Jan 7, 2010 at 12:29 PM, Andrew Haley wrote:
> On 01/06/2010 07:24 PM, Joshua Haberman wrote:
>
>> In the notes that Nick referenced it says:
>>
>> Is there anybody that thinks the rules are clear enough? No one is
>> really able to interpret them. So it seems that they are not
>>
On 01/06/2010 07:24 PM, Joshua Haberman wrote:
> In the notes that Nick referenced it says:
>
> Is there anybody that thinks the rules are clear enough? No one is
> really able to interpret them. So it seems that they are not
> clear enough. The problem is how to state them.
>
> [...
On Thursday 07 January 2010, Richard Earnshaw wrote:
> On Wed, 2010-01-06 at 18:26 +, Paul Brook wrote:
> > On Wednesday 06 January 2010, Carrot Wei wrote:
> > > So thumb2 can also use the instructions similar to thumb1, right? It
> > > potentially has better performance and smaller code size.
On Thu, 7 Jan 2010, Andrew Pinski wrote:
> As long as owner is not used when count is 0, then I don't see an
> issue. Note I know libobjc does implement it incorrectly; I have not
> had time to fix that.
> Thanks,
> Andrew Pinski
>
Absolutely right, unfortunately on all cases I am reffereed th
On Wed, 2010-01-06 at 18:26 +, Paul Brook wrote:
> On Wednesday 06 January 2010, Carrot Wei wrote:
> > So thumb2 can also use the instructions similar to thumb1, right? It
> > potentially has better performance and smaller code size.
>
> Technically yes, however in ARMv7 the relevant instruct
Sent from my iPhone
On Jan 7, 2010, at 1:59 AM, Takis Psarogiannakopoulos
wrote:
Guys,
While looking the GCC code, all the releases really from the 3.X.X
the GNU gettext/libintl lock.c,h code the GCC/libjava code, the
GCC/libgomp code, I have observed that the thread-id zero is widely
Guys,
While looking the GCC code, all the releases really from the 3.X.X
the GNU gettext/libintl lock.c,h code the GCC/libjava code, the
GCC/libgomp code, I have observed that the thread-id zero is widely
used to initialize/free recursive mutexes/monitors etc.
Eg GCC 4.X.X, libgomp/config/posi
Hello,
I have been trying to implement sibcalls (you can see my digression
yesterday in gcc-help) for an arch with gcc 4.3.4.
The problem with this is that I only want to sibcall when it happens
to reduce my code size.
I noticed (in the internals manual) we cannot actually fallback to a
normal ca
On Thu, Jan 07, 2010 at 03:53:59AM -0500, Jakub Jelinek wrote:
> On Thu, Jan 07, 2010 at 09:48:53AM +0100, Gabriel Paubert wrote:
> > > apparently rs6000_emit_set_long_const needs work.
> > > lis 3,0x8034
> > > extsw 3,3
> > > or
> > > li 3,0x401a
> > > sldi 3,3,17
> > > etc. do IMHO the sa
I've been working on instruction scheduling issues for our (Ubicom) ISA
and have run into a problem I can't seem to resolve.
The pipeline has a major hazard associated with the generation of
addresses that are loaded from memory - the hazard window is 4
instructions. This is more than enough time
On Thu, Jan 07, 2010 at 09:48:53AM +0100, Gabriel Paubert wrote:
> > apparently rs6000_emit_set_long_const needs work.
> > lis 3,0x8034
> > extsw 3,3
> > or
> > li 3,0x401a
> > sldi 3,3,17
> > etc. do IMHO the same.
>
> Huh? I don't think so:
>
> - first one loads 0x__8034
On Wed, Jan 06, 2010 at 04:18:06PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 06, 2010 at 10:15:58AM +, Andrew Haley wrote:
> > On 01/06/2010 09:59 AM, Mark Colby wrote:
> > Yabbut, how come RTL cse can handle it in x86_64, but PPC not?
> > >>>
> > >>> Probably because the RTL on x86_64 use
24 matches
Mail list logo
