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
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
File libgomp/config/posix95/lock.c
It implemnts recursive mutexes with the intuitive idea (in the header)
typedef struct
{
pthread_mutex_t lock;
pthread_t owner;
int count;
} omp_nest_lock_t;
However when this is implemented in config/posix95/lock.c
void
omp_unset_nest_lock (omp_nest_loc
On Thu, 5 Mar 2009, Ralf Wildenhues wrote:
> If you are rerunning things manually, in libgomp you need to use
> aclocal -I .. -I ../config
> autoconf
> automake
Well i dont run aclocal and automake as I have not mods that are related
to those tools. I guess thats causing my issue.
> and
Hi,
Seems that libgomp is part of GCC and not a separate project right?
So i am posting this here.
I have a new target for this library that I want to add. Hence I am
modifying configure.tgt, source files etc and also adding some new
threads stuff on the configure.ac However when I recreate the c
On Mon, 2 Mar 2009, Andrew Pinski wrote:
> On Mon, Mar 2, 2009 at 5:16 AM, Takis Psarogiannakopoulos
> wrote:
> > Also you saying basically that there is no other way to customize
> > GCC (anymore) other than to hack the original .opt source files. I would
> > prefer
On Mon, 2 Mar 2009, Joseph S. Myers wrote:
> On Mon, 2 Mar 2009, Takis Psarogiannakopoulos wrote:
>
> > > The only use of
> > > SUBTARGET_SWITCHES was to be expanded by the TARGET_SWITCHES macro.
> > >
> > Exactly. The feature was there for the last 15
On Mon, 2 Mar 2009, Joseph S. Myers wrote:
> On Mon, 2 Mar 2009, Takis Psarogiannakopoulos wrote:
>
> > > The only use of
> > > SUBTARGET_SWITCHES was to be expanded by the TARGET_SWITCHES macro.
> > >
> > Exactly. The feature was there for the last 15
Ian thanks for you answer,
On Sun, 1 Mar 2009, Ian Lance Taylor wrote:
>
> SUBTARGET_SWITCHES shouldn't have anything to do with ASM_SPEC.
>
Unfortunately it does. Mark was right for the asmspec in
rest_of_decl_compilation but the subtarget switches needed. In a sense
what you saying above is tr
On Sun, 1 Mar 2009, Mark Mitchell wrote:
> >> I think there's some confusion here. There is no relationship between
> >> the ASM_SPEC definition in a config *.h file regarding options to be
> >> passed to the assembler and the old "asmspec" parameter to
> >> rest_of_decl_compilation, which relat
Hi Mark,
Thanks for answering.
On Sun, 1 Mar 2009, Mark Mitchell wrote:
> I think there's some confusion here. There is no relationship between
> the ASM_SPEC definition in a config *.h file regarding options to be
> passed to the assembler and the old "asmspec" parameter to
> rest_of_decl_co
Hi,
Also another thing I dont see in GCC 4.x.x but I know it was alive and
kicking on the GCC 3.4.6 branch is the subtarget switches custom macro.
Eg in the gcc.config/.h OS specific file we could define something like
that:
#define MASK_STANDARD0x4000 /* Retain standard information
Hello,
I want to build 4.3.3 on an SVR4 (obviously port is required as its not a
std target) but I have stumble on the following issue regarding ASM_SPEC
extra switches:
On the host's (*.h) file in gcc/config we define
#undef ASM_SPEC
#define ASM_SPEC " \
%{mno-legend:-Wc,off} \
%{g:%{!mno-leg
13 matches
Mail list logo
