https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
--- Comment #3 from Richard W.M. Jones ---
(Edit comment 2: To be clear, that wasn't the thread where the
segfault occurred, which was some golang thread, that was the
thread that was unmapping the memory at the same time. Using
nodelete avoids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
--- Comment #2 from Richard W.M. Jones ---
This was the stack trace of the crashing thread with gcc-go:
Thread 7 (Thread 0x7ff5c1af3a40 (LWP 2819340)):
#0 0x7ff5c24d67cb in __GI_munmap () at
../sysdeps/unix/syscall-template.S:117
#1 0x000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
--- Comment #1 from Richard W.M. Jones ---
gcc 14.0.1-0.13.fc40 => crashes
golang-bin-1.22.2-1.fc40.x86_64 => works
I also checked this by stracing the linking process and
seeing -Wl,-z,nodelete is being used by golang, but not by
gcc-go.
IRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: rjones at redhat dot com
Target Milestone: ---
I was chasing a crash in nbdkit-golang-plugin
(https://gitlab.com/nbdkit/nbdkit/-/tree/master/plugins/golang?ref_type=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
Richard W.M. Jones changed:
What|Removed |Added
CC||rjones at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
--- Comment #1 from Richard W.M. Jones ---
Nice reproducer!
Here's the original thread where the bug was reported when compiling qemu on
Fedora Rawhide for armv7:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/threa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233
--- Comment #5 from Richard W.M. Jones ---
(In reply to David Malcolm from comment #4)
> (In reply to Richard W.M. Jones from comment #2)
> > I think since this seems to be LTO-related, you probably do need
> > to use LTO CFLAGS in the initial .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233
--- Comment #2 from Richard W.M. Jones ---
I think since this seems to be LTO-related, you probably do need
to use LTO CFLAGS in the initial ./configure step. My actual CFLAGS
were:
export CFLAGS="$(rpm --eval '%{optflags}')"
export CXXFLAGS="
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233
--- Comment #1 from Richard W.M. Jones ---
perf top shows:
36.63% lto1 [.] shortest_paths::shortest_paths
which it pretty much stuck permanently at 30-50% CPU. The
machine has plenty of free memory and is not
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
This is not so simple to reproduce. It starts with checking out:
https://github.com/libguestfs/libguestfs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99260
--- Comment #6 from Richard W.M. Jones ---
That's excellent news, thanks. We'll get around to trying this
when GCC 12 appears in Rawhide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99716
--- Comment #3 from Richard W.M. Jones ---
FYI the original code is:
https://github.com/libguestfs/libguestfs/blob/e0a11061035d47b118c95706240bcc17fd576edc/tests/mount-local/test-parallel-mount-local.c#L299-L335
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
This seems pretty bogus to me:
#include
#include
int
main ()
{
int i;
for (i = 0; i < 2; ++i) {
FILE *fp = fopen ("/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
--- Comment #12 from Richard W.M. Jones ---
There are quite a lot of these - I will try removing them
when we get the updated GCC in Fedora.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
--- Comment #10 from Richard W.M. Jones ---
Great stuff, I'll give this a go when GCC is updated
in Fedora Rawhide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196
--- Comment #3 from Richard W.M. Jones ---
Note if errcode == 0 then error does NOT exit :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
--- Comment #4 from Richard W.M. Jones ---
And another:
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/daemon/debug.c#L115
debug.c: In function 'debug_help':
debug.c:129:9: error: 'r' should have been deal
erity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/daemon/tar.c#L108
tar.c: In fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
--- Comment #3 from Richard W.M. Jones ---
This seems to be the same thing at a different place in the code:
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/df/main.c#L404
CC virt_df-main.o
main.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
Richard W.M. Jones changed:
What|Removed |Added
Version|unknown |11.0
--- Comment #2 from Richard W.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
--- Comment #1 from Richard W.M. Jones ---
Created attachment 50232
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50232&action=edit
preprocessed source (xz compressed)
tion]"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
https://github.
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
I'm not certain this is really a bug, but I
y: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
This is a very reduced example from some real code where we are using -Werror
-Wstack-usage=5000.
We want most functions to have limited stack usage, but in some cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
--- Comment #6 from Richard W.M. Jones ---
I switched the warning off in libguestfs, but before it was
switched off I got all these warnings (errors in fact because
we use -Werror in development builds).
qemuopts.c: In function 'qemuopts_to_conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
--- Comment #1 from Richard W.M. Jones ---
Sorry, forgot the version. It's:
gcc-9.0.0-0.3.fc30.x86_64
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
-Wformat-overflow=2 is the default when using gnulib manywarnings.m4, and
so is used by a bunch of GNU projects. I've found with GCC 9 it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270
--- Comment #4 from Richard W.M. Jones ---
FWIW I was testing:
gcc (FreeBSD Ports Collection) 7.3.0
$ cat test.c
#include
int
main (int argc, char *argv[])
{
printf ("%m\n");
return 0;
}
$ gcc -Wformat test.c
(no warnings)
$ gcc -Wformat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142
--- Comment #6 from Richard W.M. Jones ---
The paste removed the "di" from "diff" but the patch is otherwise
as posted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142
--- Comment #5 from Richard W.M. Jones ---
I'm not the original reporter but you could give us a few *minutes*
at least to resolve these questions by just asking.
The patch in question is this one. (I didn't write it, it was written
by David th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142
--- Comment #2 from Richard W.M. Jones ---
The build log is here:
https://fedorapeople.org/groups/risc-v/logs/gcc-7.3.1-5.2.riscv64.fc28.src.rpm/build.log
Grep the log for "../configure" to see configure line(s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79546
Richard W.M. Jones changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
#include
#include
int f (size_t len);
int
main (int argc, char *argv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78665
--- Comment #4 from Richard W.M. Jones ---
Created attachment 40363
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40363&action=edit
handle.i
Preprocessed source. The full command to produce this was:
gcc -DHAVE_CONFIG_H -I. -I.. -I../gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78665
--- Comment #2 from Richard W.M. Jones ---
The code which calculates seg_len is surely quite interesting in that case:
size_t seg_len = block_len (h, blkoff, &used);
if (seg_len <= 4 || (seg_len & 3) != 0) {
The block_len function w
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
size_t seg_len;
//...
if (seg_len <= 4 || (seg_len & 3) != 0) {
gives:
hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63509
Richard W.M. Jones changed:
What|Removed |Added
CC||rjones at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52560
--- Comment #3 from Richard W.M. Jones 2012-03-12
16:30:45 UTC ---
I see that this is actually a bug in our code. I pushed
the following fix to libguestfs:
https://github.com/libguestfs/libguestfs/commit/d66dd2260c724bdfe57a8595aac37c8e9173cee5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52560
Bug #: 52560
Summary: if (r == -1) causes 'assuming signed overflow does not
occur when simplifying conditional to constant'
Classification: Unclassified
Product: gcc
Version: 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48022
--- Comment #1 from rjones at redhat dot com
2011-03-07 16:51:14 UTC ---
Report on Fedora devel mailing list:
http://lists.fedoraproject.org/pipermail/devel/2011-March/thread.html#149342
40 matches
Mail list logo
