On May 15, 2018 10:12:45 PM GMT+02:00, Freddie Chopin
wrote:
>On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
>> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
>> > As to a workaround for the ld bug you can try keeping all .debug_*
>> > sections. IIRC 2.30 has the bug fixed (on
On Tue, May 15, 2018 at 12:56:22PM -0700, Julius Werner wrote:
> > I think you are asking for per-function constant pool sections. Because
> > we generally cannot avoid the need of a constant pool and dependent
> > on the target that is always global. Note with per-function constant
> > pools you
This has been listed as a desirable feature for a long time:
https://gcc.gnu.org/projects/optimize.html#putting_constants_in_special_sections
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> > As to a workaround for the ld bug you can try keeping all .debug_*
> > sections. IIRC 2.30 has the bug fixed (on the branch).
>
> Indeed - "keeping" all the debug sections is a
On Mon, 2018-05-14 at 16:34 +0200, David Brown wrote:
> Interesting. Making these sections and then using gc-sections should
> only remove code that is not used - LTO should do that anyway.
My guess - expressed in the other e-mail to the list - is that the
things LTO cannot remove but --gc-sectio
> I think you are asking for per-function constant pool sections. Because
> we generally cannot avoid the need of a constant pool and dependent
> on the target that is always global. Note with per-function constant
> pools you will not benefit from constant pool entry merging across
> functions.
On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> That's an interesting result. Do you have any non-LTO objects?
> Basically I'm curious what ld eliminates that gcc with LTO doesn't.
Whole project is compiled with LTO, part of the project is provided as
a library (which is archived with
> On Feb 9, 2018, at 3:47 PM, Steve Ellcey wrote:
>
> […]
> I was wondering if the function vector ABI has been published yet and
> if so, where I could find it.
>
Hi Steve,
I am happy to let you know that the Vector Function ABI for AArch64 is now
public and available via the link at [1].
On Mon, May 14, 2018 at 04:38:09PM -0700, Julius Werner wrote:
> However, I just found an issue with this when the functions include local
> variables like this:
>
> const int some_array[] = { 1, 2, 3, 4, 5, 6 };
Does it work better if you make this "static const"?
Segher
That makes me wonder if there is a latent bug though. Consider pushing
args to a pure function. Could we then try to CSE the memory reference
and get it wrong because we haven't accounted for the autoinc?
>>>
>>> Can't know for sure but one would hope something would test for
>>> s
Make `i' defined within `i387_collect_xsave' unsigned, removing a
`-Werror=strict-overflow' compilation error:
.../gdb/i387-tdep.c: In function 'void i387_collect_xsave(const regcache*, int,
void*, int)':
.../gdb/i387-tdep.c:1348:1: error: assuming signed overflow does not occur when
assuming t
On 05/15/2018 12:58 PM, A. Skrobov wrote:
>>> That makes me wonder if there is a latent bug though. Consider pushing
>>> args to a pure function. Could we then try to CSE the memory reference
>>> and get it wrong because we haven't accounted for the autoinc?
>>
>> Can't know for sure but one woul
>> That makes me wonder if there is a latent bug though. Consider pushing
>> args to a pure function. Could we then try to CSE the memory reference
>> and get it wrong because we haven't accounted for the autoinc?
>
> Can't know for sure but one would hope something would test for
> side_effects_
On 15 May 2018 at 11:01, Rodrigo V. G. wrote:
> On Tue, May 15, 2018 at 12:27 AM, Jonathan Wakely
> wrote:
>> 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 ve
On 05/15/2018 11:01 AM, Rodrigo V. G. wrote:
> I tried to use __atomic_fetch_add in C++ with a volatile (non _Atomic)
> variable,
> and it seems to generate the same assembler code.
> The only difference that I saw was that with _Atomic
> it generates a "mfence" instruction after initialization bu
On Tue, May 15, 2018 at 12:27 AM, Jonathan Wakely wrote:
> 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++
On Tue, May 15, 2018 at 1:38 AM Julius Werner wrote:
> 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 curre
17 matches
Mail list logo
