>> Your patch dealt with board/multilib_flags, but the same problem exists
>> for board/cflags and many other flag-containing options.
>
> What's the use case for that? IIUC board flags are supposed to be ones
> that are absolutely required for executables to run with a given board,
> such as
On Wed, 2 Sep 2020, Jose E. Marchesi via Gcc-patches wrote:
> Your patch dealt with board/multilib_flags, but the same problem exists
> for board/cflags and many other flag-containing options.
What's the use case for that? IIUC board flags are supposed to be ones
that are absolutely required f
> On Wed, Sep 2, 2020 at 8:31 AM Jose E. Marchesi via Gcc-patches
> wrote:
>>
>>
>> Hi people!
>>
>> While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
>> board/cflags were included in the final compilation line _after_ the
>> flags in the test's dg-options.
>>
>> Since the test
On Wed, Sep 2, 2020 at 8:31 AM Jose E. Marchesi via Gcc-patches
wrote:
>
>
> Hi people!
>
> While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
> board/cflags were included in the final compilation line _after_ the
> flags in the test's dg-options.
>
> Since the test options are mor
Hi people!
While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
board/cflags were included in the final compilation line _after_ the
flags in the test's dg-options.
Since the test options are more particular than the board options, I
would expect them to be placed after any board-
