[Bug c++/17053] New: [3.5 Regression] Repo functionality partially broken on AIX

[Bug c++/17053] New: [3.5 Regression] Repo functionality partially broken on AIX

[dje at gcc dot gnu dot org]

Mark Mitchell's patch to clean up linkage handling has damaged -frepo
functionality on AIX and has caused a number of regressions in the testsuite:

g++.old-deja/g++.pt/instantiate4.C
g++.old-deja/g++.pt/instantiate6.C
g++.old-deja/g++.pt/repo1.C
g++.old-deja/g++.pt/repo2.C
g++.old-deja/g++.pt/repo4.C

The testcases now all result in a linker error.

./xgcc -B./ -c -frepo repo4.C
./xgcc -B./ -frepo repo4.o
collect: recompiling repo4.C
collect: relinking
ld: 0711-317 ERROR: Undefined symbol: _GLOBAL__F_main

After the linkage patch, the existence of frame info for some functions depends
on whether the -frepo option is present.  collect2.c does not re-scan the object
file as part of relinking and uses the existing frame information from the first
scan referencing frame info that no longer is present when relinking without
-frepo option.

I have tracked down the difference in frame info to the call to _ZN1SIiED1Ev. 
Depending on the presence of -frepo, the tree for that call gets marked
TREE_NOTHROW, causing ecf_flags to have ECF_NOTHROW set, causing REG_EH_REGION
reg_note to be attached to the RTL, causing the TREE_NOTHROW and
all_throwers_are_sibcalls to be cleared for the function, causing
output_call_frame_info() to determine that no unwinding will be needed and not
emitting any frame info.

For targets that do not use collect2, the change in frame info probably will go
unnoticed.  I do not know if the new -frepo-dependent behavior is intentional
and/or a consequence of the lazy evaluation.

I am not sure whether the NOTHROW property should be changing.  collect2
possibly could be changed to rescan the files when relinking, but that may be
papering over a problem if NOTHROW should be consistent.

-- 
           Summary: [3.5 Regression] Repo functionality partially broken on
                    AIX
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dje at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-ibm-aix5.1.0.0
  GCC host triplet: powerpc-ibm-aix5.1.0.0
GCC target triplet: powerpc-ibm-aix5.1.0.0


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |critical
           Keywords|                            |wrong-code
   Target Milestone|---                         |3.5.0


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[dje at gcc dot gnu dot org]

------- Additional Comments From dje at gcc dot gnu dot org  2004-08-17 01:49 -------
The divergence appears to occur in cp/decl.c:finish_function().  In the -frepo
case, TREE_NOTHROW (fndecl) is not set, while in the non-frepo case, it is.  The
templates are processed a different number of times with the different options,
so it appears that the compiler is noticing something or remembering something
that was not evident with the other option.

-- 


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-17 03:35 -------
I understand why the NOTHROW bit is changing, and, in fact, I'm not really sure
how my patch made this different.  The reason it is changing is that during the
initial build the template is not instantiated (in the hopes that some other
translation unit will instantiate it).  Because it is not instantiated, the
compiler does not know whether or not the body of the template could throw an
exception.  So, it does not set the NOTHROW bit.  When reocmpiling (from
collect2), the template will be instantiated, and so the compiler then cleverly
notices that it cannot throw an exception.

I will look into why this is causing a problem.

-- 


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-17 03:37 -------
OK, now I understand why this is causing a problem -- the next question is what
to do about it...

-- 


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-17 05:50 -------
It looks like collect2.c does template instantiation first, followed by
discovery of global constructors -- on all platforms except those that define
COLLECT_EXPORT_LIST, i.e., all platforms except AIX.  On AIX, we do these things
in the opposite order: constructor discovery first, followed by template
instantiation.  The AIX order does not seem safe, in general: instantiating
templates can certainly result in the need for additional static constructors.

I'm not sure how best to fix this.  In the abstract, it's wrong of the C++ front
end not to instantiate the template in all cases; the standard requires we
instantiate it.  However, with -frepo, we've always tried to avoid instantiating
templates unncessarily.  Without doing full optimization on the template body,
we wouldn't be assured of getting NOTHROW set correctly anyhow.

I guess I need to understand why collect2 does things in the opposite order in AIX.

-- 


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-17 05:53 -------
So we should confirm this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-17 05:53:10
               date|                            |


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[dje at gcc dot gnu dot org]

------- Additional Comments From dje at gcc dot gnu dot org  2004-08-17 15:08 -------
Note that the divergence occurs with -frepo before the repo file has been 
updated with information about which templates should be instantiated and 
recompiled.

AIX performs constructor discovery first because the garbage collecting linker 
may find no references to static constructors before the scan, which will cause 
it not to link in the static constructors, leaving nothing for the scan to find.

-- 


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2004-08-17 15:49 -------
Subject: Re:  [3.5 Regression] Repo functionality partially
 broken on AIX

dje at gcc dot gnu dot org wrote:

>------- Additional Comments From dje at gcc dot gnu dot org  2004-08-17 15:08 -------
>Note that the divergence occurs with -frepo before the repo file has been 
>updated with information about which templates should be instantiated and 
>recompiled.
>  
>
Right, I understand.  With the "-frepo" switch on the first compilation, 
G++ will avoid instantiating the template, and therefore will not learn 
that it cannot throw.  Without the "-frepo" switch, it will have to 
instantiate the template, will therefore learn that it cannot throw.

>AIX performs constructor discovery first because the garbage collecting linker 
>may find no references to static constructors before the scan, which will cause 
>it not to link in the static constructors, leaving nothing for the scan to find.
>
I understand.

There might have been bugs in this area before; for example, I'd expect:

  int f();

  template <typename T>
  struct S {
    static int i;
  };

 template <typename T>
 int S<T>::i = f();
 
 int main () { return S<int>::i; }

to result in a global constructor call without -frepo, but not with 
-frepo, and therefore have the same problem.  However, it may be that 
the lack of weak symbols means that without -frepo the compiler delays 
instantiation of S<int>::i, and that we therefore skirt this particular 
problem.

In any case, I don't think there's really any way to get NOTHROW set 
correctly 100% of the time unless we actually generate code (all the way 
through the optimizers) for every template that might be instantiated.  
So, I think this problem needs to be addressed in some other way.

I think that that the best thing would be to make the constructor 
discovery process iterative in the case of AIX.  After each cycle of 
recompilation, we need to regenerate the list.  If you agree, I will try 
to write the code, but I don't have an AIX system, so you might have to 
do the testing.

Thanks,



-- 


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[dje at watson dot ibm dot com]

------- Additional Comments From dje at watson dot ibm dot com  2004-08-17 15:56 -------
Subject: Re:  [3.5 Regression] Repo functionality partially broken on AIX 

	I didn't know if gcc's behavior was correct.  If you agree that it
is, I will develop the fix for collect2.c so that you can concentrate on
other things.  I didn't know if AIX was raising a problem that was hidden
on other systems.



-- 


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

[Bug c++/17053] [3.5 Regression] Repo functionality partially broken on AIX

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2004-08-17 16:01 -------
Subject: Re:  [3.5 Regression] Repo functionality partially
 broken on AIX

dje at watson dot ibm dot com wrote:

>------- Additional Comments From dje at watson dot ibm dot com  2004-08-17 15:56 -------
>Subject: Re:  [3.5 Regression] Repo functionality partially broken on AIX 
>
>	I didn't know if gcc's behavior was correct.  
>
I believe so, yes.  Basically, it is being conservative about whether or 
not the template instantiation can throw, until it is sure.

>If you agree that it
>is, I will develop the fix for collect2.c so that you can concentrate on
>other things.  
>
Thanks!



-- 


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

[Bug c++/17053] [4.0 Regression] Repo functionality partially broken on AIX

[dje at gcc dot gnu dot org]

------- Additional Comments From dje at gcc dot gnu dot org  2004-10-14 14:49 -------
reducing priority

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


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

[Bug c++/17053] [4.0 Regression] Repo functionality partially broken on AIX (collect2.c)

[neroden at gcc dot gnu dot org]

------- Additional Comments From neroden at gcc dot gnu dot org  2004-11-26 23:28 -------
DJE said he'd develop the collect2 fix, so assigning... 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dje at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
            Summary|[4.0 Regression] Repo       |[4.0 Regression] Repo
                   |functionality partially     |functionality partially
                   |broken on AIX               |broken on AIX (collect2.c)


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

[Bug c++/17053] [4.0/4.1 Regression] Repo functionality partially broken on AIX (collect2.c)

[dje at gcc dot gnu dot org]

------- Additional Comments From dje at gcc dot gnu dot org  2005-03-24 19:58 -------
reducing priority again.  I do not see a clean way to rescan the application 
from the tlink loop.  -frepo is not a primary feature and -frepo continues to 
work for most real applications.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3


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

[Bug c++/17053] [4.0/4.1 Regression] Repo functionality partially broken on AIX (collect2.c)

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-17 03:00 -------
Retargeted to 4.0.1.  

AIX maintainer has indicated that this bug is not particularly critical, and
that the problems are difficult to solve.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.0                       |4.0.1


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

[Bug c++/17053] [4.0/4.1 Regression] Repo functionality partially broken on AIX (collect2.c)

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-07-06 16:44 -------
Postponed until 4.0.2.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.1                       |4.0.2


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

[Bug c++/17053] [4.0/4.1 Regression] Repo functionality partially broken on AIX (collect2.c)

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.2                       |4.0.3


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