Re: gcc-4.9.2: Assembly for i386 Target

On Mon, Oct 12, 2015 at 11:11 AM, Abhishek Aggarwal wrote: > I was befuddled by the following 3 assembly instructions (generated > right in the beginning of 'main' function): >lea 0x4(%esp), %ecx >and 0xfff0, %esp >pushl -0x4(%ecx) > > I am not able to understand the p

Re: gcc-4.9.2: Assembly for i386 Target

On Mon, Oct 12, 2015 at 1:06 PM, Abhishek Aggarwal wrote: > @Jonathan: The reason I started this discussion is due to my suspicion > of a potential bug in gcc-4.9.2. However, I may be wrong. Here is the > explanation: I think everything is alright. The code is only emitted for the main function,

Re: how to tweak x86 code generation to instrument certain opcodes with CC trap?

On Mon, Oct 26, 2015 at 8:47 PM, Yasser Shalabi wrote: > So back to square one. Any tips on what code/config-files I need to > modify with to get GCC to emit additional opcodes for certain > instructions? Maybe you should try cross-compiling. It looks like you have already succeeded with the inst

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) wrote: > The point is to permit the compiler to use interworking compatible > sequences of code when generating ARM code, not to force users to use > Thumb code. The necessary instruction (BX) is available in armv5 and > armv5e, even thou

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On Thu, Feb 25, 2016 at 3:15 PM, David Brown wrote: > The "t" is thumb, "e" means "DSP-like extensions", and I suspect the "l" > is a misprint for "j", meaning the Jazelle (Java) acceleration instructions. I doubt that as "armv5tejl" is also quite common.

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On Thu, Feb 25, 2016 at 3:15 PM, David Brown wrote: > Great link, thanks!

Re: no response to cfarm request

On Tue, Dec 16, 2014 at 10:13 AM, Jay Foad wrote: > I've pinged again and waited another week with no response. Is there > no-one else who can administer compile farm accounts? Maybe you should try the gcc-cfarm mailing list: https://mail.gna.org/listinfo/gcc-cfarm-users It seems very responsive

Re: Building on gcc112 is stuck in msgfmt

On Tue, Aug 29, 2017 at 9:32 AM, Martin Liška wrote: > On 08/28/2017 09:15 PM, Martin Liška wrote: >> On 08/28/2017 04:06 PM, Jeff Law wrote: >>> On 08/28/2017 01:16 AM, Martin Liška wrote: Hello. I've just repeatedly seen stuck in build process: make[5]: Entering director

Missed possible branch elimination

While poring over the Transport Tycoon Deluxe disassembly, commonly known to have been hand-written in assembler, I stumbled across this tidbit, which I think is kinda neat: 004057F7 83 7D B8 01 cmp dword ptr [ebp-48h],1 004057FB 1B C0sbb eax,eax 004057FD F

Re: Missed possible branch elimination

On Thu, Oct 26, 2017 at 8:23 PM, Stefan Ring wrote: > While poring over the Transport Tycoon Deluxe disassembly, commonly > known to have been hand-written in assembler, I stumbled across this > tidbit, which I think is kinda neat: > > 004057F7 83 7D B8 01 cmp dwo

RedHat patch not found in mainline gcc

At the company where I work, we have a large program using Boost Python (1.54). We do our product builds for RHEL 5 and recently started building using gcc 4.8 from RedHat devtoolset 2 for performance. This works well, except for one system where it would deterministically crash. I traced it to an

Re: RedHat patch not found in mainline gcc

> I don't remember it well, but from re-reading the gcc-patches threads around > that time like: > http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html That thread is from 2009. > it seems that the actually committed fix for the bug that the > gcc41-unwind-restore-state.patch was meant to fix

Re: RedHat patch not found in mainline gcc

>> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html > > That thread is from 2009. > >> it seems that the actually committed fix for the bug that the >> gcc41-unwind-restore-state.patch was meant to fix was >> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00617.html committed as >> http://gcc.