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

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.

i'll post a temptative patch for the cris issue if i get to it during the commute.

ahem, tentative

Created attachment 15620 [details]
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.

Richard (Sandiford), could you look at the patch?  You are the varasm.c expert. :-)

not wrong-code, it fails to assemble.

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.

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.

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

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

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.

(In reply to comment #5)
> Created an attachment (id=15620) [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?

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

(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

Is this fixed on the branch?

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.

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.

(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.