On Mon, Dec 05, 2011 at 04:47:08PM +, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Dave Martin writes:
> >> Another way of doing a similar thing is to mark __mylib_constructor
> >> as undefined in all the objects that make up the library.
> >>
> >> Unfortunately, there seems to be
Richard Sandiford writes:
> Dave Martin writes:
>> Another way of doing a similar thing is to mark __mylib_constructor
>> as undefined in all the objects that make up the library.
>>
>> Unfortunately, there seems to be no obvious way of doing that: the
>> assembler generates undefined symbol refe
Dave Martin writes:
> Another way of doing a similar thing is to mark __mylib_constructor
> as undefined in all the objects that make up the library.
>
> Unfortunately, there seems to be no obvious way of doing that: the
> assembler generates undefined symbol references automatically for
> unresol
> On Mon, Dec 5, 2011 at 1:40 AM, Tom Gall wrote:
> > I probably know the answer to this already but ...
> >
> > For shared libs one can define and use something like:
> >
> > void __attribute__ ((constructor)) my_init(void);
> > void __attribute__ ((destructor)) my_fini(void);
> >
> > Which of co
* Linaro GCC
Continued work on 64-bit shift / extend / etc. in NEON. I have posted an
RFC to the gcc-patches list in the hope of getting some feedback on how
best to fix this. No response yet. Hopefully some of the Linaro guys are
at least looking at it ...
Merged FSF GCC 4.5 and 4.6 into th
==Progress===
* Off sick on Monday
* Systematic testing duty - few Aarch64 issues.
* Linaro patch review duty.
* Tested my vcvt fixed point patch and close to committing.
* Worked on sometime on movw / movt for symbol references rather than
constant pools . While this gives nice benefits it's a c
