[Bug rtl-optimization/36182] New: [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[Bug rtl-optimization/36182] New: [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

With 135074 no regressions.
With 135087, I see the following regressions:
FAIL: ext/malloc_allocator/deallocate_local.cc (test for excess errors)
WARNING: ext/malloc_allocator/deallocate_local.cc compilation failed to produce
executable
FAIL: ext/mt_allocator/deallocate_local-2.cc (test for excess errors)
WARNING: ext/mt_allocator/deallocate_local-2.cc compilation failed to produce
executable
FAIL: ext/mt_allocator/deallocate_local-4.cc (test for excess errors)
WARNING: ext/mt_allocator/deallocate_local-4.cc compilation failed to produce
executable
FAIL: ext/mt_allocator/deallocate_local-6.cc (test for excess errors)
WARNING: ext/mt_allocator/deallocate_local-6.cc compilation failed to produce
executable
FAIL: ext/mt_allocator/deallocate_local-8.cc (test for excess errors)
WARNING: ext/mt_allocator/deallocate_local-8.cc compilation failed to produce
executable
FAIL: ext/new_allocator/deallocate_local.cc (test for excess errors)
WARNING: ext/new_allocator/deallocate_local.cc compilation failed to produce
executable
FAIL: ext/throw_allocator/deallocate_local.cc (test for excess errors)
WARNING: ext/throw_allocator/deallocate_local.cc compilation failed to produce
executable

with the .log file saying similar for all errors:
/tmp/ccDpHWIJ.s: Assembler messages:^M
/tmp/ccDpHWIJ.s:788: Error: can't resolve `.LC2' {.rodata.str1.2 section} -
`__ZNSbIcSt11char_traitsIcEN9__gnu_cxx16malloc_allocatorIcEEE4_Rep20_S_empty_rep_storageE'
{.bss._ZNSbIcSt11char_traitsIcEN9__gnu_cxx16malloc_allocatorIcEEE4_Rep20_S_empty_rep_storageE
section}^M
/tmp/ccDpHWIJ.s:788: Error: expression too complex^M
compiler exited with status 1
output is:
/tmp/ccDpHWIJ.s: Assembler messages:^M
/tmp/ccDpHWIJ.s:788: Error: can't resolve `.LC2' {.rodata.str1.2 section} -
`__ZNSbIcSt11char_traitsIcEN9__gnu_cxx16malloc_allocatorIcEEE4_Rep20_S_empty_rep_storageE'
{.bss._ZNSbIcSt11char_traitsIcEN9__gnu_cxx16malloc_allocatorIcEEE4_Rep20_S_empty_rep_storageE
section}^M
/tmp/ccDpHWIJ.s:788: Error: expression too complex^M

FAIL: ext/malloc_allocator/deallocate_local.cc (test for excess errors)

There's only the PR36090 simplify_plus_minus change between these two revisions
on the 4.3 branch.  So, the CONST change now causes a wrap of a MINUS between
two symbols to _different_ sections, which must not happen.  Curiously, the
same change on HEAD doesn't exhibit these regressions.  Author of patch CC:ed.


-- 
           Summary: [4.3 Regression] Fix for PR 36090 causes libstdc++
                    regressions
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-08 22:47 -------
I have a similar issue on spu-elf where we get s-t+3@l which is too complex for
the linker to handle.

/tmp/ccbhdI9l.s:19: Error: reloc 132 not supported by object file format^M
/tmp/ccbhdI9l.s:22: Error: reloc 131 not supported by object file format^M

        ilhu    $3,s-t+3@h
        iohl    $3,s-t+3@l

This is with compiling pr34029-2.c


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.3.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

------- Comment #3 from bonzini at gnu dot org  2008-05-09 05:05 -------
i'll post a temptative patch for the cris issue if i get to it during the
commute.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

------- Comment #2 from bonzini at gnu dot org  2008-05-09 05:04 -------
unfortunately my current gcc time is ~0, which is why dje actually tested and
committed the patch for me, but sorry for causing these regressions anyway.

for cris, i believe the correct fix is to strengthen the check and only wrap
symbol_refs if they are from the same section.  (this is a problem in my patch,
which is why i'm confirming the bug).

for spu, this is a target bug where legitimate_address is not rejecting an
invalid address.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-05-09 05:04:25
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

------- Comment #4 from bonzini at gnu dot org  2008-05-09 05:05 -------
ahem, tentative


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker
           Keywords|                            |wrong-code
      Known to fail|                            |4.3.1
      Known to work|                            |4.3.0
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

------- Comment #5 from bonzini at gnu dot org  2008-05-09 13:36 -------
Created an attachment (id=15620)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15620&action=view)
patch for cris problem

This patch should fix the CRIS problem.  However, we should also check that it
does not make PR36090 resurface -- obviously.  David, can you look at that?

It does not attempt to fix the SPU problem, which should be fixed in the
target.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

------- Comment #6 from bonzini at gnu dot org  2008-05-09 13:37 -------
Richard (Sandiford), could you look at the patch?  You are the varasm.c expert.
:-)


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

------- Comment #7 from bonzini at gnu dot org  2008-05-09 13:37 -------
not wrong-code, it fails to assemble.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |rejects-valid


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[dje at gcc dot gnu dot org]

------- Comment #8 from dje at gcc dot gnu dot org  2008-05-09 14:36 -------
The TOC anchor SYMBOL_REF does not have an associated DECL, so the new patch
crashes with a segfault.  I'm not sure if there is a safe section to assume for
SYMBOL_REFs without DECLs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[bonzini at gnu dot org]

------- Comment #9 from bonzini at gnu dot org  2008-05-09 16:03 -------
I'll revert my patch on Monday even if no alternative solution for PR36090 is
found during the weekend.  It opened too big cans of worms for a release
branch, even though it fixed a serious regression.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[dje at gcc dot gnu dot org]

------- Comment #10 from dje at gcc dot gnu dot org  2008-05-09 17:14 -------
Subject: Bug 36182

Author: dje
Date: Fri May  9 17:13:30 2008
New Revision: 135118

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135118
Log:
        PR target/36090
        * config/rs6000/rs6000.c (print_operand_address): If the TOC
        address RHS contains an offset, output it as well.

        PR target/36182
        Revert:
        2008-05-08  Paolo Bonzini  <bonzini@gnu.org>
        PR target/36090
        * simplify-rtx.c (simplify_plus_minus): Create CONST of
        similar RTX_CONST_OBJ before CONST_INT.

Modified:
    branches/gcc-4_3-branch/gcc/ChangeLog
    branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c
    branches/gcc-4_3-branch/gcc/simplify-rtx.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[rsandifo at nildram dot co dot uk]

------- Comment #11 from rsandifo at nildram dot co dot uk  2008-05-09 17:17 -------
Subject: Re:  [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

"bonzini at gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
> I'll revert my patch on Monday even if no alternative solution for PR36090 is
> found during the weekend.  It opened too big cans of worms for a release
> branch, even though it fixed a serious regression.

For the record, I think it would be easier if the rs6000 port
used an unspec wrapper around the symbol, rather than a MINUS
of two symbols.  E.g.

   (const (unspec [(symbol_ref "foo")] UNSPEC_TOC))

and:

   (const (plus (unspec [(symbol_ref "foo")] UNSPEC_TOC)
                (const_int OFFSET)))

Richard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

------- Comment #12 from hp at gcc dot gnu dot org  2008-05-09 19:18 -------
There has been some speculation that the back-ends where the bug
appear are *all* to blame by e.g. having a flawed
GO_IF_LEGITIMATE_ADDRESS.  A gdb session shows that the back-end
validation hook that is used for the (CONST (MINUS sym2 sym1))
expression is (naturally when you think of it)
LEGITIMATE_CONSTANT_P.  In cases similar to the failure for CRIS,
the flawed expression isn't used in an address-operand so
GO_IF_LEGITIMATE_ADDRESS won't hit.

But, consider the documentation, which recommends defining
LEGITIMATE_CONSTANT_P to 1, which indeed most targets do; very
few actually look inside a CONST, i386 being a notable
exception.

I think that kind of CONST should simply not be generated by gcc
for now, and certainly not on the 4.3 branch.

If this CONST *is* to be generated (on trunk), IMHO some new
constant-expression validation needs to take place in
CONSTANT_P, one where the target can refuse expressions that
aren't valid assembly-code (in this case, for CRIS, sym2-sym1
where sym2 and sym1 are in different sections). Alternatively,
LEGITIMATE_CONSTANT_P redefined in the documentation and most
back-ends.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

------- Comment #13 from hp at gcc dot gnu dot org  2008-05-09 19:28 -------
(In reply to comment #5)
> Created an attachment (id=15620)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15620&action=view) [edit]
> patch for cris problem
> 
> This patch should fix the CRIS problem.

Looks fine except (as the OP also mentioned), I can't see what happens when
neither symbol has any information on the section.
Do you need me to test it?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[dje at gcc dot gnu dot org]

------- Comment #14 from dje at gcc dot gnu dot org  2008-05-09 21:41 -------
HP,

If there is no CONST wrapping the difference of symbols, does the CRIS port
continue to believe the address is legitimate?  In other words, Paolo's patch
without the CONST?  I would not object to removing the CONST because that
particular RTX disappears later and CONST is placed in the correct position.

Separate from the specific grouping satisfying legitimate_address, the RTL does
contain a difference of SYMBOL_REFs from different sections.  If it is not a
valid address, valid instruction, valid relocation, GCC will generate the
difference as an explicit subtraction across multiple instructions because it
is trying to calculate that operation.  I do not understand how the operation
GCC is trying to perform in the CRIS port is valid using multiple instructions.

Thanks, David


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

------- Comment #15 from hp at gcc dot gnu dot org  2008-05-10 06:59 -------
(In reply to comment #14)
> If there is no CONST wrapping the difference of symbols, does the CRIS port
> continue to believe the address is legitimate?

As I said, for the failure on CRIS, it's not passed as an
*address*, just an ordinary operand.

>  In other words, Paolo's patch
> without the CONST?

The CONST changes the world, so hopefully the right thing 
would happen.

> Separate from the specific grouping satisfying legitimate_address, the RTL does
> contain a difference of SYMBOL_REFs from different sections.  If it is not a
> valid address, valid instruction, valid relocation, GCC will generate the
> difference as an explicit subtraction across multiple instructions because it
> is trying to calculate that operation.

Correct.

> I do not understand how the operation
> GCC is trying to perform in the CRIS port is valid using multiple instructions.

Maybe it'll help if I just quote the faulty assembly code:
...
        move.d $r12,$r13
        add.d .LC6-__ZN...mangling elided...rep_storageE-12,$r13
        ba .L98
        nop
...

(The add.d does what you think; adds the offset to register $r13).
The ".LC6-__ZN...mangling elided...rep_storageE-12" (wrapped in a CONST) is
just passed to LEGITIMATE_CONSTANT_P at replacement time.  No MEM in sight,
hence no GO_IF_LEGITIMATE_ADDRESS call.

brgds, H-P


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2008-05-16 19:45 -------
Is this fixed on the branch?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

------- Comment #17 from hp at gcc dot gnu dot org  2008-05-17 02:04 -------
For cris-axis-elf, this was fixed on the branch with (e.g.) r135125 (never saw
a problem on trunk, FWIW, previous erroneous branch revision was r135087),
matching dje's reversion of bonzin's patch, so I'm closing this. 
Fallout-problems on other ports, please clone your own PR:s.


-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[pinskia at gcc dot gnu dot org]

------- Comment #18 from pinskia at gcc dot gnu dot org  2008-09-04 02:40 -------
Note the SPU back-end was not really the issue, the assembler/linker was the
issue and upgrading to a new one fixed the testcase for that issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182

[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

------- Comment #19 from hp at gcc dot gnu dot org  2008-09-04 02:44 -------
(In reply to comment #18)
> Note the SPU back-end was not really the issue, the assembler/linker was the
> issue and upgrading to a new one fixed the testcase for that issue.

... but that wasn't the issue for this PR, just the anectdotal reference in
comment #1 IIUC.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182