From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127203 invoked by alias); 30 Jun 2015 02:37:33 -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 127075 invoked by uid 48); 30 Jun 2015 02:37:19 -0000 From: "olegendo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4 Date: Tue, 30 Jun 2015 02:37: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.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: olegendo at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-06/txt/msg03334.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833 --- Comment #17 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #15) > sh_reorg calls shorten_branches after the loop which includes > find_barrier call and get_attr_length will return correct value > after that. I see. If I understand correctly, the computed and cached values in final.c will not be used by anything else in this case and shorten_branches is always invoked afterwards. Now I understand the patch in c#12, thanks. > > Wouldn't it be easier/safer to just set the length of casesi_worker_1 to "8"? > > It may be safest from the computational viewpoint, though it'll > affect almost existing pic codes, I'm afraid. Perhaps it's OK > for trunk. The above patch won't affect existing code except > very limited cases, though it's a bit tricky. Increasing insn lengths unnecessarily might result in some unlucky constant pool placements and far branches and some code might get worse. On the other hand, constant pool placement and far branch code generation is "a matter of luck" anyway. Reading through the sh_reorg code, there are already some "CODE_FOR_casesi_worker_2" ifs and elses. Adding one more special case as in c#12 seems to fit in the picture nicely :) However, I think the comment in c#12 should be expanded a bit ... /* get_attr_length returns cached insn lengths which are computed once in shorten_branches. When here, fixup_mova might have replaced the insn pattern casesi_worker_1 with casesi_worker_2 and the cached insn length will be wrong. In this case, get the uncached length value directly from the insn attribute. */