* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
@ 2013-11-11 22:50 ` law at redhat dot com
2013-11-12 16:00 ` marxin.liska at gmail dot com
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: law at redhat dot com @ 2013-11-11 22:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #2 from Jeffrey A. Law <law at redhat dot com> ---
I need a compilable/complete testcase.
If a program is faulting with -fisolate-erroneous-paths, then that program is
faulty in one way or another. It's dereferencing a null pointer, pass a null
argument in a situation where the argument must be non-null, or returning a
null pointer from a function declared as returning non-null.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
2013-11-11 22:50 ` [Bug c++/59083] " law at redhat dot com
@ 2013-11-12 16:00 ` marxin.liska at gmail dot com
2013-11-12 16:17 ` octoploid at yandex dot com
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: marxin.liska at gmail dot com @ 2013-11-12 16:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #3 from Martin Liška <marxin.liska at gmail dot com> ---
I've seen the same problem also in Inkscape. I will try to create a testcase.
Would it be possible Jeffrey to build one of these programs?
Thanks,
Martin
>From gcc-bugs-return-434368-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 12 16:03:50 2013
Return-Path: <gcc-bugs-return-434368-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31154 invoked by alias); 12 Nov 2013 16:03:50 -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 31093 invoked by uid 48); 12 Nov 2013 16:03:46 -0000
From: "paulo@matos-sorge.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008
Date: Tue, 12 Nov 2013 16:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paulo@matos-sorge.com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58862-4-gTmf94jFhE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58862-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58862-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: 2013-11/txt/msg01145.txt.bz2
Content-length: 140
http://gcc.gnu.org/bugzilla/show_bug.cgi?idX862
--- Comment #20 from Paulo J. Matos <paulo@matos-sorge.com> ---
Thanks for fixing this.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
2013-11-11 22:50 ` [Bug c++/59083] " law at redhat dot com
2013-11-12 16:00 ` marxin.liska at gmail dot com
@ 2013-11-12 16:17 ` octoploid at yandex dot com
2013-11-12 16:19 ` law at redhat dot com
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: octoploid at yandex dot com @ 2013-11-12 16:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
Markus Trippelsdorf <octoploid at yandex dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |octoploid at yandex dot com
--- Comment #4 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(In reply to Jeffrey A. Law from comment #2)
> I need a compilable/complete testcase.
>
> If a program is faulting with -fisolate-erroneous-paths, then that program
> is faulty in one way or another. It's dereferencing a null pointer, pass a
> null argument in a situation where the argument must be non-null, or
> returning a null pointer from a function declared as returning non-null.
I'm seeing this also quite often. Xorg fails to start when
compiled with current gcc, the Linux kernel doesn't build, because
relocs (build during the kernel build) fails with illegal instruction,
etc..
So tbe -fisolate-erroneous-paths patch should be reverted IMHO.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (2 preceding siblings ...)
2013-11-12 16:17 ` octoploid at yandex dot com
@ 2013-11-12 16:19 ` law at redhat dot com
2013-11-12 16:26 ` octoploid at yandex dot com
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: law at redhat dot com @ 2013-11-12 16:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
I need testcases. "the kernel" or "x.org" isn't sufficient for a variety of
reasons.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (3 preceding siblings ...)
2013-11-12 16:19 ` law at redhat dot com
@ 2013-11-12 16:26 ` octoploid at yandex dot com
2013-11-12 16:39 ` octoploid at yandex dot com
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: octoploid at yandex dot com @ 2013-11-12 16:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #6 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(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
SIGSEGV will fail.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (4 preceding siblings ...)
2013-11-12 16:26 ` octoploid at yandex dot com
@ 2013-11-12 16:39 ` octoploid at yandex dot com
2013-11-12 23:10 ` law at redhat dot com
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: octoploid at yandex dot com @ 2013-11-12 16:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #7 from Markus Trippelsdorf <octoploid at yandex dot com> ---
markus@x4 tmp % cat test.c
#include <setjmp.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
static sigjmp_buf jmpbuf;
static void
sig_handler (int signo)
{
siglongjmp (jmpbuf, 1);
}
int
main (void)
{
char *p = NULL;
volatile int ret = 0;
struct sigaction sa;
sa.sa_handler = sig_handler;
sigemptyset (&sa.sa_mask);
sa.sa_flags = SA_SIGINFO;
if (sigaction (SIGSEGV, &sa, 0))
{
perror ("installing SIGSEGV handler\n");
exit (1);
}
puts ("Attempting to sprintf to null ptr");
if (setjmp (jmpbuf))
{
puts ("Exiting main...");
return ret;
}
sprintf (p, "This should segv\n");
return 1;
}
markus@x4 tmp % gcc -O2 test.c && ./a.out
Attempting to sprintf to null ptr
[1] 28519 illegal hardware instruction ./a.out
markus@x4 tmp % gcc -fno-isolate-erroneous-paths -O2 test.c && ./a.out
Attempting to sprintf to null ptr
Exiting main...
markus@x4 tmp %
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (5 preceding siblings ...)
2013-11-12 16:39 ` octoploid at yandex dot com
@ 2013-11-12 23:10 ` law at redhat dot com
2013-11-13 5:17 ` octoploid at yandex dot com
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: law at redhat dot com @ 2013-11-12 23:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
Should be fixed via recent commits. Specifically, we preserve the *0 for code
that wants to catch the null pointer deref.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (6 preceding siblings ...)
2013-11-12 23:10 ` law at redhat dot com
@ 2013-11-13 5:17 ` octoploid at yandex dot com
2013-11-13 5:30 ` law at redhat dot com
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: octoploid at yandex dot com @ 2013-11-13 5:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #9 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(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 simple glibc testcase that I've posted above,
you would have found out that your recent commits don't fix this issue.
It's obvious, not only from the amount of churn, that fisolate-erroneous-paths
shouldn't be enabled by default at -O2. The very few users you would like
SIGSEGV
to be transformed to SIGILL by the compiler should set this option explicitly.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (7 preceding siblings ...)
2013-11-13 5:17 ` octoploid at yandex dot com
@ 2013-11-13 5:30 ` law at redhat dot com
2013-11-13 7:34 ` law at redhat dot com
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: law at redhat dot com @ 2013-11-13 5:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
I ran the testcase you sent. It worked fine for me.
THe problems we're having are within the realm of normal development and they
will be resolved one way or another.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (8 preceding siblings ...)
2013-11-13 5:30 ` law at redhat dot com
@ 2013-11-13 7:34 ` law at redhat dot com
2013-11-13 7:42 ` law at redhat dot com
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: law at redhat dot com @ 2013-11-13 7:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---
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 and a variety of other functions. Once you
execute code which attempts that, you've walked into the realm of undefined
behaviour.
Once you cross that boundary the compiler is allowed to do these kinds of
transformations. Your testcode is fundamentally flawed in that it relies upon
undefined behaviour.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (9 preceding siblings ...)
2013-11-13 7:34 ` law at redhat dot com
@ 2013-11-13 7:42 ` law at redhat dot com
2013-11-13 7:50 ` octoploid at yandex dot com
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: law at redhat dot com @ 2013-11-13 7:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
I'll note further, that an implementation of sprintf, memcpy, etc could check
for a NULL pointer internally and raise a trap on their own rather than
dereferencing the invalid pointer and still be a conforming implementation.
In summary, you can't make the assumption that you'll actually get a
segfault/bus error like your code wants to do.
Contrast that to an explicit *0 = <whatever> which might appear in user code.
While executing that code still results in undefined behaviour, one can easily
make an argument from a QOI standpoint that we should still allow the memory
dereference to occur to generate the SIGBUS/SIGSEGV.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (10 preceding siblings ...)
2013-11-13 7:42 ` law at redhat dot com
@ 2013-11-13 7:50 ` octoploid at yandex dot com
2013-11-13 9:08 ` octoploid at yandex dot com
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: octoploid at yandex dot com @ 2013-11-13 7:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #13 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(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 and a variety of other functions. Once you
> execute code which attempts that, you've walked into the realm of undefined
> behaviour.
>
> Once you cross that boundary the compiler is allowed to do these kinds of
> transformations. Your testcode is fundamentally flawed in that it relies
> upon undefined behaviour.
Understood. But the problem is that "the kernel" and "x.org" still fail.
I will try to come up with testcases for those two and see if it's also
caused by the same undefined behavior.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (11 preceding siblings ...)
2013-11-13 7:50 ` octoploid at yandex dot com
@ 2013-11-13 9:08 ` octoploid at yandex dot com
2013-11-13 15:47 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: octoploid at yandex dot com @ 2013-11-13 9:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #14 from Markus Trippelsdorf <octoploid at yandex dot com> ---
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, ...) {}
void sort_relocs(struct relocs *p1) { qsort(p1->offset, 0); }
int main() {
sort_relocs(&a);
return 0;
}
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (12 preceding siblings ...)
2013-11-13 9:08 ` octoploid at yandex dot com
@ 2013-11-13 15:47 ` rguenth at gcc dot gnu.org
2013-11-13 16:50 ` law at redhat dot com
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-11-13 15:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that technically invalid C programs still may be "reasonable". For
example
writing *0 = 1; and catching that via sigsetjmp/siglongjmp and a signal handler
is possible but of course invokes undefined behavior according to the C
standard.
But yes, if now random "POSIX" programs start failing then that's bad. Does
-fnon-call-exceptions exeption handling on SJLJ targets still work? (I suppose
we lower to SJLJ only after RTL expansion or we at least still have EH edges
around).
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (13 preceding siblings ...)
2013-11-13 15:47 ` rguenth at gcc dot gnu.org
@ 2013-11-13 16:50 ` law at redhat dot com
2013-11-13 17:04 ` octoploid at yandex dot com
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: law at redhat dot com @ 2013-11-13 16:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #17 from Jeffrey A. Law <law at redhat dot com> ---
Markus,
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 code which
then passes null for those arguments has stepped into the realm of undefined
behaviour.
Prior to CCP2 we have:
main ()
{
int * _3;
;; basic block 2, loop depth 0, count 0, freq 10000, maybe hot
;; prev block 0, next block 1, flags: (NEW, REACHABLE)
;; pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
_3 = a.offset;
qsort (_3, 0);
return 0;
;; succ: EXIT [100.0%]
}
a.offset gets folded to zero by CCP2 resulting in:
main ()
{
;; basic block 2, loop depth 0, count 0, freq 10000, maybe hot
;; prev block 0, next block 1, flags: (NEW, REACHABLE)
;; pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
qsort (0B, 0);
return 0;
;; succ: EXIT [100.0%]
}
Note we're passing NULL as the first argument to qsort, which has a declaration
saying that none of its pointer arguments can be NULL.
Note we're able to fold a.offset to zero because we can see "a"'s initializer.
AFAICT the code is doing exactly what is expected.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (14 preceding siblings ...)
2013-11-13 16:50 ` law at redhat dot com
@ 2013-11-13 17:04 ` octoploid at yandex dot com
2013-11-13 17:10 ` law at redhat dot com
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: octoploid at yandex dot com @ 2013-11-13 17:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #18 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(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
> code which then passes null for those arguments has stepped into the realm
> of undefined behaviour.
Yes, I've already posted a patch to the LKML to fix this issue.
Now the question is if one could also find *real* bugs with the help of
-fisolate-erroneous-path and if the inconvenience of breaking otherwise
"harmless" programs is counterbalanced by this ability?
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (15 preceding siblings ...)
2013-11-13 17:04 ` octoploid at yandex dot com
@ 2013-11-13 17:10 ` law at redhat dot com
2013-11-18 12:03 ` octoploid at yandex dot com
2013-12-18 13:08 ` trippels at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: law at redhat dot com @ 2013-11-13 17:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #19 from Jeffrey A. Law <law at redhat dot com> ---
Yes, the glibc guys have already found real bugs that they've fixed.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (16 preceding siblings ...)
2013-11-13 17:10 ` law at redhat dot com
@ 2013-11-18 12:03 ` octoploid at yandex dot com
2013-12-18 13:08 ` trippels at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: octoploid at yandex dot com @ 2013-11-18 12:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #20 from Markus Trippelsdorf <octoploid at yandex dot com> ---
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 of the compiler is a developer, e.g.
as a Gentoo user I don't care deeply about most ebuilds, I just
want them to compile without fuss. And for this I need a compiler
that is as permissive as possible.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
2013-11-11 22:04 [Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate marxin.liska at gmail dot com
` (17 preceding siblings ...)
2013-11-18 12:03 ` octoploid at yandex dot com
@ 2013-12-18 13:08 ` trippels at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: trippels at gcc dot gnu.org @ 2013-12-18 13:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
CC| |trippels at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #21 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Jeff patch to split up the erroneous path optimization into two pieces
(r205689) fixes the issue.
^ permalink raw reply [flat|nested] 20+ messages in thread