--- Comment #41 from jakub at gcc dot gnu dot org 2008-05-18 18:31 ---
The bug is fixed there (though with the safer rs6000 specific fix), just the
testcase hasn't been committed. I'll do that later tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #42 from jakub at gcc dot gnu dot org 2008-05-18 20:19 ---
Subject: Bug 36090
Author: jakub
Date: Sun May 18 20:19:03 2008
New Revision: 135508
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135508
Log:
PR target/36090
*
--- Comment #43 from jakub at gcc dot gnu dot org 2008-05-18 20:20 ---
Subject: Bug 36090
Author: jakub
Date: Sun May 18 20:19:55 2008
New Revision: 135509
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135509
Log:
PR target/36090
*
--- Comment #44 from jakub at gcc dot gnu dot org 2008-05-18 20:24 ---
The bug I've reported is fixed both on the trunk and on the branch, although
with different patches.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #40 from rguenth at gcc dot gnu dot org 2008-05-16 19:44
---
What is the status of this bug on the 4.3 branch?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from bonzini at gnu dot org 2008-05-12 15:50 ---
so you prefer to leave my fix (possibly amended in 4.4+)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #36 from dje at gcc dot gnu dot org 2008-05-12 16:32 ---
Yes, I suggest keeping the simplify_plus_minus change with the CONST wrapper
removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #37 from bonzini at gnu dot org 2008-05-12 16:48 ---
Ok, I started a bootstrap of the obvious patch on i686-pc-linux-gnu. But I
think the obvious patch is not enough if we go this way. The comments in
simplify_plus_minus are already not up-to-date, and removing CONST is
--- Comment #38 from dje at gcc dot gnu dot org 2008-05-12 16:51 ---
I did update the comment when I applied the patch.
I will work on this more when I return from travel next week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #39 from bonzini at gnu dot org 2008-05-12 16:54 ---
Ah, only on 4.3 branch. Ok, I'll go on from here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #31 from jakub at gcc dot gnu dot org 2008-05-09 14:18 ---
Alternate patch to #c12 that doesn't touch at all rs6000_legitimate_address,
just changes print_operand_address:
--- gcc/config/rs6000/rs6000.c.jj 2008-04-24 18:30:39.0 +0200
+++
--- Comment #32 from jakub at gcc dot gnu dot org 2008-05-09 14:32 ---
Actually find_constant_pool_expr can be simplified, given that
constant_pool_expr_1 had to return 1 each time.
--- gcc/config/rs6000/rs6000.c.jj 2008-04-24 18:30:39.0 +0200
+++
--- Comment #33 from bonzini at gnu dot org 2008-05-09 15:51 ---
I now think that fixing it in the target is better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #34 from dje at gcc dot gnu dot org 2008-05-09 17:14 ---
Subject: Bug 36090
Author: dje
Date: Fri May 9 17:13:30 2008
New Revision: 135118
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135118
Log:
PR target/36090
* config/rs6000/rs6000.c
--- Comment #28 from dje at gcc dot gnu dot org 2008-05-08 16:36 ---
Subject: Bug 36090
Author: dje
Date: Thu May 8 16:35:56 2008
New Revision: 135086
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135086
Log:
2008-05-08 Paolo Bonzini [EMAIL PROTECTED]
PR target/36090
--- Comment #29 from dje at gcc dot gnu dot org 2008-05-08 16:41 ---
Subject: Bug 36090
Author: dje
Date: Thu May 8 16:40:17 2008
New Revision: 135087
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135087
Log:
2008-05-08 Paolo Bonzini [EMAIL PROTECTED]
PR target/36090
--- Comment #30 from cnstar9988 at gmail dot com 2008-05-09 05:36 ---
fixed?
--
cnstar9988 at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #26 from jakub at gcc dot gnu dot org 2008-05-04 19:47 ---
Created an attachment (id=15576)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15576action=view)
gcc44-pr36090.patch
Patch I've bootstrapped on 4.3 branch on {i386,x86_64,ppc,ppc64}-linux, no
regressions.
Note
--- Comment #27 from dje at gcc dot gnu dot org 2008-05-04 20:08 ---
I was planning to add asserts in print_operand_address ensuring that the
operand was the TOC SYMBOL_REF.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #21 from bonzini at gnu dot org 2008-05-03 07:13 ---
Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation
How do we proceed? Your initial patch is fine with me.
Whose? I can foster-parent yours too, and bootstrap/regtest it on
i686-pc-linux-gnu.
Paolo
--
--- Comment #22 from dje at gcc dot gnu dot org 2008-05-03 13:21 ---
Your patch from comment #17 (with typos fixed in comment #18).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #23 from bonzini at gnu dot org 2008-05-03 13:25 ---
Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation
dje at gcc dot gnu dot org wrote:
--- Comment #22 from dje at gcc dot gnu dot org 2008-05-03 13:21 ---
Your patch from comment #17 (with typos
--- Comment #24 from dje at gcc dot gnu dot org 2008-05-03 14:20 ---
I am testing with the patch. I wanted to make sure that there was agreement on
how to modify simplify_plus_minus before going too far. Also, I wanted to give
you the opportunity to take the lead on your patch. I can
--- Comment #25 from bonzini at gnu dot org 2008-05-03 15:47 ---
Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation
dje at gcc dot gnu dot org wrote:
--- Comment #24 from dje at gcc dot gnu dot org 2008-05-03 14:20 ---
I am testing with the patch. I wanted to
--- Comment #11 from jakub at gcc dot gnu dot org 2008-05-02 09:34 ---
The unexpected address is created by simplify_plus_minus on
(plus:DI (reg:DI 2 2)
(const:DI (minus:DI (symbol_ref/u:DI (*.LC1) [flags 0x2])
(symbol_ref:DI (*.LCTOC1)
and
(const_int 8 [0x8])
where
--- Comment #12 from jakub at gcc dot gnu dot org 2008-05-02 09:46 ---
Created an attachment (id=15561)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15561action=view)
gcc44-pr36090.patch
Untested patch that 1) tightens the checking in
legitimate_constant_pool_address_p -
--- Comment #13 from dje at gcc dot gnu dot org 2008-05-02 12:41 ---
fwprop cannot be modified to produce the preferred RTL with the symbol_refs on
the inside and the constant on the outside instead of teaching another part of
the compiler how to print this peculiar construct?
--
--- Comment #14 from dje at gcc dot gnu dot org 2008-05-02 15:10 ---
The problematic transformation in simplify_plus_minus() is:
/* We suppressed creation of trivial CONST expressions in the
combination loop to avoid recursion. Create one manually now.
The combination loop
--- Comment #15 from dje at gcc dot gnu dot org 2008-05-02 15:43 ---
This patch groups RTX_CONST_OBJ before CONST_INT.
Index: simplify-rtx.c
===
*** simplify-rtx.c (revision 134851)
--- simplify-rtx.c (working
--- Comment #16 from dje at gcc dot gnu dot org 2008-05-02 15:45 ---
Copying Bonzini for him to comment on the precedence and canonicalization
issue.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from bonzini at gnu dot org 2008-05-02 16:29 ---
I wonder if your patch would be a problem because it sometimes removes a CONST
wrapping. It could also be possible to precede the CONST_INT optimization with
another test for two adjacent CONSTANT_P:
if (GET_CODE
--- Comment #18 from dje at gcc dot gnu dot org 2008-05-02 17:36 ---
Yes, the patch works, modulo typos.
if (GET_CODE (ops[n_ops - 1].op) == CONST_INT)
i = n_ops - 2;
else
i = n_ops - 1;
if (i = 1
ops[i].neg
!ops[i - 1].neg
CONSTANT_P (ops[i].op)
--- Comment #19 from bonzini at gnu dot org 2008-05-02 21:08 ---
Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation
Yes, the patch works, modulo typos.
It was not tested indeed.
Does it make sense to group any two RTX_CONST_OBJ together of not the same
type?
I don't
--- Comment #20 from dje at gcc dot gnu dot org 2008-05-02 21:23 ---
How do we proceed? Your initial patch is fine with me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #6 from jakub at gcc dot gnu dot org 2008-05-01 07:13 ---
It certainly assembles with gas and after adding that 8+ the testcase works.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dje at gcc dot gnu dot org 2008-05-01 15:08 ---
The TOC path is used for both PPC64 Linux and AIX, so it needs to be acceptable
for both systems.
ld 11,8+LC..1(2)
is valid AIX assembler, so we can pursue that solution.
--
--- Comment #8 from dje at gcc dot gnu dot org 2008-05-01 15:46 ---
We can print the offset with something like the following patch:
Index: rs6000.c
===
*** rs6000.c(revision 134851)
--- rs6000.c(working copy)
--- Comment #9 from jakub at gcc dot gnu dot org 2008-05-01 17:15 ---
Yeah, this would fix this testcase. But I'd say constant_pool_expr_1 or
callers
need to be adjusted, so that they only accept what print_operand_address can
handle.
BTW, for:
long double foo (void)
{
return
--- Comment #10 from dje at gcc dot gnu dot org 2008-05-01 17:33 ---
In your second example, the RTL is in the canonical form that I would have
expected and already is handled:
(mem/u/c/i:DF (plus:DI (reg:DI 2 2)
(const:DI (plus:DI (minus:DI (symbol_ref/u:DI (*.LC0) [flags
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.3.1
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-30 20:25 ---
This wierdo addressing was created by fwprop2, which replaced:
In insn 40, replacing
(mem/u/c/i:DI (plus:DI (reg/f:DI 129)
(const_int 8 [0x8])) [2 S8 A64])
with (mem/u/c/i:DI (plus:DI (reg:DI 2 2)
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-30 20:38 ---
constant_pool_expr_p and therefore legitimate_constant_pool_address_p and
rs6000_legitimate_address too say this is ok, so fwprop2 isn't doing anything
wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #3 from dje at gcc dot gnu dot org 2008-04-30 21:17 ---
jakub Rhyolite: in PR36090, looks like print_operand_address completely
ignores the other operand of MINUS, probably assumes it has to be .LCTOC1
--
dje at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from dje at gcc dot gnu dot org 2008-05-01 02:32 ---
Is
ld 11,[EMAIL PROTECTED](2)
even valid assembly? Is that a valid relocation?
I suspect that constant_pool_expr_1() needs to be changed so that it does not
allow anything to be added to the toc_label_name.
--- Comment #5 from dje at gcc dot gnu dot org 2008-05-01 02:40 ---
Maybe something like the following patch (untested)?
Index: rs6000.c
===
*** rs6000.c(revision 132964)
--- rs6000.c(working copy)
***
45 matches
Mail list logo
