From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76782 invoked by alias); 7 Jan 2019 21:16:56 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 76771 invoked by uid 89); 7 Jan 2019 21:16:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=complement, HX-HELO:sk:mail-oi, H*c:alternative X-HELO: mail-oi1-f173.google.com Received: from mail-oi1-f173.google.com (HELO mail-oi1-f173.google.com) (209.85.167.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Jan 2019 21:16:53 +0000 Received: by mail-oi1-f173.google.com with SMTP id a77so1566613oii.5 for ; Mon, 07 Jan 2019 13:16:53 -0800 (PST) MIME-Version: 1.0 References: <20190107172251.GL14180@gate.crashing.org> In-Reply-To: From: Felipe Gohring Date: Mon, 07 Jan 2019 21:16:00 -0000 Message-ID: Subject: Re: GCC update increased the file size by 4x on PowerPC port To: Segher Boessenkool Cc: gcc-help@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-01/txt/msg00026.txt.bz2 A complement to this. I was able to successfully execute my tests with 8.2 What it took was to remove all debug flags. Which lead me to another question: how can GCC 8.2 generate SO MUCH extra information, when compared to 6.3? The size difference I was having (stated on the original message) is regarding the stuff created to debug. When loading this amount of information into QeMU (I am loading each portion of my code on specific memory regions) I was having a memory overlap, as debugging info was not being take into account. On Mon, Jan 7, 2019 at 1:59 PM Felipe Gohring wrote: > Thanks for the replies. > > > On Mon, Jan 7, 2019 at 12:23 PM Segher Boessenkool < > segher@kernel.crashing.org> wrote: > >> Hi, >> >> On Mon, Jan 07, 2019 at 11:14:12AM -0500, Felipe Gohring wrote: >> > Now, my question is related to the generated code. When using V6.3, I >> had >> > files of about 10k. After upgrading to V8.2, the very same file has more >> > than 40k. Why is that? Please keep in mind that I am using exactly the >> same >> > compilation flags (*-m32 -mmfpgpr -mabi=spe -mfloat-gprs=double >> -nostdlib >> > -ffreestanding -fno-builtin -O0 -g3 -std=c11 -Wno-packed-bitfield-compat >> > -Wall -Werror*) and source code, the only thing changing is the compiler >> > version. I wouldn't mind having a memory footprint a bit bigger, but the >> > overhead added is beyond acceptable. >> >> If you care about code size, you want -O1 or -Os, not -O0. >> >> I don't, I was just surprised! But indeed, the difference was mostly due > to -g3 flag. Without debug flags the size is almos (>5%) the same. > > >> And why are you using -mmfpgpr? That option doesn't do anything for >> anything >> targetting SPE, but for some reason many people use it? >> >> I assumed it was needed, in order for SPE to use the general purpose > registers properly. removed them. > > >> > Further, besides the crazy sizes, some applications are breaking when >> using >> > the updated compiler version, even though I am not having any warning >> > neither error (*-Wall -Werror)*. How come, as the ABI should not be >> broken >> > even with a different compiler version? >> >> Use -Wall -Wextra instead... But your code may be doing many more things >> wrong than those warnings can detect. You could try -fno-strict-aliasing >> for example. >> >> Using -Wall -Wextra a few new warnings were found and I have corrected > them already. Still, even with -fno-strict-aliasing applications do not > work with the new compiler version > >> >> Segher >> > > > -- > Felipe GM > -- Felipe GM