http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #8 from Markus Trippelsdorf ---
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 18740]
ipa_profile_generate_summary () at ../../gcc/gcc/ipa-profile.c:214
214 = h->hvalue.counters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470
--- Comment #24 from Jakub Jelinek ---
Author: jakub
Date: Mon Dec 16 08:09:05 2013
New Revision: 206009
URL: http://gcc.gnu.org/viewcvs?rev=206009&root=gcc&view=rev
Log:
PR middle-end/58956
PR middle-end/59470
* gimple-walk.h (walk_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58956
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Mon Dec 16 08:09:05 2013
New Revision: 206009
URL: http://gcc.gnu.org/viewcvs?rev=206009&root=gcc&view=rev
Log:
PR middle-end/58956
PR middle-end/59470
* gimple-walk.h (walk_st
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #9 from Markus Trippelsdorf ---
Maybe something like this:
diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
index ef9e24224921..66f87816e1bf 100644
--- a/gcc/ipa-profile.c
+++ b/gcc/ipa-profile.c
@@ -210,6 +210,8 @@ ipa_profile_gene
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59522
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59522
--- Comment #2 from Andrew Pinski ---
The one thing is your new g++ is it executing your newly build cc1plus? That
is the main reason why it would fail. Try add -B . to the command line if you
are still in the build directory.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59522
--- Comment #3 from Andrew Pinski ---
(In reply to Marek Polacek from comment #1)
> Bugzilla isn't the right place for these kind of questions, use gcc-help
> mailing list.
Even gcc-help might not be the correct place to ask this question. gcc@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56716
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542
Bug 46542 depends on bug 45685, which changed state.
Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity
in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42632
Bug 42632 depends on bug 45685, which changed state.
Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity
in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22007
Kai Tietz changed:
What|Removed |Added
Status|NEW |WAITING
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #8 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58756
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Mon Dec 16 10:34:28 2013
New Revision: 206011
URL: http://gcc.gnu.org/viewcvs?rev=206011&root=gcc&view=rev
Log:
PR libgomp/58756
* omp-low.c (lower_rec_input_clauses) : For
red
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58756
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59473
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Mon Dec 16 10:52:48 2013
New Revision: 206012
URL: http://gcc.gnu.org/viewcvs?rev=206012&root=gcc&view=rev
Log:
PR ipa/59473
* ipa-devirt.c (get_class_context): Do not ICE when ty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350
--- Comment #29 from Eric Botcazou ---
> I'm seeing this on arm-none-eabi now as well:
>
> FAIL: gcc.dg/pr59350.c (internal compiler error)
> FAIL: gcc.dg/pr59350.c (test for excess errors)
>
> $TOP/gcc/gcc/testsuite/gcc.dg/pr59350.c: In functio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59473
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #10 from Jan Hubicka ---
Yes, this patch is OK, will you test and commit it? I will also re-test the
patch that should prevent early passes from missing this optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59524
Bug ID: 59524
Summary: cilk-plus tests are run with --disable-libcilkrts
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542
Bug 46542 depends on bug 45685, which changed state.
Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity
in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42632
Bug 42632 depends on bug 45685, which changed state.
Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity
in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59511
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350
--- Comment #30 from ktkachov at gcc dot gnu.org ---
It seems I had some weird tree state. It passes on trunk after doing a clean
build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #11 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #10)
> Yes, this patch is OK, will you test and commit it? I will also re-test the
> patch that should prevent early passes from missing this optimization.
I've t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525
Bug ID: 59525
Summary: Inheritance problems
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525
--- Comment #1 from Sarantis Pantazis ---
Created attachment 31446
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31446&action=edit
Minimal working example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59523
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #19 from Jan Hubicka ---
> I can't reproduce this.
> What platform is this? What is the command line?
I used x86-64 and you apparently need LTO to trigger it. I used same
commandline
as in original report
g++ -flto-partition=none -fl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #12 from Jan Hubicka ---
OK, will commit it shortly (after re-testing with break replaced by continue).
You may just ask for write access and write me as garant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #20 from Jan Hubicka ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
>
> --- Comment #17 from Markus Trippelsdorf ---
> In the non-lto case one has:
> lib/libLLVMAsmParser.so:
> U
> _ZN4llvm21SymbolTableListTraitsINS_10BasicB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59526
Bug ID: 59526
Summary: [C++11] Defaulted special member functions don't
accept noexcept if a member has a non-trivial noexcept
operator in the corresponding special member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56645
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #13 from Jan Hubicka ---
Author: hubicka
Date: Mon Dec 16 13:37:43 2013
New Revision: 206014
URL: http://gcc.gnu.org/viewcvs?rev=206014&root=gcc&view=rev
Log:
PR ipa/59265
* ipa-profile.c (ipa_profile_generate_summary): Do not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54949
--- Comment #4 from janus at gcc dot gnu.org ---
Both test cases give an ICE at least with 4.6 on upward, but not with 4.4, so
the ICE is technically a regression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #21 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #20)
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
> >
> > --- Comment #17 from Markus Trippelsdorf ---
> > In the non-lto case one has:
> > lib/libLLVMAs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527
Bug ID: 59527
Summary: [4.9 Regression] ICE: in fixup_reorder_chain, at
cfgrtl.c:3739 during PGO Firefox build
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59008
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #5 from joseph at codesourcery dot com ---
On Thu, 12 Dec 2013, algrant at acm dot org wrote:
> demonstrates the same lack of ordering. You suggest that this might
> be a problem with the atomic built-ins - and yes, if this had been
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58296
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #15 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #14)
> Fixed. Thank you for testing it. The Firefox ICE
> Seems to fix Mozilla build untill the next (unrelated) ICE:
>
> /var/tmp/mozilla-central/js/src/vm/Stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Mon Dec 16 15:33:42 2013
New Revision: 206017
URL: http://gcc.gnu.org/viewcvs?rev=206017&root=gcc&view=rev
Log:
PR libgomp/59337
* openmp.c (resolve_omp_atomic): Adjust error messa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #11 from Jakub Jelinek ---
Patches have been posted, but haven't been reviewed yet.
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00558.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00964.html
Various tsan testcases right now fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #8 from H.J. Lu ---
On Linux/x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #12 from Alexander Potapenko ---
I wonder if https://code.google.com/p/address-sanitizer/issues/detail?id=253 is
relevant here. In the case TSan tests do fork() (which I'm not expecting from
them, however) the parent and the child will
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527
--- Comment #1 from Markus Trippelsdorf ---
Created attachment 31447
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31447&action=edit
unreduced testcase
% g++ -w -r -nostdlib -fprofile-use -fprofile-correction -march=amdfam10
-fno-exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #3 from Martin Jambor ---
It should be easy to make SRA safely cope with BIT_FIELD_REFs,
REALPART_EXPRs and IMAGPART_EXPRs under a VIEW_CONVERT_EXPR (as
opposed to those under a COMPONENT_REF, ARRAY_REF, MEM_REF or
similar). I'd prefe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
Ollie Wild changed:
What|Removed |Added
CC||aaw at gcc dot gnu.org
--- Comment #4 from O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59514
--- Comment #1 from Jonathan Wakely ---
I think this is already fixed on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488
--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #10)
> ktkachov,
>
> It seems to be working fine for me with my arm-eabi cross compiler. Perhaps
> you could provide some more details:
>
> make check-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #5 from Jonathan Wakely ---
Users can specialize std::set::find to do something different,
e.g. write to a file, and it must not do that if they call std::find.
It's not a matter of whether the type is the library's iterator type or n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #1 from Zhendong Su ---
Below is simpler testcase that triggers the same ICE:
int a, b, c, d;
void
foo ()
{
for (; d; d++)
for (b = 0; b < 14; b++)
{
c |= 1;
if (a)
bre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59528
Bug ID: 59528
Summary: Profiledbootstrap should use stage1 compiler during
stagefeedback
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #9 from Jakub Jelinek ---
Note this must be PCH related, can't reproduce it without PCH even with --param
ggc-min-expand=0 --param ggc-min-heapsize=0.
Unfortunately I only reproduce it two i686 builds ago and don't remember the
exact r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #6 from Oleg Endo ---
(In reply to Jonathan Wakely from comment #5)
> Users can specialize std::set::find to do something
> different, e.g. write to a file, and it must not do that if they call
> std::find.
>
> It's not a matter of wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #16 from Jan Hubicka ---
> Executing: c++ -o js -Wall -Wpointer-arith -Woverloaded-virtual
> -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null
> -Wsign-compare -Wno-invalid-offsetof -Wcast-align -flto=4 -fprofile-u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #22 from Jan Hubicka ---
00010 // This file implements the stickier parts of the SymbolTableListTraits
class,
00011 // and is explicitly instantiated where needed to avoid defining all this
code
00012 // in a widely used header.
I wou
-gnu/sys-include /tmp/x.cc -quiet -dumpbase x.cc
-mtune=corei7 -march=corei7 -auxbase-strip /tmp/x.s -g -g -O2 -O2 -std=gnu++11
-version -fdiagnostics-color=never -fmessage-length=0 -ffunction-sections
-fdata-sections -o /tmp/x.s
GNU C++ (GCC) version 4.9.0 20131216 (experimental) [trunk revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723
--- Comment #3 from Jeffrey A. Law ---
Andrew, no.
4.2 didn't muck things up at all. The 4.2 code is clearly better (unless
you're vectorizing the loop).
What's happening is the IV code changes the loop structure enough that
VRP2/DOM2 are unabl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #11 from H.J. Lu ---
It is PCH related. Stage1 and stage2 cc1plus can compile the same input.
But stage3 cc1plus fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |4.7.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59466
--- Comment #1 from Vladimir Makarov ---
Author: vmakarov
Date: Mon Dec 16 18:24:54 2013
New Revision: 206023
URL: http://gcc.gnu.org/viewcvs?rev=206023&root=gcc&view=rev
Log:
2013-12-16 Vladimir Makarov
PR rtl-optimization/59466
* em
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527
--- Comment #2 from Teresa Johnson ---
I will take a look and report back. -freorder-blocks-and-partition was
recently enabled by default, which presumably exposed this issue.
Thanks,
Teresa
On Mon, Dec 16, 2013 at 8:21 AM, octoploid at yandex do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #12 from H.J. Lu ---
(In reply to H.J. Lu from comment #11)
> It is PCH related. Stage1 and stage2 cc1plus can compile the same input.
> But stage3 cc1plus fails.
It is very sensitive PCH load address.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
Anton Mitrofanov changed:
What|Removed |Added
CC||BugMaster at narod dot ru
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #3 from Oleg Endo ---
(In reply to Oleg Endo from comment #2)
> As of rev 204180 (4.9) this problem still exists.
> As far as I understand, the actual root of the problem is that the 'unsigned
> char' mem loads into regs are neither si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #19 from H.J. Lu ---
(In reply to Anton Mitrofanov from comment #18)
> This patch is ok for mingw32 target but may produce incorrect code for
> x86_64 linux target in case of saving/restoring both rax and r10. In that
> case during res
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #20 from Anton Mitrofanov ---
I was talking about:
if (r10_live && eax_live)
{
t = plus_constant (Pmode, stack_pointer_rtx, allocate);
emit_move_insn (gen_rtx_REG (word_mode, R10_REG),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59529
Bug ID: 59529
Summary: fix experimental/string_view end-of-string edge cases
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #21 from Anton Mitrofanov ---
It should be:
t = plus_constant (Pmode, stack_pointer_rtx,
allocate + UNITS_PER_WORD);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59530
Bug ID: 59530
Summary: Incorrect check on string_view operator[]
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59531
Bug ID: 59531
Summary: string_view overrun in copy operation
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
Geoff Romer changed:
What|Removed |Added
CC||gromer at google dot com
--- Comment #5 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18469
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
--- Comment #9 from Jan Hubicka ---
> Honza,
>
> I've tested your patch from comment 7 and it doesn't work.
> However your suggestion "to simply return NULL when inner_binfo is NULL"
> does seem to work fine. I've successfully build Chromium with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59514
Chris Sakalis changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945
--- Comment #5 from Jan Hubicka ---
> Even better something that uses it and that even declares the original:
> extern int j;
> static int i __attribute__((weakref("j")));
>
> int
> foo (void)
> {
> return &i ? i : 0;
> }
>
> This ICEs with cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #4 from Jack Howarth ---
Created attachment 31452
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31452&action=edit
assembly file for gcc.dg/atomic/c11-atomic-exec-5.c -O0 on darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #3 from Jack Howarth ---
Created attachment 31451
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31451&action=edit
preprocessed source for gcc.dg/atomic/c11-atomic-exec-5.c -O0 on darwin12
-1000/gcc-4.9-20131216/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c
-B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libatomic/
-L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libatomic/.libs
-latomic -fno-diagnostics-show-caret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945
--- Comment #6 from Jan Hubicka ---
OK, somewhat confusing on the testcase above is that j is defined, but C++ FE
never consider it uses and thus never passes it to middle-end.
The problem is that C++ FE chose to first assemble alias:
#0 assembl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #6 from Dominique d'Humieres ---
> on x86_64-apple-darwin12. Can someone confirm that we have both support
> for floating-point exceptions and the required hook on darwin?
I cannot answer these questions.
> If so, I suspect we are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #18 from Jan Hubicka ---
> Just double-checked. And yes, unfortunately it's 100% reproducible.
Can not think of much of reason for this. How much off the index is? Just
slightly or is it completely random number?
Honza
>
> --
> Yo
1 - 100 of 127 matches
Mail list logo
