Hi Jeff,
I've downloaded and compiled gcc 4.4.7 (same as stock Centos version).
Unfortunately, the program no longer compiles, giving an error "This platform
does not support exception propagation". (I don't know what that means).
Any suggestion on how to get around this?
Thanks,
Danny
/home/
Hi Tom,
I omitted -march (didn't have -mcpu), but unfortunately exactly same error.
Now recompiling g++ 4.4.7 from source as per suggestion from Jeff Hammond.
Danny
On 29/11/2016, at 8:19 PM, Tom Hughes wrote:
>> For -march I've tried 'native', 'pentiumpro' and 'core2'.
>> When compiling for v
Super - thanks so much. Working on small emergency so will be able to get back
to this on Saturday. Fingers crossed.
Danny
On 29/11/2016, at 8:19 PM, Tom Hughes wrote:
>> For -march I've tried 'native', 'pentiumpro' and 'core2'.
>> When compiling for valgrind, also -O0.
>
> Well native is de
On 29/11/16 12:10, Danny Wilson wrote:
> For -march I've tried 'native', 'pentiumpro' and 'core2'.
> When compiling for valgrind, also -O0.
Well native is definitely not going to work, and core2 might be pushing
it, but pentiumpro should be fine. To be honest just leaving out -march
and -mcpu s
Hi Tom,
For -march I've tried 'native', 'pentiumpro' and 'core2'.
When compiling for valgrind, also -O0.
# cat /etc/redhat-release
CentOS release 6.6 (Final)
# uname -a
Linux dvstor5 3.10.80-1.el6.elrepo.i686 #1 SMP Sun Jun 7 08:15:14 EDT 2015 i686
i686 i386 GNU/Linux
Danny
On 29/11/2016, at
Hi Jeff,
Thanks, I'll give it a shot!
From the previous messages in this thread, the target machine is an 6500 series
i5. When rebuilding gcc, what value for -march would be appropriate?
Danny
On 29/11/2016, at 12:35 PM, Jeff Hammond wrote:
> Based upon your prior report showing the illegal
On 29/11/16 09:42, Alex Bligh wrote:
>> On 29 Nov 2016, at 01:29, Danny Wilson wrote:
>>
>> Hi Alex, rebuilding the standard libraries is a little beyond our scope (and
>> I'd figure it unlikely that such a basic function of the c++ library had a
>> memory leak. Something like that would be we
Danny,
> On 29 Nov 2016, at 01:29, Danny Wilson wrote:
>
> Hi Alex, rebuilding the standard libraries is a little beyond our scope (and
> I'd figure it unlikely that such a basic function of the c++ library had a
> memory leak. Something like that would be well published). As Tom pointed
>
On Mon, Nov 28, 2016 at 5:29 PM, Danny Wilson wrote:
> On 28/11/2016, at 8:07 PM, Alex Bligh wrote:
> >
> >> On 27 Nov 2016, at 16:09, Danny Wilson wrote:
> >>
> >> The target machines uses an i5 CPU but the build machine is a core2 duo
> which is why I chose 'native'. Not sure that was the rig
On 28/11/2016, at 8:07 PM, Alex Bligh wrote:
>
>> On 27 Nov 2016, at 16:09, Danny Wilson wrote:
>>
>> The target machines uses an i5 CPU but the build machine is a core2 duo
>> which is why I chose 'native'. Not sure that was the right choice but it
>> works (without Valgrind).
>>
>> I've ju
> On 27 Nov 2016, at 16:09, Danny Wilson wrote:
>
> The target machines uses an i5 CPU but the build machine is a core2 duo which
> is why I chose 'native'. Not sure that was the right choice but it works
> (without Valgrind).
>
> I've just tried -march as 'native', 'core2', and 'pentiumpro'
The target machines uses an i5 CPU but the build machine is a core2 duo which
is why I chose 'native'. Not sure that was the right choice but it works
(without Valgrind).
I've just tried -march as 'native', 'core2', and 'pentiumpro'. All have the
same result.
(and you are right: the SIGILL h
On 27/11/16 10:28, Danny Wilson wrote:
> The build machine is a core2 duo running 32-bit Centos 6.6 and custom
> kernel 3.10.
>
> I recompiled the app using --march=native and --march=pentiumpro, but
> got the same error.
Don't use -march=native - that is telling the compiler to use everything
m
Hi Jeff,
I put a SIGILL handler in. Running normally without valgrind shows the signal
is caught and ignored (when kill -ILL is sent)
But it seems that valgrind is disabling my signal handler. Running under
valgrind still exits with
> Valgrind will now raise a SIGILL signal which will proba
The build machine is a core2 duo running 32-bit Centos 6.6 and custom kernel
3.10.
I recompiled the app using --march=native and --march=pentiumpro, but got the
same error.
I'll try the SIGKILL handler now.
Danny
> vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
> ==29426== valg
On 27/11/16 03:46, Danny Wilson wrote:
> It is a huge application, 1.5M lines not including big external dependencies
> like ACE/TAO. Porting over to 64bit mode would probably take months. Any
> other suggestion? Perhaps disabling the generation of the offending AVX
> instructions with some co
Hi Tom,
Thanks for the response.
It is a huge application, 1.5M lines not including big external dependencies
like ACE/TAO. Porting over to 64bit mode would probably take months. Any other
suggestion? Perhaps disabling the generation of the offending AVX instructions
with some compiler flag?
> Thanks for the response.
>
> It is a huge application, 1.5M lines not including big external dependencies
> like ACE/TAO. Porting over to 64bit mode would probably take months. Any
> other suggestion? Perhaps disabling the generation of the offending AVX
> instructions with some compiler flag
On 26/11/16 15:36, Jeffrey Walton wrote:
> On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson wrote:
>> I am trying to find a memory leak in a large C++ program which utilizes
>> multiple shared libraries.
>>
>> Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9
>> 0x6E 0x45"
>>
On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson wrote:
> I am trying to find a memory leak in a large C++ program which utilizes
> multiple shared libraries.
>
> Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9
> 0x6E 0x45"
>
> It says the illegal instruction is inside std:
I am trying to find a memory leak in a large C++ program which utilizes
multiple shared libraries.
Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9 0x6E
0x45"
It says the illegal instruction is inside std::tr1::__detail, inside a standard
library...
Is there anything
21 matches
Mail list logo
