On 7/4/2014 12:08 AM, Hans-Peter Nilsson wrote:
Currently, c-cppbuiltin.c doesn't provide proper defines for this support.
> >We
> >currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in
> >pa-linux.h.
I thought that was cheating! 1/2:)
> I'll experiment with defining ATOMIC_INT_LOCK_F
On Tue, 1 Jul 2014, Jonathan Wakely wrote:
> On 1 July 2014 20:58, John David Anglin wrote:
> > On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
> >
> >> On 1 July 2014 09:40, Matthias Klose wrote:
> >>>
> >>> - HPPA (build log [2]), is missing all the future_base symbols and
> >>> exception_ptr1
ure_base symbols and
exception_ptr13exception symbols, current_exception and
rethrow_exception.
- SPARC (build log [3]) configured for sparc64-linux-gnu is missing
symbols in the 32bit multilib build, although these are present
in a sparc-linux-gnu build. Missing are same ones as in the
On 01/07/14 20:58, John David Anglin wrote:
On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
On 1 July 2014 09:40, Matthias Klose wrote:
- HPPA (build log [2]), is missing all the future_base symbols and
exception_ptr13exception symbols, current_exception and
rethrow_exception.
This i
On 1-Jul-14, at 4:40 AM, Matthias Klose wrote:
Looks like more than one issue is involved, I remember that the
math symbols were already dropped in earlier versions for other
architectures. The build is configured -with-long-double-128.
Long double is 64 bits on hppa-linux.
Dave
--
John
throw_exception.
>
> - SPARC (build log [3]) configured for sparc64-linux-gnu is missing
>symbols in the 32bit multilib build, although these are present
>in a sparc-linux-gnu build. Missing are same ones as in the HPPA
>build, long double 128 related symbols, numeric_
On 1 July 2014 20:58, John David Anglin wrote:
> On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
>
>> On 1 July 2014 09:40, Matthias Klose wrote:
>>>
>>> - HPPA (build log [2]), is missing all the future_base symbols and
>>> exception_ptr13exception symbols, current_exception and
>>> rethrow_ex
On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
On 1 July 2014 09:40, Matthias Klose wrote:
- HPPA (build log [2]), is missing all the future_base symbols and
exception_ptr13exception symbols, current_exception and
rethrow_exception.
This implies ATOMIC_INT_LOCK_FREE <= 1 for that target.
OMIC_INT_LOCK_FREE <= 1 for that target. Our future and
> exception_ptr implementations rely on usable atomics.
thanks for the reminder. then the same missing symbols for sparc is a missing
--with-cpu-32=ultrasparc.
Matthias
xception_ptr implementations rely on usable atomics.
I don't know about the other missing symbols.
1.3.3
__aeabi_vec_*
Can these be ignored?
- HPPA (build log [2]), is missing all the future_base symbols and
exception_ptr13exception symbols, current_exception and
rethrow_exception.
- SPARC (build log [3]) configured for sparc64-linux-gnu is missing
symbols in the 32bit multilib
On 09/24/2011 12:23 AM, David Edelsohn wrote:
My latest bootstrap of GCC on AIX failed due to missing symbols in
libstdc++ expected by libgmpxx:
On x86_64-linux are both still exported. And for sure nobody worked on
the code itself. I would say, it's a compiler issue..
Paolo.
My latest bootstrap of GCC on AIX failed due to missing symbols in
libstdc++ expected by libgmpxx:
exec(): 0509-036 Cannot load program exec(): 0509-036 Cannot load
program /tmp/20110922/./gcc/cc1plus/tmp/20110922/./g
cc/cc1plus because of the following errors:
because of the following errors
On 14/10/2010 19:11, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> The consequence of this is that either there are going to be undefined
>> symbols in the final executable, or the linker has to perform another round
>> of
>> library scanning. It occurred to me that the semantics of this mi
On 14/10/2010 17:12, Dave Korn wrote:
> On 14/10/2010 16:24, Richard Guenther wrote:
>> On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn
>> wrote:
>>> I *think* that re-adding the stdlibs after all
>>> the new input files in the plugin might work, but haven't tried it yet.
It does do the job, and I
Dave Korn writes:
> The consequence of this is that either there are going to be undefined
> symbols in the final executable, or the linker has to perform another round of
> library scanning. It occurred to me that the semantics of this might even not
> have been decided yet, since ELF platfor
On 14/10/2010 16:24, Richard Guenther wrote:
> On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn wrote:
>> On 14/10/2010 15:44, Richard Guenther wrote:
>>> I have no idea about the linker-plugin side, but we could of course
>>> avoid generating any calls that were not there before (by for example
>>> st
On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn wrote:
> On 14/10/2010 15:44, Richard Guenther wrote:
>> On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn
>> wrote:
>
>>> Nor indeed is there any sign of puts, which is what the generated ltrans0.s
>>> file ends up optimising it to (as indeed does the native
On 14/10/2010 15:44, Richard Guenther wrote:
> On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn wrote:
>> Nor indeed is there any sign of puts, which is what the generated ltrans0.s
>> file ends up optimising it to (as indeed does the native code in the original
>> .o file). I'm assuming that this is
On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn wrote:
>
> Hello list,
>
> When I compile this source with -flto:
>
>> extern int retval;
>> int func (void)
>> {
>> return retval;
>> }
>
> ... the LTO symbol table contains both symbols:
>
>> /gnu/binutils/git.repo/obj/ld/test/func.o: file for
Hello list,
When I compile this source with -flto:
> extern int retval;
> int func (void)
> {
> return retval;
> }
... the LTO symbol table contains both symbols:
> /gnu/binutils/git.repo/obj/ld/test/func.o: file format pe-i386
>
> Contents of section .gnu.lto_.symtab.227b80e3:
>
On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote:
On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote:
> In the following code, compiled with
> g++ cls.cc -Wall -W -g3 -o cls
>
> why only only virtual functions f1, f2 and constructor is listed by nm.
Because they are needed for the vtable. While f
On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote:
In the following code, compiled with
g++ cls.cc -Wall -W -g3 -o cls
why only only virtual functions f1, f2 and constructor is listed by nm.
Only debugging symbols for virtual functions are included in
executable output file ?
//cls.cc
#include
In the following code, compiled with
g++ cls.cc -Wall -W -g3 -o cls
why only only virtual functions f1, f2 and constructor is listed by nm.
Only debugging symbols for virtual functions are included in
executable output file ?
//cls.cc
#include
using namespace std;
class test
{
public:
i
24 matches
Mail list logo
