Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
markus@x4 /tmp % cat test.ii
template void declval();
template void forward();
template class D;
template
class D <_Functor(_Bound_args...)> {
template )>
void operator()(...
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=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
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
src % /var/tmp/gcc_test/usr/local/bin/g++ -w -r -nostdlib -o js -flto=4
-fprofile-use -fprofile-correction -march=native -fno
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=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
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
The cilk-plus tests are run even with --disable-libcilkrts.
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=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=59265
--- Comment #7 from Markus Trippelsdorf ---
Created attachment 31444
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31444&action=edit
testcase
% c++ -o nsLocalFileUnix.o -c -fprofile-use -fno-exceptions -std=gnu++0x -O2
nsLocalFileUnix.ii
/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #6 from Markus Trippelsdorf ---
It now segfaults in ipa_profile_generate_summary:
==9510==ERROR: AddressSanitizer: SEGV on unknown address 0x0028 (pc
0x0120aff0 sp 0x7fff4fe6add0 bp 0x606000210080 T0)
#0 0x120afef in i
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_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
lib/lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #16 from Markus Trippelsdorf ---
(In reply to H.J. Lu from comment #14)
> (In reply to H.J. Lu from comment #13)
> > Can you try bfd linker, hjl/linux/release/2.24.51.0.2, from
> >
> > https://sourceware.org/git/?p=binutils-gdb.git;a=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #12 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #10)
> I also saw in past problems with GNU-ld and comdat symbols becoming static
> while being comdat somewhere else. Do you use gold or ld? Can you perhaps
> try
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #11 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #8)
> OK, the unmangled name of symbol is:
> 0004c8c0 T
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodes
> FromListERNS_12ili
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #7 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #6)
> With -fno-fat-lto-objects we are also faster on SPEC build time and I think
> it should be the case in general. We produce considerably less code and
> most o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #2 from Markus Trippelsdorf ---
Here's a reduced testcase that works without any gcda file:
markus@x4 testcase % < test.ii
class A {
int m_fn1() const;
unsigned m_fn2() const;
};
class B {
public:
virtual void m_fn1();
};
class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505
--- Comment #12 from Markus Trippelsdorf ---
(In reply to David Kredba from comment #11)
> And I will try your binutils patch.
>
> Do you think that for 4.9.0 GCC release binutils will support
> slim-LTO-objects?
> LTO support for general use in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505
--- Comment #10 from Markus Trippelsdorf ---
Created attachment 31437
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31437&action=edit
binutils patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505
--- Comment #9 from Markus Trippelsdorf ---
(In reply to David Kredba from comment #8)
> Thank you Markus.
> Could you please tell me if binutils 2.24.51.0.2 are OK for this?
Unfortunately not out of the box. I use the attached simple patch for b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
Markus Trippelsdorf changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Markus Trippelsdorf from comment #3)
> > BTW it is interesting that gcc compiles the attached testcase faster
> > when using LTO.
> >
> > % ti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #3 from Markus Trippelsdorf ---
BTW it is interesting that gcc compiles the attached testcase faster
when using LTO.
% time g++ -flto=4 -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii
Function.ii
52.48s user 0.59s system 168
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #2 from Markus Trippelsdorf ---
markus@x4 llvm_build % cat BasicBlock.ii
struct A {};
namespace llvm {
struct B {};
template struct ilist_traits : B {};
template class ilist_iterator : A {
public:
ilist_iterator(int) {}
int opera
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
Building LLVM with LTO fails:
...
lib/libLLVMAsmParser.so: error: undefined reference to
'llvm::SymbolTableListTraits::transferNodesFromList(llvm::ilist_traits&,
llvm::ilist_iterator,
llvm::ilist_iterato
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #1 from Markus Trippelsdorf ---
Created attachment 31417
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31417&action=edit
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
Markus Trippelsdorf changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #16 from Markus Trippelsdorf ---
(In reply to Richard Biener from comment #15)
> Confirmed with 4.7.3 and 4.8.2. Seems to work on the trunk, worked with
> 4.6.4.
>
> Now it would be interesting to bisect what fixed this on the trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #14 from Markus Trippelsdorf ---
(In reply to David Kredba from comment #11)
> Delta died after more than 20 iterations. Started new delta. A little
> more reduced ii file uploaded.
Boost testcases are always fun ;-)
For testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #13 from Markus Trippelsdorf ---
Created attachment 31401
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31401&action=edit
Further reduced
Further reduced.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59201
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
,
||octoploid at yandex dot com
--- Comment #1 from Markus Trippelsdorf ---
Git blame points to r204516.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #10 from Markus Trippelsdorf ---
(In reply to David Kredba from comment #8)
> Going to attach ii file gzipped.
>
> What can I do next please?
You can now further reduce the single testfile by following the
"Simple ICE reduction" sec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Alexander Ivchenko from comment #4)
> This broke Android image build with trunk compiler (in addition to pr58585)..
Yes. Many C++ projects that use multiple inheritance don't compile ATM:
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #4 from Markus Trippelsdorf ---
I've tested this on my Gentoo box and cannot reproduce the issue
on trunk or gcc-4.8 branch.
So it is most likely already fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
--- Comment #12 from Markus Trippelsdorf ---
(In reply to Jakub Jelinek from comment #11)
> Can't reproduce this, with various snapshots from around the date of
> comments, or current trunk, neither on the larger nor shorter testcase.
Strange.
Ju
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733
--- Comment #8 from Markus Trippelsdorf ---
(In reply to Jakub Jelinek from comment #7)
> So, with r205392 now in, can this still be reproduced?
Unfortunately, yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003
--- Comment #7 from Markus Trippelsdorf ---
Created attachment 31378
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31378&action=edit
disassemled get_or_alloc_expr_for_name(tree_node*) bad
I've attached the disassembly of get_or_alloc_expr_f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003
--- Comment #6 from Markus Trippelsdorf ---
Created attachment 31377
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31377&action=edit
disassemled get_or_alloc_expr_for_name(tree_node*) good
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003
--- Comment #5 from Markus Trippelsdorf ---
Looks like gcc/tree-ssa-pre.c gets miscompiled:
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 8327]
0x00d156d3 in get_or_alloc_expr_for_name(tree_node*) [clone
.lto_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003
--- Comment #3 from Markus Trippelsdorf ---
Switching off misaligned_move_string_pro_epilogues for AMD "fixes"
the issue:
diff --git a/gcc/config/i386/x86-tune.def b/gcc/config/i386/x86-tune.def
index 4c13c3a0ec69..af58b3e1f77e 100644
--- a/gcc/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||wrong-code
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003
Markus Trippelsdorf changed:
What|Removed |Added
Summary|[4.9 Regression]|[4.9 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #17 from Markus Trippelsdorf ---
(In reply to H.J. Lu from comment #15)
> It may be a latent bug in amdfam10 scheduler. Before z.i.234r.sched2.
> there are
BTW -mtune=opteron is also affected.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #14 from Markus Trippelsdorf ---
Further reduced:
markus@x4 tmp % cat test.i
typedef struct {
int ctxlen;
long interhunkctxlen;
int flags;
long find_func;
void *find_func_priv;
int hunk_func;
} xdemitconf_t;
__attribute__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #8 from Markus Trippelsdorf ---
To reproduce the issue:
% git clone https://github.com/git/git
% cd git
% vim Makefile (add "-march=amdfam10" to CFLAGS
and point CC to gcc trunk)
% make
% ./git-blame Makefile (cra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #7 from Markus Trippelsdorf ---
Antoine Pelisse explained the control flow:
http://thread.gmane.org/gmane.comp.version-control.git/238629/focus=238631
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #2)
> 22209 static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
> 22210 xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
> 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #4 from Markus Trippelsdorf ---
git % cc -v -S -c -O2 -march=native blame.i
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/gcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr
--bind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #2 from Markus Trippelsdorf ---
22209 static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
22210 xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
22211 {
22212 xpparam_t xpp = {0};
22213 xdemitconf_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #1 from Markus Trippelsdorf ---
Created attachment 31346
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31346&action=edit
preprocessed file
Testcase.
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
Starting with r203886 git gets miscompiled on my machine.
For example:
% git blame gcc/tree-object-size.c
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59362
--- Comment #2 from Markus Trippelsdorf ---
Reduced:
markus@x4 tmp % cat test.i
char *a;
long int b;
void enc_format() {
b = __builtin_object_size(0, 0);
a = __builtin___stpcpy_chk(0, "", b);
b = __builtin_object_size(a, 0);
}
markus@x4 tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59362
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208
--- Comment #13 from Markus Trippelsdorf ---
(In reply to Richard Biener from comment #12)
> Fixed.
The testcase is missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694
--- Comment #8 from Markus Trippelsdorf ---
Ping.
All supported gcc versions are affected. Can someone
please have a look?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58893
--- Comment #5 from Markus Trippelsdorf ---
==3700== Conditional jump or move depends on uninitialised value(s)
==3700==at 0xDCB562: diagnostic_report_current_module(diagnostic_context*,
unsigned int) (diagnostic.c:506)
==3700==by 0x58DB6D
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712
--- Comment #10 from Markus Trippelsdorf ---
New issue, started with r204926, r204997:
==21374== Conditional jump or move depends on uninitialised value(s)
==21374==at 0x686F3A: set_storage_via_setmem(rtx_def*, rtx_def*, rtx_def*,
unsigned in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733
--- Comment #5 from Markus Trippelsdorf ---
FYI I'm running the latest binutils trunk:
GNU gold (GNU Binutils 2.24.51.20131121) 1.11
(I don't use -fuse-ld=gold normally, because one can
easily switch linkers globally, e.g.:
ln -f /usr/x86_64-pc-
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
More outfall from r205019:
markus@x4 tmp % cat test.ii
class A {
virtual void m_fn1();
};
class B;
class C : A {
public:
virtual B *m_fn2();
};
class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59201
Markus Trippelsdorf changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comm
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
markus@x4 src % cat test.ii
class A {
public:
virtual void m_fn1();
};
class B final : A {
~B();
virtual void m_fn2() { m_fn1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #20 from Markus Trippelsdorf ---
I've tested this further on my Gentoo box and it turned out
the many nontrivial packages that I've compiled failed
with "trap invalid opcode". From a QOI perspective this is a
nightmare. Not every user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #18 from Markus Trippelsdorf ---
(In reply to Jeffrey A. Law from comment #17)
> For the kernel case, note the qsort prototype and the non-null attribute.
> That explicitly states that the pointer arguments must not be null. Any
> co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
--- Comment #10 from Markus Trippelsdorf ---
(In reply to David Binderman from comment #9)
> (In reply to Markus Trippelsdorf from comment #8)
> > The following patch seems to fix the issue:
>
> Looks good to me.
>
> I think it needs to get int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #14 from Markus Trippelsdorf ---
The 'kernel' case passes a NULL pointer to qsort:
% < test.i
struct relocs {
int *offset;
};
static struct relocs a;
void qsort(void *, int) __attribute__((__nonnull__));
void die(int *p1, ...) {}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #13 from Markus Trippelsdorf ---
(In reply to Jeffrey A. Law from comment #11)
> Damn it. Tested the wrong compiler.
>
> The problem with your testcase Markus is you're simply not allowed to pass a
> null pointer to sprintf, memcpy a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #9 from Markus Trippelsdorf ---
(In reply to Jeffrey A. Law from comment #8)
> Should be fixed via recent commits. Specifically, we preserve the *0 for
> code that wants to catch the null pointer deref.
Well, if you had run the simpl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #7 from Markus Trippelsdorf ---
markus@x4 tmp % cat test.c
#include
#include
#include
#include
#include
static sigjmp_buf jmpbuf;
static void
sig_handler (int signo)
{
siglongjmp (jmpbuf, 1);
}
int
main (void)
{
char *p = N
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #6 from Markus Trippelsdorf ---
(In reply to Jeffrey A. Law from comment #5)
> I need testcases. "the kernel" or "x.org" isn't sufficient for a variety of
> reasons.
Every program that uses a custom sig_handler which only handles
SIG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59089
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712
octoploid at yandex dot com changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050
octoploid at yandex dot com changed:
What|Removed |Added
CC||congh at google dot com
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
markus@x4 tsan % cat test.ii
struct {
int trace[6];
} a;
void fn1() {
for (int i; i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040
--- Comment #6 from octoploid at yandex dot com ---
(In reply to octoploid from comment #5)
> (In reply to H.J. Lu from comment #2)
> > (In reply to Igor Zamyatin from comment #1)
> > > Dup of 58853
> >
> > There i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040
octoploid at yandex dot com changed:
What|Removed |Added
CC||octoploid at yandex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733
--- Comment #3 from octoploid at yandex dot com ---
The issue only happens when I use the 'gold' linker,
ld.bfd is fine. So maybe a binutils bug?
Honza?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
--- Comment #8 from octoploid at yandex dot com ---
The following patch seems to fix the issue:
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index f4cb72a9c2b0..b69d4d96176a 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -698,7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
octoploid at yandex dot com changed:
What|Removed |Added
Attachment #30920|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733
octoploid at yandex dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
--- Comment #6 from octoploid at yandex dot com ---
Program received signal SIGFPE, Arithmetic exception.
[Switching to process 21235]
0x0052531d in want_inline_self_recursive_call_p (edge=0x774412d8,
outer_node=0x77442260, peeling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712
--- Comment #7 from octoploid at yandex dot com ---
(In reply to Richard Biener from comment #6)
> Any issues remaining?
Yes. The second one.
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
% ../gcc/configure --enable-checking=release --disable-werror
--disable-multilib --enable-languages=c,c++
% make -j4 BOOT_CFLAGS="-march=n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
octoploid at yandex dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #12 from octoploid at yandex dot com ---
(In reply to Jakub Jelinek from comment #11)
> Created attachment 31153 [details]
> gcc49-pr58978.patch
>
> Supposedly this updated patch would fix even that?
Yes. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #10 from octoploid at yandex dot com ---
(In reply to octoploid from comment #9)
> With your patch applied I get this new ICE:
>
I've posted the wrong backtrace. Here's the correct one:
/var/tmp/gcc_test/usr/local/bi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #9 from octoploid at yandex dot com ---
With your patch applied I get this new ICE:
/home/markus/mozilla-central/js/src/jit/IonBuilder.cpp:6937:1: internal
compiler error: Segmentation fault
IonBuilder::jsop_getelem_typed(MDefinition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
octoploid at yandex dot com changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
markus@x4 tmp % cat test.ii
class A {
public:
int m_fn1();
};
class B {
public:
static B *m_fn1(int);
enum {
d = 8,
Sub,
Mul,
UDiv,
SDiv,
URem,
SRem,
Shl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58925
octoploid at yandex dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58925
--- Comment #6 from octoploid at yandex dot com ---
(In reply to Balaji V. Iyer from comment #5)
> Hi,
>I just submitted a patch to the gcc-patches mailing list. Can you try
> that out?
Our mails just crossed and I think your patc
1 - 100 of 111 matches
Mail list logo
