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
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
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=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
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=88993
--- Comment #1 from Richard W.M. Jones ---
Sorry, forgot the version. It's:
gcc-9.0.0-0.3.fc30.x86_64
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=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=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 #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=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
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=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
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
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=79546
Richard W.M. Jones changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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
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=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
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.
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)
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 #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:
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 #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
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 #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=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=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=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.
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=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
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 #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 .
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=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.
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 #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
40 matches
Mail list logo
