ONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim at meyering dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
I note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107 is an ICE at the
same file:line, but for fortran. This is for C and causes any
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
First clue: the following (derived from a gnulib test) segfaults with -O1, but
not with -O0. I build gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156
--- Comment #3 from jim at meyering dot net ---
Hi Andrew, thank you for the prompt investigation.
I'm probably just being dense, but how can the compiler ever generate code for
that null_ptr function that results in -1?
Your comment show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156
--- Comment #5 from jim at meyering dot net ---
(In reply to Andrew Pinski from comment #4)
> (In reply to jim from comment #3)
> > Hi Andrew, thank you for the prompt investigation.
> > I'm probably just being dense, but
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
Created attachment 47808
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47808&action=edit
derived from gnulib's lib/ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56210
Bug #: 56210
Summary: invalid -Warray-bounds warning
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56210
--- Comment #1 from jim at meyering dot net 2013-02-05 00:26:50 UTC ---
Created attachment 29352
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29352
preprocessed k.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56210
--- Comment #5 from jim at meyering dot net 2013-02-05 17:00:47 UTC ---
Hi Jakub,
Exactly. The lack of const there was a bug, and I fixed that before reporting
the gcc behavior that had surprised me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54409
Bug #: 54409
Summary: internal compiler error: in remap_predicate, at
ipa-inline-analysis.c:2710
Classification: Unclassified
Product: gcc
Version: unknown
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54409
--- Comment #1 from jim at meyering dot net 2012-08-29 14:40:35 UTC ---
Created attachment 28101
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28101
connect.i from heavily pared-down connect.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54409
jim at meyering dot net changed:
What|Removed |Added
Version|unknown |4.8.0
--- Comment #2 from jim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493
jim at meyering dot net changed:
What|Removed |Added
CC||jim at meyering dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52560
--- Comment #1 from jim at meyering dot net 2012-03-12 12:30:20 UTC ---
Created attachment 26877
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26877
50-line reproducer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053
Bug #: 53053
Summary: code-gen (missing loop-termination test) bug
introduced between April 18 and April 19th
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053
--- Comment #2 from jim at meyering dot net 2012-04-20 10:28:35 UTC ---
when I add printf ("%u\n", i); before the end of the loop, it prints values up
to about 128K before segfaulting.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053
--- Comment #3 from jim at meyering dot net 2012-04-20 10:43:28 UTC ---
Created attachment 27201
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27201
preprocessed source
PS, gcc was built via this:
CC=/usr/bin/gcc ./configure --pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53053
--- Comment #5 from jim at meyering dot net 2012-04-20 11:23:21 UTC ---
Oh! I'm not used to seeing this sort of transformation (invalid code ->
effectively-skipped loop-termination test), but it certainly makes sense,
given an inval
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p)
It all started with a new unwarranted wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86528
--- Comment #1 from jim at meyering dot net ---
I have just noticed that the two /p/... filename dates are wrong. The real
pass/fail bracketing dates are listed below: July 7 works, July 11 fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80528
jim at meyering dot net changed:
What|Removed |Added
CC||jim at meyering dot net
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
Created attachment 43686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43686&
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
While attempting to emit a diagnostic following this warning,
x.ii:11:3: warning: access declarations are deprecated in favou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70538
--- Comment #1 from jim at meyering dot net ---
FYI, that same ICE strikes also with gcc-4.9.3, gcc-5.1.0 and gcc-5.3.0 when
using -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70538
--- Comment #2 from jim at meyering dot net ---
Small correction:
It's not "while attempting to emit...", but rather "after emitting that
warning".
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
The following gets an ICE with gcc 7 (latest from git at git-svn-id:
svn+ssh://gcc.gnu.org/svn/gcc/trunk@247659
138bc75d-0d04-0410-961f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80659
--- Comment #4 from jim at meyering dot net ---
Created attachment 41351
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41351&action=edit
process.i.xz
Thanks for the quick work.
Here's the original process.i file.
Had to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80659
--- Comment #5 from jim at meyering dot net ---
FYI, for a little more context around how I found it, here's the thread on
emacs-devel:
https://lists.gnu.org/archive/html/emacs-devel/2017-05/msg00182.html
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
Please consider adding a __noextension__(...) operator.
If we had a __noextension__(...) operator to counteract the effect of a
preceding __extension__(...), I could write this in glibc&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72828
jim at meyering dot net changed:
What|Removed |Added
CC||jim at meyering dot net
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
Normally, adding a comment like /* FALLTHRU */ works fine to mark a switch case
that is intended to fall through. But if a cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817
--- Comment #2 from jim at meyering dot net ---
Oops. That must have been the "worked-around" version.
Swap the #undef and fallthrough comment to repro:
int
foo (int x)
{
switch (x)
{
case 1:
x = 3;
/* fallthrough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817
--- Comment #7 from jim at meyering dot net ---
Thanks for investigating.
I already pushed a workaround for gnulib's vasnprintf problem
(http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=e63f5eb55570a1ea3e51ce47df33689785e085c1).
I may
tatus: UNCONFIRMED
Severity: blocker
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
Since the Oct 1 commit, 7e3a76de7c496449b187c2688d958631cf21a944,
coreutils's wc.c wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67861
--- Comment #3 from jim at meyering dot net ---
Created attachment 36452
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36452&action=edit
wc.i
Attaching wc.i:
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Thanks for tending and continually improving gcc.
I see some surprising new warnings when using built-from-git (an hour ago) gcc
to compile coreutils. Here is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66921
jim at meyering dot net changed:
What|Removed |Added
CC||jim at meyering dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
jim at meyering dot net changed:
What|Removed |Added
CC||jim at meyering dot net
0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim at meyering dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
--- Comment #1 from jim at meyering dot net 2010-06-06 13:41 ---
Created an attachment (id=20851)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20851&action=view)
gengtype: don't test undefined value after vasprintf failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
--- Comment #4 from jim at meyering dot net 2010-06-07 18:24 ---
Good! I see that there's already a patch to deal with all of the unchecked
asprintf calls, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
ent: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim at meyering dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44806
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
Summary: -Wstrict-overflow gives obviously unwarranted warning
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49262
Summary: 3-yr-old infinite loop in dwarf2out.c
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49426
Summary: unwarranted warning from -Wsign-compare
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Target Milestone: ---
Here's the invalid warning.
The buffer's size is obviously not 6. It is AT LEAST 6.
$ gcc -Wformat-truncation=2 -O2 -c strerror_r.c
strerror_r.c: In function ‘
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97817
--- Comment #1 from jim at meyering dot net ---
I confirmed this happens both with the very latest built from git: gcc version
11.0.0 20201113 (experimental) (GCC), and Fedora 32's gcc version 10.2.1
20201016 (Red Hat 10.2.1-6) (GCC).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97817
--- Comment #4 from jim at meyering dot net ---
Thanks for explaining. It would be nice if the diagnostic were to say something
along the lines of "... writing into a region whose size may be as low as N".
Given the wording of t
48 matches
Mail list logo
