From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27426 invoked by alias); 21 Nov 2013 23:57:24 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 27350 invoked by uid 48); 21 Nov 2013 23:57:20 -0000 From: "vincent-gcc at vinc17 dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/19430] taking address of a var causes missing uninitialized warning Date: Thu, 21 Nov 2013 23:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 3.4.2 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: vincent-gcc at vinc17 dot net X-Bugzilla-Status: NEW 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: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-11/txt/msg02238.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D19430 --- Comment #26 from Vincent Lef=C3=A8vre -= -- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #25) > I don't see any reason for -Wuninitialized to not enable > -Wmaybe-uninitialized. I can see 3 kinds of use: 1. Users who are interested in neither: they just don't use these options (= if they want to use -Wall, they need the -Wno- version). 2. Users interested in -Wuninitialized but not in -Wmaybe-uninitialized (to avoid potential many false positives). Because -Wuninitialized enables -Wmaybe-uninitialized, they need 2 options: -Wuninitialized -Wno-maybe-uninitialized. If -Wuninitialized did not enable -Wmaybe-uninitialized, only one option would be needed: -Wuninitialized. 3. Users interested in both. I think that -Wmaybe-uninitialized should enab= le -Wuninitialized because it makes no sense to have -Wmaybe-uninitialized but= not -Wuninitialized. Indeed, if some variable is uninitialized, then it may be uninitialized. So, only one option should be needed in this case: -Wmaybe-uninitialized. >>From gcc-bugs-return-435462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 22 00:00:16 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 29705 invoked by alias); 22 Nov 2013 00:00:16 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 29646 invoked by uid 48); 22 Nov 2013 00:00:12 -0000 From: "olegendo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/58314] SH4 error: 'asm' operand requires impossible reload Date: Fri, 22 Nov 2013 00:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: olegendo at gcc dot gnu.org X-Bugzilla-Status: REOPENED 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: cc Message-ID: In-Reply-To: References: 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: 2013-11/txt/msg02239.txt.bz2 Content-length: 4801 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314 Oleg Endo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkojima at gcc dot gnu.org --- Comment #9 from Oleg Endo --- (In reply to chrbr from comment #5) > Oleg, I think it time to re-unify those. Doing an experimental resurrection > of the r,r reload constraints seems to fix it, but without knowing the > impacts on your T-bit combine optimizations... OK, I've tried your suggestion by doing ... Index: gcc/config/sh/sh.md =================================================================== --- gcc/config/sh/sh.md (revision 205190) +++ gcc/config/sh/sh.md (working copy) @@ -6993,34 +6993,6 @@ prepare_move_operands (operands, QImode); }) -;; If movqi_reg_reg is specified as an alternative of movqi, movqi will be -;; selected to copy QImode regs. If one of them happens to be allocated -;; on the stack, reload will stick to movqi insn and generate wrong -;; displacement addressing because of the generic m alternatives. -;; With the movqi_reg_reg being specified before movqi it will be initially -;; picked to load/store regs. If the regs regs are on the stack reload -;; try other insns and not stick to movqi_reg_reg, unless there were spilled -;; pseudos in which case 'm' constraints pertain. -;; The same applies to the movhi variants. -;; -;; Notice, that T bit is not allowed as a mov src operand here. This is to -;; avoid things like (set (reg:QI) (subreg:QI (reg:SI T_REG) 0)), which -;; introduces zero extensions after T bit stores and redundant reg copies. -;; -;; FIXME: We can't use 'arith_reg_operand' (which disallows T_REG) as a -;; predicate for the mov src operand because reload will have trouble -;; reloading MAC subregs otherwise. For that probably special patterns -;; would be required. -(define_insn "*mov_reg_reg" - [(set (match_operand:QIHI 0 "arith_reg_dest" "=r,m,*z") - (match_operand:QIHI 1 "register_operand" "r,*z,m"))] - "TARGET_SH1 && !t_reg_operand (operands[1], VOIDmode)" - "@ - mov %1,%0 - mov. %1,%0 - mov. %1,%0" - [(set_attr "type" "move,store,load")]) - ;; FIXME: The non-SH2A and SH2A variants should be combined by adding ;; "enabled" attribute as it is done in other targets. (define_insn "*mov_store_mem_disp04" @@ -7075,33 +7047,35 @@ ;; displacement addressing modes on anything but SH2A. That's why the ;; specialized load/store insns are specified above. (define_insn "*movqi" - [(set (match_operand:QI 0 "general_movdst_operand" "=r,r,m,r,l") - (match_operand:QI 1 "general_movsrc_operand" "i,m,r,l,r"))] + [(set (match_operand:QI 0 "general_movdst_operand" "=r,r,r,m,r,l") + (match_operand:QI 1 "general_movsrc_operand" "r,i,m,r,l,r"))] "TARGET_SH1 && (arith_reg_operand (operands[0], QImode) || arith_reg_operand (operands[1], QImode))" "@ mov %1,%0 + mov %1,%0 mov.b %1,%0 mov.b %1,%0 sts %1,%0 lds %1,%0" - [(set_attr "type" "movi8,load,store,prget,prset")]) + [(set_attr "type" "move,movi8,load,store,prget,prset")]) (define_insn "*movhi" - [(set (match_operand:HI 0 "general_movdst_operand" "=r,r,r,m,r,l") - (match_operand:HI 1 "general_movsrc_operand" "Q,i,m,r,l,r"))] + [(set (match_operand:HI 0 "general_movdst_operand" "=r,r,r,r,m,r,l") + (match_operand:HI 1 "general_movsrc_operand" "r,Q,i,m,r,l,r"))] "TARGET_SH1 && (arith_reg_operand (operands[0], HImode) || arith_reg_operand (operands[1], HImode))" "@ + mov %1,%0 mov.w %1,%0 mov %1,%0 mov.w %1,%0 mov.w %1,%0 sts %1,%0 lds %1,%0" - [(set_attr "type" "pcload,movi8,load,store,prget,prset")]) + [(set_attr "type" "move,pcload,movi8,load,store,prget,prset")]) (define_insn "*movqi_media" [(set (match_operand:QI 0 "general_movdst_operand" "=r,r,r,m") ... and it fixes the problem. The CSiBE set doesn't show any size differences for SH4, which is a good sign. make -k check-gcc RUNTESTFLAGS="sh.exp --target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}" also doesn't report new failures. However, I'm still anxious regarding the comment that reload will generate wrong displacement addresses because of the generic 'm' alternatives in the *movqi and *movhi insns. Maybe the additional reg_reg pattern was a wallpaper fix after all and is not required anymore. I'm testing the above patch now. Kaz, could you please run the above patch through your test setup? I remember there were some issues triggered by some fortran code in the test suite...