Re: Using CMake for building GCC
> On Sun, Sep 11, 2022, 10:30 Junk Trash via Gcc wrote: > >> Hi, >> >> I want to get the opinions of GCC developers regarding adding CMake as a >> build system for GCC. Is it something you would like, something you are >> neutral about, or something you are strongly against? >> >> Thanks for your valuable feedback! >> >> Regards, >> >> JT >> > > The high level premise of autotools is to make life harder for the build > system maintainer of a project and easier for a user. This makes sense on > several levels, including portability and familiarity. Cmake, on the other > hand, makes life somewhat easier for the build system maintainer (I > suppose) and harder for the user. This works for a pet project or something > without wide distribution, but I don't personally find it to be a good > design principle for usable and portable software. > > Autotools isn't perfect (configure steps are slow, for instance), but it's > robust, reliable, portable, and trivial for an end user. Very well said. Distributed source tarballs are a blessing for both distros and users. Often people suggesting replacing autotools with CMake do so under the assumption these two programs do the same thing: they don't. I would very strongly oppose using CMake for building any program I contribute to, and I would certainly never use it in any program I maintain myself.
Question unused function parameter data garbage collection
Hi,
We have a function that does not used an in-parameter, simplified example:
void test_unused_string_param_gc(const char* unused)
{
// empty
}
Though when we have calls to this function, the arguments are still put in the
memory, causing unnecessary flash memory usage for 'dead parameters'.
Example if having a call (from another file) as
test_unused_string_param_gc("This string is not garbage-collected?");
Then this string will still be added to our finally build binary?
We compile with -Os, and have tried different flags to try get rid of this dead
parameter data,
do anyone know if this is the expected behavior and why? Or if we are missing
any optimization flags, like LTO etc?
Best Regards,
Fredrik
Re: Question unused function parameter data garbage collection
On Mon, Sep 12, 2022 at 1:23 PM Fredrik Hederstierna via Gcc
wrote:
>
> Hi,
>
> We have a function that does not used an in-parameter, simplified example:
>
> void test_unused_string_param_gc(const char* unused)
> {
>// empty
> }
>
> Though when we have calls to this function, the arguments are still put in
> the memory, causing unnecessary flash memory usage for 'dead parameters'.
>
> Example if having a call (from another file) as
>
> test_unused_string_param_gc("This string is not garbage-collected?");
>
> Then this string will still be added to our finally build binary?
>
> We compile with -Os, and have tried different flags to try get rid of this
> dead parameter data,
> do anyone know if this is the expected behavior and why? Or if we are missing
> any optimization flags, like LTO etc?
Without LTO there is no way the unused parameter can be elided on the
caller side so yes, try enabling LTO.
Richard.
> Best Regards,
> Fredrik
>
Re: Question unused function parameter data garbage collection
Hi,
On Mon, Sep 12 2022, Richard Biener via Gcc wrote:
> On Mon, Sep 12, 2022 at 1:23 PM Fredrik Hederstierna via Gcc
> wrote:
>>
>> Hi,
>>
>> We have a function that does not used an in-parameter, simplified example:
>>
>> void test_unused_string_param_gc(const char* unused)
>> {
>>// empty
>> }
>>
>> Though when we have calls to this function, the arguments are still put in
>> the memory, causing unnecessary flash memory usage for 'dead parameters'.
>>
>> Example if having a call (from another file) as
>>
>> test_unused_string_param_gc("This string is not garbage-collected?");
>>
>> Then this string will still be added to our finally build binary?
>>
>> We compile with -Os, and have tried different flags to try get rid of this
>> dead parameter data,
>> do anyone know if this is the expected behavior and why? Or if we are
>> missing any optimization flags, like LTO etc?
>
> Without LTO there is no way the unused parameter can be elided on the
> caller side so yes, try enabling LTO.
>
or, if possible, make the function static.
Martin
Re: Using CMake for building GCC
In my opinion, the advantage of autotools is that it can generate a configure script that can be shipped with the source tarball, then any one with the source can run the configure script when the system has a POSIX shell and tools. If using CMake, meson, xmake, etc. the user will first need to install the build tool to build the source. I still hope to have one such build tool which can generate a configure script, and have some better properties than autotools: - implemented in a sane language (I don't like Perl) - generate a single configure script for the whole project instead of running configure on subprojects when running make - support building with ninja If CMake, meson, xmake or some other build system support generating a POSIX shell configure script, I think it would be fine to use it to replace autotools. On 2022/9/11 22:29, Junk Trash via Gcc wrote: Hi, I want to get the opinions of GCC developers regarding adding CMake as a build system for GCC. Is it something you would like, something you are neutral about, or something you are strongly against? Thanks for your valuable feedback! Regards, JT
