gcc: explicitly use CFLAGS_FOR_TARGET instead of --enable-target-optspace

Due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2222 it's impossible
to specify custom CFLAGS_FOR_TARGET, it is alway gets overriden with values
from "config/mt-ospace":

Hi Thomas, Peter,

On Mon, 2014-07-14 at 19:29 +0400, Alexey Brodkin wrote:
> Due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2222 it's impossible
> to specify custom CFLAGS_FOR_TARGET, it is alway gets overriden with values
> from "config/mt-ospace":
> ===========
>  CFLAGS_FOR_TARGET = -g -Os
>  CXXFLAGS_FOR_TARGET = -g -Os
> ===========
> 
> But in some situations it's required to pass custom flags on buildong of libgcc:
>  * Default flags "-g -Os" lead to build isses as with PowerPC on gcc 4.5
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810)
>  * Particular CPU requires specific instructions for HW support
>  * Deep optimizations

Any chance for this one to be commented/applied?

Regards,
Alexey

Dear Alexey Brodkin,

On Mon, 14 Jul 2014 19:29:46 +0400, Alexey Brodkin wrote:
> Due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2222 it's impossible
> to specify custom CFLAGS_FOR_TARGET, it is alway gets overriden with values
> from "config/mt-ospace":
> ===========
>  CFLAGS_FOR_TARGET = -g -Os
>  CXXFLAGS_FOR_TARGET = -g -Os
> ===========
> 
> But in some situations it's required to pass custom flags on buildong of libgcc:
>  * Default flags "-g -Os" lead to build isses as with PowerPC on gcc 4.5
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810)
>  * Particular CPU requires specific instructions for HW support
>  * Deep optimizations
> 
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>

I found the commit log quite difficult to understand actually. It
lacked a bit of context like:

"""
The gcc.mk file is passing --enable-target-optspace to gcc configure
script, to ask for space-optimized (-Os) target libraries. However,
passing this option has the effect of overriding any custom
CFLAGS_FOR_TARGET or CXXFLAGS_FOR_TARGET values that may be passed.
"""

And then go on with your explanation. Also, apparently, using "======="
in the middle of a commit log confuses patchwork a bit:
http://patchwork.ozlabs.org/patch/369672/.

> diff --git a/package/gcc/gcc-intermediate/gcc-intermediate.mk b/package/gcc/gcc-intermediate/gcc-intermediate.mk
> index db84d18..0543574 100644
> --- a/package/gcc/gcc-intermediate/gcc-intermediate.mk
> +++ b/package/gcc/gcc-intermediate/gcc-intermediate.mk
> @@ -46,4 +46,17 @@ ifeq ($(BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE),y)
>  HOST_GCC_INTERMEDIATE_INSTALL_OPT += install-target-libgcc
>  endif
>  
> +ifeq ($(ARCH),powerpc)
> +ifeq ($(findstring x4.5.,x$(GCC_VERSION)),x4.5.)
> +	# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810
> +	# Workaround until it's fixed in 4.5.4 or later
> +	HOST_GCC_INTERMEDIATE_CONF_ENV += CFLAGS_FOR_TARGET="-g -O2"
> +	HOST_GCC_INTERMEDIATE_CONF_ENV += CXXFLAGS_FOR_TARGET="-g -O2"
> +endif
> +else
> +	# Defaults are "-g -Os" from "config/mt-ospace"
> +	HOST_GCC_INTERMEDIATE_CONF_ENV += CFLAGS_FOR_TARGET="-g -Os"
> +	HOST_GCC_INTERMEDIATE_CONF_ENV += CXXFLAGS_FOR_TARGET="-g -Os"
> +endif

The original --enable-target-optspace is passed at *all* gcc steps, but
now you're passing CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET only at
the gcc intermediate step. This looks weird.

Also, since we can actually customize this option, what about using the
ones from Buildroot, i.e something such as:

	HOST_GCC_CONF_ENV += CFLAGS_FOR_TARGET="$(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)"
	HOST_GCC_CONF_ENV += CXXFLAGS_FOR_TARGET="$(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)"

Maybe we could even just use $(TARGET_CFLAGS) and $(TARGET_CXXFLAGS),
though I'm a bit less sure about all the possible consequences.

Thanks,

Thomas

Hi Thomas,

On Mon, 2014-07-28 at 23:12 +0200, Thomas Petazzoni wrote:
> I found the commit log quite difficult to understand actually. It
> lacked a bit of context like:
> 
> """
> The gcc.mk file is passing --enable-target-optspace to gcc configure
> script, to ask for space-optimized (-Os) target libraries. However,
> passing this option has the effect of overriding any custom
> CFLAGS_FOR_TARGET or CXXFLAGS_FOR_TARGET values that may be passed.
> """
> 
> And then go on with your explanation. Also, apparently, using "======="
> in the middle of a commit log confuses patchwork a bit:
> http://patchwork.ozlabs.org/patch/369672/.

Thanks for this comment. Makes perfect sense.

> The original --enable-target-optspace is passed at *all* gcc steps, but
> now you're passing CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET only at
> the gcc intermediate step. This looks weird.

Well I was under impression that target binaries are only built on
"gcc-intermediate" stage, that's why I moved changes there exclusively.

I noticed that "libgcc" (in all its incarnations: libgcc_s.so, libgcc.a,
libgcc_eh.a etc) was built on "intermediate" stage and considered that
there's no sense to build it once again on "final" stage.

I checked now and do see that on "gcc-final" stage libgcc and friends
was built as well. I'm wondering why?

Anyway it looks like we need to pass "custom" flags at least on
"gcc-intermediate" and "gcc-final" stages and in this case it makes
sense to leave everything in "gcc.mk" (even though "gcc-initial" doesn't
build anything for target).

> Also, since we can actually customize this option, what about using the
> ones from Buildroot, i.e something such as:
> 
> 	HOST_GCC_CONF_ENV += CFLAGS_FOR_TARGET="$(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)"
> 	HOST_GCC_CONF_ENV += CXXFLAGS_FOR_TARGET="$(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)"

My intention was to keep output results as they are now but add an
ability to modify flags if it is actually required. That way I might be
sure this change doesn't brake things for people. "libgcc" is a thing
that everybody builds and than uses on their target so if I break it
people will go for me.

Your proposal looks very sane for me and if you believe we may try this
move I'll happily implement it.

Actually I was pretty surprised myself when I found that
BR2_TARGET_OPTIMIZATION has no impact on libgcc built for target. And
maybe it's time to fix it.

> Maybe we could even just use $(TARGET_CFLAGS) and $(TARGET_CXXFLAGS),
> though I'm a bit less sure about all the possible consequences.

As for me I'd vote for TARGET_CFLAGS/CXXFLAGS because then we have
exactly the same options for all target binaries.

Would be good to get some more feedback to make a good choice.

Regards,
Alexey