* [Bug bootstrap/65150] bootstrap failure at r220878 on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
@ 2015-02-20 23:47 ` howarth at bromo dot med.uc.edu
2015-02-21 9:39 ` howarth at bromo dot med.uc.edu
` (22 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2015-02-20 23:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] bootstrap failure at r220878 on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
2015-02-20 23:47 ` [Bug bootstrap/65150] " howarth at bromo dot med.uc.edu
@ 2015-02-21 9:39 ` howarth at bromo dot med.uc.edu
2015-02-21 12:47 ` [Bug bootstrap/65150] r220875 causes bootstrap failure " dominiq at lps dot ens.fr
` (21 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2015-02-21 9:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
2015-02-20 23:47 ` [Bug bootstrap/65150] " howarth at bromo dot med.uc.edu
2015-02-21 9:39 ` howarth at bromo dot med.uc.edu
@ 2015-02-21 12:47 ` dominiq at lps dot ens.fr
2015-02-21 13:47 ` iains at gcc dot gnu.org
` (20 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-02-21 12:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (2 preceding siblings ...)
2015-02-21 12:47 ` [Bug bootstrap/65150] r220875 causes bootstrap failure " dominiq at lps dot ens.fr
@ 2015-02-21 13:47 ` iains at gcc dot gnu.org
2015-02-22 23:16 ` mrs at gcc dot gnu.org
` (19 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: iains at gcc dot gnu.org @ 2015-02-21 13:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (3 preceding siblings ...)
2015-02-21 13:47 ` iains at gcc dot gnu.org
@ 2015-02-22 23:16 ` mrs at gcc dot gnu.org
2015-02-23 10:18 ` [Bug bootstrap/65150] [5 Regression] " rguenth at gcc dot gnu.org
` (18 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mrs at gcc dot gnu.org @ 2015-02-22 23:16 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (4 preceding siblings ...)
2015-02-22 23:16 ` mrs at gcc dot gnu.org
@ 2015-02-23 10:18 ` rguenth at gcc dot gnu.org
2015-02-23 12:52 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-02-23 10:18 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (5 preceding siblings ...)
2015-02-23 10:18 ` [Bug bootstrap/65150] [5 Regression] " rguenth at gcc dot gnu.org
@ 2015-02-23 12:52 ` jakub at gcc dot gnu.org
2015-02-23 17:56 ` iains at gcc dot gnu.org
` (16 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-02-23 12:52 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (6 preceding siblings ...)
2015-02-23 12:52 ` jakub at gcc dot gnu.org
@ 2015-02-23 17:56 ` iains at gcc dot gnu.org
2015-02-23 17:58 ` dominiq at lps dot ens.fr
` (15 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: iains at gcc dot gnu.org @ 2015-02-23 17:56 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (7 preceding siblings ...)
2015-02-23 17:56 ` iains at gcc dot gnu.org
@ 2015-02-23 17:58 ` dominiq at lps dot ens.fr
2015-02-23 20:47 ` howarth at bromo dot med.uc.edu
` (14 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-02-23 17:58 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (8 preceding siblings ...)
2015-02-23 17:58 ` dominiq at lps dot ens.fr
@ 2015-02-23 20:47 ` howarth at bromo dot med.uc.edu
2015-02-23 22:29 ` iains at gcc dot gnu.org
` (13 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2015-02-23 20:47 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (9 preceding siblings ...)
2015-02-23 20:47 ` howarth at bromo dot med.uc.edu
@ 2015-02-23 22:29 ` iains at gcc dot gnu.org
2015-02-24 4:31 ` hubicka at gcc dot gnu.org
` (12 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: iains at gcc dot gnu.org @ 2015-02-23 22:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (10 preceding siblings ...)
2015-02-23 22:29 ` iains at gcc dot gnu.org
@ 2015-02-24 4:31 ` hubicka at gcc dot gnu.org
2015-02-24 14:06 ` iains at gcc dot gnu.org
` (11 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: hubicka at gcc dot gnu.org @ 2015-02-24 4:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (11 preceding siblings ...)
2015-02-24 4:31 ` hubicka at gcc dot gnu.org
@ 2015-02-24 14:06 ` iains at gcc dot gnu.org
2015-02-24 15:02 ` howarth at bromo dot med.uc.edu
` (10 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: iains at gcc dot gnu.org @ 2015-02-24 14:06 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (12 preceding siblings ...)
2015-02-24 14:06 ` iains at gcc dot gnu.org
@ 2015-02-24 15:02 ` howarth at bromo dot med.uc.edu
2015-02-24 20:01 ` mrs at gcc dot gnu.org
` (9 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2015-02-24 15:02 UTC (permalink / raw)
To: gcc-bugs
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)?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (13 preceding siblings ...)
2015-02-24 15:02 ` howarth at bromo dot med.uc.edu
@ 2015-02-24 20:01 ` mrs at gcc dot gnu.org
2015-02-24 20:20 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: mrs at gcc dot gnu.org @ 2015-02-24 20:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (14 preceding siblings ...)
2015-02-24 20:01 ` mrs at gcc dot gnu.org
@ 2015-02-24 20:20 ` jakub at gcc dot gnu.org
2015-02-25 1:08 ` iains at gcc dot gnu.org
` (7 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-02-24 20:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (15 preceding siblings ...)
2015-02-24 20:20 ` jakub at gcc dot gnu.org
@ 2015-02-25 1:08 ` iains at gcc dot gnu.org
2015-02-25 3:36 ` hubicka at ucw dot cz
` (6 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: iains at gcc dot gnu.org @ 2015-02-25 1:08 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (16 preceding siblings ...)
2015-02-25 1:08 ` iains at gcc dot gnu.org
@ 2015-02-25 3:36 ` hubicka at ucw dot cz
2015-02-25 5:18 ` hubicka at ucw dot cz
` (5 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: hubicka at ucw dot cz @ 2015-02-25 3:36 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (17 preceding siblings ...)
2015-02-25 3:36 ` hubicka at ucw dot cz
@ 2015-02-25 5:18 ` hubicka at ucw dot cz
2015-02-25 22:48 ` iains at gcc dot gnu.org
` (4 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: hubicka at ucw dot cz @ 2015-02-25 5:18 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (18 preceding siblings ...)
2015-02-25 5:18 ` hubicka at ucw dot cz
@ 2015-02-25 22:48 ` iains at gcc dot gnu.org
2015-02-27 6:14 ` hubicka at gcc dot gnu.org
` (3 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: iains at gcc dot gnu.org @ 2015-02-25 22:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (19 preceding siblings ...)
2015-02-25 22:48 ` iains at gcc dot gnu.org
@ 2015-02-27 6:14 ` hubicka at gcc dot gnu.org
2015-02-27 7:37 ` mrs at gcc dot gnu.org
` (2 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: hubicka at gcc dot gnu.org @ 2015-02-27 6:14 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (20 preceding siblings ...)
2015-02-27 6:14 ` hubicka at gcc dot gnu.org
@ 2015-02-27 7:37 ` mrs at gcc dot gnu.org
2015-02-27 8:28 ` hubicka at gcc dot gnu.org
2015-02-27 15:29 ` howarth at bromo dot med.uc.edu
23 siblings, 0 replies; 25+ messages in thread
From: mrs at gcc dot gnu.org @ 2015-02-27 7:37 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (21 preceding siblings ...)
2015-02-27 7:37 ` mrs at gcc dot gnu.org
@ 2015-02-27 8:28 ` hubicka at gcc dot gnu.org
2015-02-27 15:29 ` howarth at bromo dot med.uc.edu
23 siblings, 0 replies; 25+ messages in thread
From: hubicka at gcc dot gnu.org @ 2015-02-27 8:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
2015-02-20 23:45 [Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin howarth at bromo dot med.uc.edu
` (22 preceding siblings ...)
2015-02-27 8:28 ` hubicka at gcc dot gnu.org
@ 2015-02-27 15:29 ` howarth at bromo dot med.uc.edu
23 siblings, 0 replies; 25+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2015-02-27 15:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread