public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "Hale.Wang at arm dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking. Date: Wed, 28 May 2014 02:42:00 -0000 [thread overview] Message-ID: <bug-61123-4-DQN3ZFkA1i@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-61123-4@http.gcc.gnu.org/bugzilla/> [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5905 bytes --] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61123 --- Comment #2 from Hale Wang <Hale.Wang at arm dot com> --- (In reply to Richard Biener from comment #1) > All ABI changing options should be also enabled for LTO and they also deserve > handling in lto-opts.c (always stream, not only if explicitely set) and > lto-wrapper.c (diagnose mismatches and force a setting for the link stage). > > At least enabling them for LTO is minimally required, like you suggest. Hi Richard, I was dealing with the fno-short-enum bug that LTO ignore the options of fshort-enum and fshort-wchar(fshort-wchar is similar with fshort-enum). I tried to fix this bug by adding these options to LTO group. And this solution works. Right now, I am trying to add some test cases to report some error message for these cases in the previous gcc versions. And these cases will be passed after I add these options to LTO group. For the option of fshort-enum, I catch the Tag_ABI_enum_size from the final executable. And this test case can work very well now. But for the option of fshort-wchar, if I compile the source files without "-flto" option, I can catch the Tag_ABI_PCS_wchar_t from the final executable. If I add the "-flto" option to the compile command, the Tag_ABI_PCS_wchar_t is totally disappeared in the final executable. So I think this is another bug which means the final executable file (or the ABI) is different if we add "-flto" or not. I generated a minimal example.I have two source files: wchar_0.c: #include <stddef.h> wchar_t wc0[]=Lâabcâ; const wchar_t wc1[]=Lâabcâ; wchar_1.c: #include <stddef.h> wchar_t b0[]={ Lâabcâ }; const wchar_t b1[]={ Lâabcâ }; Firstly, I compile these files without â-fltoâ: $ arm-none-eabi-gcc -fshort-wchar wchar_0.c wchar_1.c -Wl,-Ur -o without_flto.o -nostdlib -Os $ arm-none-eabi-readelf -A without_flto.o Attribute Section: aeabi File Attributes Tag_CPU_name: "ARM7TDMI" Tag_CPU_arch: v4T Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 Tag_ABI_PCS_wchar_t: 2 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: small Tag_ABI_optimization_goals: Aggressive Size Then I compile these files with âflto: $ arm-none-eabi-gcc -fshort-wchar wchar_0.c wchar_1.c -Wl,-Ur -o with_flto.o -nostdlib -Os âflto $ arm-none-eabi-readelf -A with_flto.o Attribute Section: aeabi File Attributes Tag_CPU_name: "ARM7TDMI" Tag_CPU_arch: v4T Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: small Tag_ABI_optimization_goals: Aggressive Size So we can see the Tag_ABI_PCS_wchar_t attribute is totally disappeared. What do you think about this? >From gcc-bugs-return-452668-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 28 07:21:56 2014 Return-Path: <gcc-bugs-return-452668-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 20448 invoked by alias); 28 May 2014 07:21:55 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 20418 invoked by uid 48); 28 May 2014 07:21:51 -0000 From: "Joost.VandeVondele at mat dot ethz.ch" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/61335] New: [4.10 Regression] wrong code with -O2 -fbounds-check Date: Wed, 28 May 2014 07:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: <bug-61335-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-05/txt/msg02360.txt.bz2 Content-length: 885 https://gcc.gnu.org/bugzilla/show_bug.cgi?ida335 Bug ID: 61335 Summary: [4.10 Regression] wrong code with -O2 -fbounds-check Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Created attachment 32868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id2868&actioníit reduced testcase The attached testcase is miscompiled with current trunk. A recent regression caused in the day between good: r210955 and bad: r210994 To reproduce compile and run the attached testcase as : > gfortran -O2 -fbounds-check cp_units.f90 ; ./a.out BUG : XXXfs^-1XXX integer expected STOP 1 while e.g. '-O2' alone or '-fbound-check -O1' work fine.
next prev parent reply other threads:[~2014-05-28 2:42 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-05-09 6:10 [Bug c/61123] New: " Hale.Wang at arm dot com 2014-05-09 11:04 ` [Bug lto/61123] " rguenth at gcc dot gnu.org 2014-05-28 2:42 ` Hale.Wang at arm dot com [this message] 2014-05-30 4:45 ` Hale.Wang at arm dot com 2014-06-20 4:52 ` zqchen at gcc dot gnu.org 2014-06-20 6:12 ` Hale.Wang at arm dot com 2014-06-23 10:26 ` rguenth at gcc dot gnu.org 2014-07-29 7:11 ` xguo at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-61123-4-DQN3ZFkA1i@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).