On 05/14/2018 10:55 PM, Jeff Law wrote:
> That does sound vaguely familiar. Did we put autoinc notes on the stack
> pushes?
Not as far as I recall. I only see REG_ARGS_SIZE notes in the dumps.
> That makes me wonder if there is a latent bug though. Consider pushing
> args to a pure function. C
Hi,
I'm a firmware/embedded engineer and frequently run into cases where
certain parts of the code need to be placed in a special memory area (for
example, because the area that contains the other code is not yet
initialized or currently inaccessible). My go-to method to solve this is to
mark all
On 14 May 2018 at 22:32, Rodrigo V. G. wrote:
> In addition to the bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
> I wanted to add some comment:
>
> It would be very useful if the _Atomic keyword would be supported in C++.
> This way the header could be included inconditionally in C++
In addition to the bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
I wanted to add some comment:
It would be very useful if the _Atomic keyword would be supported in C++.
This way the header could be included inconditionally in C++ code.
Even if it is not compatible with the C++ header,
On 05/12/2018 01:35 PM, Bernd Schmidt wrote:
> On 05/12/2018 07:01 PM, Jeff Law wrote:
>
>> No. We're not supposed to have any auto-inc insns prior to the auto-inc
>> pass. A stack push/pop early in the compiler would have to be
>> represented by a PARALLEL.
>>
>> It's been this way forever. It
On 11/05/18 17:49, Freddie Chopin wrote:
> On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote:
>> For the Cortex-M devices (and probably many other RISC targets),
>> -fdata-sections comes at a big cost - it effectively blocks
>> -fsection-anchors and makes access to file-static data a lot bigger.
