On 4/25/2022 9:26 AM, Nick Clifton wrote:
Hi Jeff,
Just FYI - I am also looking at adding in another warning. This
time for
when the linker creates a PT_LOAD segment which has all of the RWX
flags
set. At the moment my testing seems to show that it only causes
problems
when a cus
Hi Jeff,
Just FYI - I am also looking at adding in another warning. This time for
when the linker creates a PT_LOAD segment which has all of the RWX flags
set. At the moment my testing seems to show that it only causes problems
when a custom linker script is used that defines its own pr
On 4/25/2022 8:42 AM, Nick Clifton wrote:
Hi Jeff,
I used -z execstack rather than --no-warn-execstack as the former
is recognized by older versions of ld, but the latter is a new option.
Thanks for it.
Unfortunately, I should have looked at the other failures that have
popped up over the
Hi Jeff,
I used -z execstack rather than --no-warn-execstack as the former is recognized
by older versions of ld, but the latter is a new option.
Thanks for it.
Unfortunately, I should have looked at the other failures that have popped up over the last week. Essentially all the nested functio
On 4/25/2022 6:56 AM, Martin Liška wrote:
I used -z execstack rather than --no-warn-execstack as the former is recognized
by older versions of ld, but the latter is a new option.
Thanks for it.
Unfortunately, I should have looked at the other failures that have
popped up over the last wee
On 4/24/22 19:42, Jeff Law via Gcc wrote:
> About a week ago many targets started failing pr94157_0.c test like this
> (bfin-elf, but many other targets are also affected):
>
>> spawn -ignore SIGHUP /home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/xgcc
>> -B/home/jlaw/test/obj/bfin-elf/obj/gcc/gcc/ c_lt
On Mon, Apr 25, 2022 at 11:42:14 +0200, Boris Kolpackov wrote:
> 1. Firstly, this only applies to header units, not named modules.
Correct.
> 2. I am not sure what you mean by "active build executor" (but it
>does sound ominous, I will grant you that ;-)).
One that does more than schedule bu
Ben Boeckel writes:
> If we need to know and have dependencies prepared before we can figure
> out the dependencies for a TU, modules are unsolvable (without an active
> build executor). If C++ implementations are really going to require
> that, then [...] the following tools are all unsuitable f
Iain Sandoe writes:
> The standard has the concept of an “importable header” which is
> implementation-defined.
But it must contain all the C++ library headers:
https://eel.is/c++draft/headers#4
> We could choose that only headers that are self-contained (i.e. unaffected
> by external defines
