Bug 17483 - [4.0 regression] ICE at -O3 when passing a reference.
Summary: [4.0 regression] ICE at -O3 when passing a reference.
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.0.0
: P2 critical
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
Keywords: ice-on-valid-code, monitored
: 17478 17497 (view as bug list)
Depends on:
Blocks: 8361 17478
  Show dependency treegraph
Reported: 2004-09-14 20:01 UTC by Volker Reichelt
Modified: 2004-09-18 14:40 UTC (History)
4 users (show)

See Also:
Known to work: 3.4.2
Known to fail: 4.0.0
Last reconfirmed: 2004-09-14 21:54:32


Note You need to log in before you can comment on or make changes to this bug.
Description Volker Reichelt 2004-09-14 20:01:17 UTC
Compiling the following valid code snippet (inspired by PR6189)
on mainline with -O3 yields an ICE:

struct A
    int i;
    int& ref() { return i; }

A foo()
    A a;
    return a;

void bar()

bug.cc: In function `void bar()':
bug.cc:15: error: address taken, but ADDRESSABLE bit not set

bug.cc:15: internal compiler error: verify_stmts failed.
Please submit a full bug report, [etc.]

The regression was introduced 2004-09-13 or 2004-09-14.
Comment 1 Andrew Pinski 2004-09-14 21:03:09 UTC
Hmm, it works for me on
Reading specs from /export/gates/pinskia/openbsd/bin/../lib/gcc/i686-unknown-openbsd3.1/4.0.0/
Configured with: /home/gates/pinskia/src/gnu/gcc/src/configure --target=i686-unknown-
openbsd3.1 --host=i686-unknown-openbsd3.1 --build=i686-unknown-openbsd3.1 --disable-nls --
verbose --enable-cpp --prefix=/home/gates/pinskia/openbsd --enable-shared --disable-libmudflap 
Thread model: single
gcc version 4.0.0 20040914 (experimental)

Which has the following changelog entry at the top of the list:
2004-09-13  James E Wilson  <wilson@specifixinc.com>
Comment 2 Andrew Pinski 2004-09-14 21:54:32 UTC
Confirmed, why I don't see in that compiler is beyond me but I see it on a different machine.

This is an inlining bug.

  int & D.1602;
  struct A a;
  int & D.1599;
  struct A D.1586;

  # BLOCK 0
  # PRED: ENTRY (fallthru)
  D.1602 = &D.1586.i;
  D.1599 = D.1602;
  *D.1599 = 0;
Comment 3 Andrew Pinski 2004-09-14 21:56:54 UTC
*** Bug 17478 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Pinski 2004-09-15 05:55:56 UTC
Here is another example, and it does not happen in the C front-end because NRV happens later:
struct A { int i; };
struct A foo()
    struct A a;
    int *aaa = &a.i;
    *aaa = 0;
    return a;
void bar()
Comment 5 Andrew Pinski 2004-09-15 10:12:59 UTC
*** Bug 17497 has been marked as a duplicate of this bug. ***
Comment 6 Steven Bosscher 2004-09-15 12:15:10 UTC
I cannot reproduce this on amd64 normal or amd64 -m32.
Comment 7 Wolfgang Bangerth 2004-09-15 12:50:21 UTC
As has been mentioned somewhere else already: the call to error() 
should be changed to internal_error() -- the message gcc prints 
looks just like a message indicating an error in the code, not 
one inside gcc. 
Comment 8 Andrew Pinski 2004-09-15 17:55:50 UTC
That is because NRV is not happening until later for i686.
But this can be reproduced on ppc for sure.
Comment 9 Andrew Pinski 2004-09-16 01:57:06 UTC
I have a fix for this problem.  Basically we need to mark the variable as TREE_ADDRESSABLE in 
Comment 10 Andrew Pinski 2004-09-16 02:12:56 UTC
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01640.html>.
Comment 11 Andrew Pinski 2004-09-16 03:27:42 UTC
The problem comes from the tree optimizations happen for foo so the TREE_ADDRESSABLE bit is unset 
but since we don't do inlining from that trees we get the orginal code where we take the address.  So 
this is really a tree problem where we don't reset the addressable flags after doing the optimizations on 
the tree.  If we did the inlining from the optimizated code, we would not have this problem in fact we 
don't have to do the optimizations twice on the code (which can reduce the compile time :) ).
Comment 12 Andrew Pinski 2004-09-17 01:36:00 UTC
Here is a testcase which fails on x86 (where we do NRV early in the front-end):
struct A { int i; int j, k,l,m; };
struct A foo()
    struct A a;
    int *aaa = &a.i;
    *aaa = 0;
    return a;
void bar()

: Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530).
Comment 13 Andrew Pinski 2004-09-17 03:32:17 UTC
I should note that the date I quoted is when &a->b (and &a.b) is no longer lowered so this was a latent 
Comment 14 Andrew Pinski 2004-09-18 14:40:20 UTC
Fixed by the patch which fixed 17153.