[Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin

[Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

            Bug ID: 65150
           Summary: bootstrap failure at r220878 on x86_64 darwin
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: howarth at bromo dot med.uc.edu

Current gcc trunk at r220878 fails to bootstrap on x86_64-apple-darwin14 with
the error...

/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc5.0/x86_64-apple-darwin14.3.0/bin/ -nostdinc++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs

-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include/x86_64-apple-darwin14.3.0

-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include
 -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150220/libstdc++-v3/libsupc++
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs
  -g -O2  -gtoggle -DIN_GCC    -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,-no_pie
-o build/genmatch \
    build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a build/errors.o
build/vec.o build/hash-table.o .././libiberty/libiberty.a -lintl -L/sw/lib
-liconv 
Undefined symbols for architecture x86_64:
  "std::type_info::__is_pointer_p() const", referenced from:
      vtable for __cxxabiv1::__si_class_type_info in
libstdc++.a(si_class_type_info.o)
      vtable for __cxxabiv1::__class_type_info in
libstdc++.a(class_type_info.o)
      vtable for std::type_info in libstdc++.a(tinfo.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
Makefile:2606: recipe for target 'build/genmatch' failed
make[3]: *** [build/genmatch] Error 1
make[3]: Leaving directory
'/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc'
Makefile:4408: recipe for target 'all-stage2-gcc' failed
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir'
Makefile:20723: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir'
Makefile:20918: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2

[Bug bootstrap/65150] bootstrap failure at r220878 on x86_64 darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #1 from howarth at bromo dot med.uc.edu ---
Failed for bootstrap using...

 ../gcc-5-20150220/configure --prefix=/sw --prefix=/sw/lib/gcc5.0
--mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-5.0

[Bug bootstrap/65150] bootstrap failure at r220878 on x86_64 darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #3 from howarth at bromo dot med.uc.edu ---
Also verified that r220886 bootstraps fine on x86_64-apple-darwin14 with
r220875 reverted.

[Bug bootstrap/65150] r220875 causes bootstrap failure on x86_64 darwin

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-21
     Ever confirmed|0                           |1

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Caused by...
>
> r220875 | jakub | 2015-02-20 11:44:37 -0500 (Fri, 20 Feb 2015) | 8 lines
> ...

Confirmed.

[Bug bootstrap/65150] r220875 causes bootstrap failure on x86_64 darwin

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
fix posted here.
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01320.html

[Bug bootstrap/65150] r220875 causes bootstrap failure on x86_64 darwin

[mrs at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |mrs at gcc dot gnu.org
           Severity|normal                      |critical

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0
            Summary|r220875 causes bootstrap    |[5 Regression] r220875
                   |failure on x86_64 darwin    |causes bootstrap failure on
                   |                            |x86_64 darwin

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, patch for discussions:
1) for DECL_VIRTUAL_P trying redirect_callers will unlikely help (not sure
about that too)
2) don't remove alias even if it is virtual or has any non-callers references
(what is the best way to express this condition)?
3) fall thru info create_thunk case if we didn't alias->remove ()
4) typo fix
5) use return false instead of return 0

--- gcc/ipa-icf.c.jj    2015-02-20 17:42:54.000000000 +0100
+++ gcc/ipa-icf.c    2015-02-23 12:16:27.669089598 +0100
@@ -662,6 +662,7 @@ sem_function::merge (sem_item *alias_ite
       redirect_callers
     = (!original_discardable
        && !DECL_COMDAT_GROUP (alias->decl)
+       && !DECL_VIRTUAL_P (alias->decl)
        && alias->get_availability () > AVAIL_INTERPOSABLE
        && original->get_availability () > AVAIL_INTERPOSABLE
        && !alias->instrumented_version);
@@ -724,15 +725,18 @@ sem_function::merge (sem_item *alias_ite

       /* The alias function is removed if symbol address
          does not matter.  */
-      if (!alias_address_matters)
-    alias->remove ();
+      if (!alias->externally_visible && !alias->address_taken)
+    {
+      alias->remove ();

-      if (dump_file && redirected)
-    fprintf (dump_file, "Callgraph local calls have been redirected.\n\n");
+      if (dump_file && redirected)
+        fprintf (dump_file, "Callgraph local calls have been
redirected.\n\n");
+      return true;
+    }
     }
-  /* If the condtion above is not met, we are lucky and can turn the
+  /* If the condition above is not met, we are lucky and can turn the
      function into real alias.  */
-  else if (create_alias)
+  if (create_alias)
     {
       alias->icf_merged = true;
       if (local_original->lto_file_data
@@ -762,7 +766,7 @@ sem_function::merge (sem_item *alias_ite
       if (dump_file)
         fprintf (dump_file, "Callgraph thunk cannot be created because of
COMDAT\n");

-      return 0;
+      return false;
     }

       if (DECL_STATIC_CHAIN (alias->decl))
@@ -770,7 +774,7 @@ sem_function::merge (sem_item *alias_ite
          if (dump_file)
            fprintf (dump_file, "Thunk creation is risky for static-chain
functions.\n\n");

-         return 0;
+         return false;
         }

       alias->icf_merged = true;

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> So, patch for discussions:
> 1) for DECL_VIRTUAL_P trying redirect_callers will unlikely help (not sure
> about that too)
> 2) don't remove alias even if it is virtual or has any non-callers
> references (what is the best way to express this condition)?
> 3) fall thru info create_thunk case if we didn't alias->remove ()
> 4) typo fix
> 5) use return false instead of return 0
> 
> --- gcc/ipa-icf.c.jj	2015-02-20 17:42:54.000000000 +0100
> +++ gcc/ipa-icf.c	2015-02-23 12:16:27.669089598 +0100
> @@ -662,6 +662,7 @@ sem_function::merge (sem_item *alias_ite
>        redirect_callers
>  	= (!original_discardable
>  	   && !DECL_COMDAT_GROUP (alias->decl)
> +	   && !DECL_VIRTUAL_P (alias->decl)
>  	   && alias->get_availability () > AVAIL_INTERPOSABLE
>  	   && original->get_availability () > AVAIL_INTERPOSABLE
>  	   && !alias->instrumented_version);
> @@ -724,15 +725,18 @@ sem_function::merge (sem_item *alias_ite
>  
>        /* The alias function is removed if symbol address
>           does not matter.  */
> -      if (!alias_address_matters)
> -	alias->remove ();
> +      if (!alias->externally_visible && !alias->address_taken)
> +	{
> +	  alias->remove ();
>  
> -      if (dump_file && redirected)
> -	fprintf (dump_file, "Callgraph local calls have been redirected.\n\n");
> +	  if (dump_file && redirected)
> +	    fprintf (dump_file, "Callgraph local calls have been redirected.\n\n");
> +	  return true;
> +	}
>      }

here we fall through to the case were we make a thunk - IFF we were not able to
rmove the alias.  However, potentially, we already moved all the callers from
the alias to the original.

(a) is that safe?
(b) we might as well avoid the work by testing whether the alias will be
removable before we set redirect_callers?


> -  /* If the condtion above is not met, we are lucky and can turn the
> +  /* If the condition above is not met, we are lucky and can turn the
>       function into real alias.  */
> -  else if (create_alias)
> +  if (create_alias)
>      {
>        alias->icf_merged = true;
>        if (local_original->lto_file_data
> @@ -762,7 +766,7 @@ sem_function::merge (sem_item *alias_ite
>  	  if (dump_file)
>  	    fprintf (dump_file, "Callgraph thunk cannot be created because of
> COMDAT\n");
>  
> -	  return 0;
> +	  return false;
>  	}
>  
>        if (DECL_STATIC_CHAIN (alias->decl))
> @@ -770,7 +774,7 @@ sem_function::merge (sem_item *alias_ite
>           if (dump_file)
>             fprintf (dump_file, "Thunk creation is risky for static-chain
> functions.\n\n");
>  
> -         return 0;
> +         return false;
>          }
>  
>        alias->icf_merged = true;

===

on x86_64-darwin12, Java and Ada look "normal".

there are regressions on (at least) the following C cases:

FAIL: gcc.dg/attr-noinline.c scan-assembler function_declaration_both_after

FAIL: gcc.dg/ipa/iinline-5.c scan-ipa-dump-not inline
"wrong_target[^\\\\n]*inline copy in"

however, ISTM that these might be more general issues being exposed by the
changes - since (at least) the iinline-5 shows up on Linux.

Essentially, I think we still need to address my points (b, c) in comment#23 on
pr63892 .. (I think Martin is looking, at least, at point b).
>From gcc-bugs-return-478200-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 23 17:48:10 2015
Return-Path: <gcc-bugs-return-478200-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13245 invoked by alias); 23 Feb 2015 17:48:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12874 invoked by uid 48); 23 Feb 2015 17:48:01 -0000
From: "tschwinge at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65181] New: Support for alloca in nvptx
Date: Mon, 23 Feb 2015 17:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: tschwinge at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc cf_gcctarget
Message-ID: <bug-65181-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg02532.txt.bz2
Content-length: 546

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide181

            Bug ID: 65181
           Summary: Support for alloca in nvptx
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
                CC: bernds at gcc dot gnu.org
            Target: nvptx

There is no alloca in PTX, but can it perhaps be implemented using PTX local
memory?

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
On I also see

FAIL: c-c++-common/attr-used.c  -std=gnu++(11|14|98)  scan-assembler
function_declaration_before

or

FAIL: c-c++-common/attr-used.c  -Wc++-compat   scan-assembler
function_declaration_before

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #10 from howarth at bromo dot med.uc.edu ---
(In reply to Jakub Jelinek from comment #9)

What about the significance (if any) of the observed regressions introduced by
the patch proposed in Comment 6?

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Iain Sandoe from comment #7)
> > here we fall through to the case were we make a thunk - IFF we were not able
> > to rmove the alias.  However, potentially, we already moved all the callers
> > from the alias to the original.
> > 
> > (a) is that safe?
> 
> Why not?

no idea :-) hence my question.
However, mostly, I wonder what happens when we transfer part of the information
(the callers) but not the remainder (the referrers)?

> > (b) we might as well avoid the work by testing whether the alias will be
> > removable before we set redirect_callers?
> 
> Redirecting the callers is beneficial even when we create trunk.
> For the redirected callers, they will jump directly to the right function,
> while
> without redirection you call a thunk, which in the better case just jumps to
> the right function (ie. sibcall), in the worse case calls it and then
> returns.
> So you save a few instructions on each redirected call.
> When alias is created instead of redirection (in that case we don't redirect
> callers right now), the only advantage of redirection would be tail
> recursion.

Thanks, that clarifies it for me.

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #12 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The functions ought to be equivalent, so transfering just some users should not
cause correctness issues. Of course unless the function is turned into a thunk
and/or the rest of references are optimized out, we will not see code size
decrease.

In longer term I would like to get references redirected, but doing so is bit
more touchy than redirecting callers. ipa-visibility already has code to bring
in static variable initializers and update them.  It probably should be
separated and also used by ipa-icf. Redirecting references in function bodies
will need new infrastructure.  

This is not that important issue as it may look, because in most cases we will
not redirect references because we lack knowledge about ADDR_EXPR being
posisbly used for pointer comparsion. For GCC 5 I guess we may want to do
redirection only when symbol passes
will_be_removed_from_program_if_no_direct_calls_p or when we are going to turn
the function into thunk anyway.

For GCC 6 we can introduce analysis to identify symbols whose address can
possibly be compared for equality.  Given the rising number of cases where this
matter, I think doing so will be a win.

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #13)
> (In reply to Dominique d'Humieres from comment #8)
> > On I also see
> > 
> > FAIL: c-c++-common/attr-used.c  -std=gnu++(11|14|98)  scan-assembler
> > function_declaration_before
> > 
> > or
> > 
> > FAIL: c-c++-common/attr-used.c  -Wc++-compat   scan-assembler
> > function_declaration_before
> 
> Hello.
> 
> I've just analyzed both these test cases (iinline-5.c and attr-used) and
> both situations looks correctly from my point of view:
> 
> If target does not support alias support in iinline-5.c, ICF optimization
> creates a thunk that inliner refuses to inline.
> 
> Similar situation for attr-used.c, where as we call condition
> redirect_callers and alias has no reference
> (_ZL27function_declaration_beforev), thus the symbol is removed.
> 
> I've been running complete c/c++ testsuite on x86_64-linux-pc (with disable
> alias support) and if it passes (modulo these testcases), I would like to
> apply Jakub's patch.

thanks for looking at these.

FWIW, LGTM (with suitable guards added to the tests for the target alias
support).
(I cannot officially approve of course ;) )
 ... if we find other regressions a new PR can be opened.
>From gcc-bugs-return-478307-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Feb 24 12:54:11 2015
Return-Path: <gcc-bugs-return-478307-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 72743 invoked by alias); 24 Feb 2015 12:54:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 72637 invoked by uid 48); 24 Feb 2015 12:54:04 -0000
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
Date: Tue, 24 Feb 2015 14:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: critical
X-Bugzilla-Who: marxin at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65150-4-MKVNtnfmMM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65150-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65150-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg02639.txt.bz2
Content-length: 1037

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #13 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #8)
> On I also see
> 
> FAIL: c-c++-common/attr-used.c  -std=gnu++(11|14|98)  scan-assembler
> function_declaration_before
> 
> or
> 
> FAIL: c-c++-common/attr-used.c  -Wc++-compat   scan-assembler
> function_declaration_before

Hello.

I've just analyzed both these test cases (iinline-5.c and attr-used) and both
situations looks correctly from my point of view:

If target does not support alias support in iinline-5.c, ICF optimization
creates a thunk that inliner refuses to inline.

Similar situation for attr-used.c, where as we call condition redirect_callers
and alias has no reference (_ZL27function_declaration_beforev), thus the symbol
is removed.

I've been running complete c/c++ testsuite on x86_64-linux-pc (with disable
alias support) and if it passes (modulo these testcases), I would like to apply
Jakub's patch.

Thanks,
Martin
>From gcc-bugs-return-478308-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Feb 24 13:05:19 2015
Return-Path: <gcc-bugs-return-478308-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 111064 invoked by alias); 24 Feb 2015 13:05:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 109964 invoked by uid 48); 24 Feb 2015 13:05:15 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60458] Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute
Date: Tue, 24 Feb 2015 14:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60458-4-qddEdbz9oR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60458-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60458-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg02640.txt.bz2
Content-length: 455

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`458

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 65187 has been marked as a duplicate of this bug. ***

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #15 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #14)

> FWIW, LGTM (with suitable guards added to the tests for the target alias
> support).
> (I cannot officially approve of course ;) )
>  ... if we find other regressions a new PR can be opened.

Does this even need approval from a Darwin maintainer (as it doesn't seem to
touch darwin-specific files at all)?

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[mrs at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #16 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
My take, Jakub should review/approve it.  The the people with darwin boxes can
check any proposed patch to ensure the testcases in question pass and ensure
the bootstrap works and there are no regressions.

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is really Honza's field, so I'd strongly prefer if Honza approved this
instead.

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> ---
if I understood the conversation in irc correctly, Honza you were suggesting
the following modification (to use alias->can_remove_if_no_direct_calls_p() as
the criterion for deciding on eligibility for removal)?

on x86_64-darwin12, bootstrap succeeds with the following; C test regressions
seem much the same as for comment #6 - preliminary tests only.
----

diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index e1af8bf..0c3d668 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -662,6 +662,7 @@ sem_function::merge (sem_item *alias_item)
       redirect_callers
        = (!original_discardable
           && !DECL_COMDAT_GROUP (alias->decl)
+          && !DECL_VIRTUAL_P (alias->decl)
           && alias->get_availability () > AVAIL_INTERPOSABLE
           && original->get_availability () > AVAIL_INTERPOSABLE
           && !alias->instrumented_version);
@@ -724,15 +725,18 @@ sem_function::merge (sem_item *alias_item)

       /* The alias function is removed if symbol address
          does not matter.  */
-      if (!alias_address_matters)
-       alias->remove ();
+      if (alias->can_remove_if_no_direct_calls_p())
+       {
+         alias->remove ();

-      if (dump_file && redirected)
-       fprintf (dump_file, "Callgraph local calls have been redirected.\n\n");
+         if (dump_file && redirected)
+           fprintf (dump_file, "Callgraph local calls have been
redirected.\n\n");
+         return true;
+       }
     }
-  /* If the condtion above is not met, we are lucky and can turn the
+  /* If the condition above is not met, we are lucky and can turn the
      function into real alias.  */
-  else if (create_alias)
+  if (create_alias)
     {
       alias->icf_merged = true;
       if (local_original->lto_file_data
@@ -762,7 +766,7 @@ sem_function::merge (sem_item *alias_item)
          if (dump_file)
            fprintf (dump_file, "Callgraph thunk cannot be created because of
COMDAT\n");

-         return 0;
+         return false;
        }

       if (DECL_STATIC_CHAIN (alias->decl))
@@ -770,7 +774,7 @@ sem_function::merge (sem_item *alias_item)
          if (dump_file)
            fprintf (dump_file, "Thunk creation is risky for static-chain
functions.\n\n");

-         return 0;
+         return false;
         }

       alias->icf_merged = true;

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #19 from Jan Hubicka <hubicka at ucw dot cz> ---
Hi,
I went in detail through the icf's merge functions and found quite few corner
cases where it may
lead to wrong code and some confussion.  This is my current patch I am testing.

Honza

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #20 from Jan Hubicka <hubicka at ucw dot cz> ---
Updated version to apply after Jakub's patch

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #21 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #20)
> Created attachment 34864 [details]
> icfmerge2
> 
> Updated version to apply after Jakub's patch

this bootstraps on x86_64-darwin12, and powerpc-darwin9 (at least).

in addition to new test failures seen with previous patches (FAIL:
gcc.dg/attr-noinline.c, FAIL: gcc.dg/ipa/iinline-5.c scan-ipa-dump-not inline
"wrong_target[^\\\\n]*inline copy in")

we also see :
FAIL: g++.dg/warn/Wsuggest-final.C  -std=gnu++11  (test for warnings, line 3)
(also, as expected, for c++98, c++14)

== looks like:

GCC/gcc-trunk/gcc/testsuite/g++.dg/warn/Wsuggest-final.C:3:8: warning:
Declaring type 'struct A' final would enable devirtualization of 2 calls
[-Wsuggest-final-types]
/GCC/gcc-trunk/gcc/testsuite/g++.dg/warn/Wsuggest-final.C:5:15: warning:
Declaring method 'virtual void A::b()' final would enable devirtualization of 2
calls [-Wsuggest-final-methods]
output is:
/GCC/gcc-trunk/gcc/testsuite/g++.dg/warn/Wsuggest-final.C:3:8: warning:
Declaring type 'struct A' final would enable devirtualization of 2 calls
[-Wsuggest-final-types]
/GCC/gcc-trunk/gcc/testsuite/g++.dg/warn/Wsuggest-final.C:5:15: warning:
Declaring method 'virtual void A::b()' final would enable devirtualization of 2
calls [-Wsuggest-final-methods]

FAIL: g++.dg/warn/Wsuggest-final.C  -std=gnu++11  (test for warnings, line 3)
FAIL: g++.dg/warn/Wsuggest-final.C  -std=gnu++11  (test for warnings, line 4)
PASS: g++.dg/warn/Wsuggest-final.C  -std=gnu++11  (test for warnings, line 5)
FAIL: g++.dg/warn/Wsuggest-final.C  -std=gnu++11 (test for excess errors)
Excess errors:
/GCC/gcc-trunk/gcc/testsuite/g++.dg/warn/Wsuggest-final.C:3:8: warning:
Declaring type 'struct A' final would enable devirtualization of 2 calls
[-Wsuggest-final-types]

==

there might be possibly be other related [C] fails - it's actually tricky to
get a clean baseline, since this PR is caused by a fix to a related one.

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #22 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Fri Feb 27 02:06:48 2015
New Revision: 221040

URL: https://gcc.gnu.org/viewcvs?rev=221040&root=gcc&view=rev
Log:
    PR bootstrap/65150
    * ipa-icf.c (symbol_compare_collection::symbol_compare_colleciton):
    Use address_matters_p.
    (redirect_all_callers, set_addressable): New functions.
    (sem_function::merge): Reorganize and fix merging issues.
    (sem_variable::merge): Likewise.
    (sem_variable::compare_sections): Remove.
    * common.opt (fmerge-all-constants, fmerge-constants): Remove
    Optimization flag.
    * symtab.c (symtab_node::resolve_alias): When alias has aliases,
    redirect them.
    (symtab_node::make_decl_local): Set ADDRESSABLE bit when
    decl is used.
    (address_matters_1): New function.
    (symtab_node::address_matters_p): New function.
    * cgraph.c (cgraph_edge::verify_corresponds_to_fndecl): Fix
    check for merged flag.
    * cgraph.h (address_matters_p): Declare.
    (symtab_node::address_taken_from_non_vtable_p): Remove.
    (symtab_node::address_can_be_compared_p): New method.
    (ipa_ref::address_matters_p): Move here from ipa-ref.c; simplify.
    * ipa-visibility.c (symtab_node::address_taken_from_non_vtable_p):
    Remove.
    (comdat_can_be_unshared_p_1) Use address_matters_p.
    (update_vtable_references): Fix formating.
    * ipa-ref.c (ipa_ref::address_matters_p): Move inline.
    * cgraphunit.c (cgraph_node::create_wrapper): Drop UNINLINABLE flag.
    * cgraphclones.c: Preserve merged and icf_merged flags.

Added:
    trunk/gcc/testsuite/gcc.dg/ipa/ipa-cp-1.c
    trunk/gcc/testsuite/gcc.dg/ipa/ipa-cp-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraph.c
    trunk/gcc/cgraph.h
    trunk/gcc/cgraphclones.c
    trunk/gcc/cgraphunit.c
    trunk/gcc/common.opt
    trunk/gcc/ipa-icf.c
    trunk/gcc/ipa-ref.c
    trunk/gcc/ipa-visibility.c
    trunk/gcc/symtab.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/ipa/ipa-icf-4.C
    trunk/gcc/testsuite/g++.dg/warn/Wsuggest-final.C
    trunk/gcc/testsuite/gcc.dg/ipa/iinline-5.c
    trunk/gcc/testsuite/gcc.dg/pr28685-1.c
    trunk/gcc/testsuite/gcc.dg/pr64454.c

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[mrs at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:

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

--- Comment #23 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
Fixed?

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #24 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I beleive so, at least I can bootstrap w/o the aliases.

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150

--- Comment #25 from howarth at bromo dot med.uc.edu ---
Bootstrap completed at r221041 on x86_64-apple-darwin14 for
c,c++,fortran,lto,objc,obj-c++,java language set.