* Jakub Jelinek:
> Or if we recorded all command line options we care about into LTO bytecode
> (Optimization/Target options are recorded already on a per-function basis
> but I'm worried about others), just have a gcc driver mode that turns
> a non-fat LTO object into normal non-LTO object.
I th
Jakub Jelinek wrote:
> Or if we recorded all command line options we care about into LTO bytecode
> (Optimization/Target options are recorded already on a per-function basis
> but I'm worried about others), just have a gcc driver mode that turns
> a non-fat LTO object into normal non-LTO object.
T
On Mon, Nov 15, 2021 at 12:13:19PM -0700, Jeff Law wrote:
> > with somehting that errors out (fails the build) if any relocatable
> > object files (.o) or static archives (.a) by default, and stop producing
> > object code by default, only LTO representation. If a special
> > redhat-rpm-config fla
On 11/15/2021 6:06 AM, Florian Weimer wrote:
In the future, we might want to switch GCC not to generate both object
code and LTO representation during the build process. For most
packages, dual generation is not necessary because no relocatable object
files for static linking are included in t
* Tom Stellard:
> On 11/15/21 05:06, Florian Weimer wrote:
>> In the future, we might want to switch GCC not to generate both object
>> code and LTO representation during the build process. For most
>> packages, dual generation is not necessary because no relocatable object
>> files for static li
On 11/15/21 05:06, Florian Weimer wrote:
In the future, we might want to switch GCC not to generate both object
code and LTO representation during the build process. For most
packages, dual generation is not necessary because no relocatable object
files for static linking are included in the RPM
In the future, we might want to switch GCC not to generate both object
code and LTO representation during the build process. For most
packages, dual generation is not necessary because no relocatable object
files for static linking are included in the RPM (neither as separate
ET_REL .o files, nor
