[Bug c/97817] -Wformat-truncation=2 elicits invalid warning
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 the current diagnostic, I initially went looking for a caller whose buffer really did have length 2 (in the original it was 2, not 6). It's only when I finally noticed that initial "if" block in the implementation that I understood where the "2" (6 in this example) was coming from.
[Bug c/97817] -Wformat-truncation=2 elicits invalid warning
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).
[Bug c/97817] New: -Wformat-truncation=2 elicits invalid warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97817
Bug ID: 97817
Summary: -Wformat-truncation=2 elicits invalid warning
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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 ‘strerror_r’:
strerror_r.c:12:35: warning: ‘Unknown error ’ directive output truncated
writing 14 bytes into a region of size 6 [-Wformat-truncation=]
12 | snprintf (buf, buflen, "Unknown error %d", errnum);
| ~~^~~~
strerror_r.c:12:5: note: ‘snprintf’ output between 16 and 26 bytes into a
destination of size 6
12 | snprintf (buf, buflen, "Unknown error %d", errnum);
| ^~
Here's the reduced test case (from gnulib's strerror.c):
$ cat strerror_r.c
#define size_t unsigned long long
extern int snprintf (char *__restrict __s, size_t __maxlen,
const char *__restrict __format, ...)
__attribute__ ((__format__ (__printf__, 3, 4)));
extern int __xpg_strerror_r (int errnum, char *buf, size_t buflen);
int strerror_r (int errnum, char *buf, size_t buflen)
{
if (buflen <= 5)
return 9;
int ret = __xpg_strerror_r (errnum, buf, buflen);
if (ret == 1 && !*buf)
snprintf (buf, buflen, "Unknown error %d", errnum);
return ret;
}
[Bug c/97157] New: -Wduplicated-branches: C ICE in hash_operand, at fold-const.c:3768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97157
Bug ID: 97157
Summary: -Wduplicated-branches: C ICE in hash_operand, at
fold-const.c:3768
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
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 tool using
gnulib's quotearg.c to fail to compile.
I built gcc from git today; git desc prints this:
basepoints/gcc-11-3342-g27edc6c3e29
$ cat quotearg.c
static int f (int x)
{
switch (9)
{
default:
do
{
if (1)
break;
else
if (0)
switch (1) { default: ; }
}
while (1);
}
return f (x);
}
$ gcc -Wduplicated-branches -c quotearg.c
quotearg.c: In function ‘f’:
quotearg.c:17:1: internal compiler error: in hash_operand, at fold-const.c:3768
17 | }
| ^
0x5e9431 operand_compare::hash_operand(tree_node const*, inchash::hash&,
unsigned int)
/home/j/w/co/gcc/gcc/fold-const.c:3768
0x85a876 operand_compare::hash_operand(tree_node const*, inchash::hash&,
unsigned int)
/home/j/w/co/gcc/gcc/fold-const.c:3858
0x85a876 operand_compare::hash_operand(tree_node const*, inchash::hash&,
unsigned int)
/home/j/w/co/gcc/gcc/fold-const.c:3858
0x6f8997 do_warn_duplicated_branches
/home/j/w/co/gcc/gcc/c-family/c-warn.c:2768
0x6f8997 do_warn_duplicated_branches_r(tree_node**, int*, void*)
/home/j/w/co/gcc/gcc/c-family/c-warn.c:2790
0xd68bfa walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/j/w/co/gcc/gcc/tree.c:12001
0xd68f29 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/j/w/co/gcc/gcc/tree.c:12106
0xd68d4a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/j/w/co/gcc/gcc/tree.c:12336
0xd68f29 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/j/w/co/gcc/gcc/tree.c:12106
0xd6ad9a walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
/home/j/w/co/gcc/gcc/tree.c:12362
0x6cf53d c_genericize(tree_node*)
/home/j/w/co/gcc/gcc/c-family/c-gimplify.c:537
0x630380 finish_function(unsigned int)
/home/j/w/co/gcc/gcc/c/c-decl.c:10219
0x68635f c_parser_declaration_or_fndef
/home/j/w/co/gcc/gcc/c/c-parser.c:2562
0x68d043 c_parser_external_declaration
/home/j/w/co/gcc/gcc/c/c-parser.c:1777
0x68db39 c_parser_translation_unit
/home/j/w/co/gcc/gcc/c/c-parser.c:1650
0x68db39 c_parse_file()
/home/j/w/co/gcc/gcc/c/c-parser.c:21821
0x6d9c2d c_common_parse_file()
/home/j/w/co/gcc/gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug other/93644] New: -Wreturn-local-addr July regression: new false-positive warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 Bug ID: 93644 Summary: -Wreturn-local-addr July regression: new false-positive warning Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal 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=edit derived from gnulib's lib/careadlinkat.c Using -Wreturn-local-addr can now evoke this false positive: $ gcc -c -O2 -Wreturn-local-addr k.c k.c: In function 'careadlinkat': cc1: warning: function may return address of local variable [-Wreturn-local-addr] k.c:24:8: note: declared here 24 | char stack_buf[1024]; |^ I was able to easily narrow down that this behavior changed on gcc/git master built from: 2019-07-19 (no warning) to 2019-07-23 (warning emitted). -- I was surprised not to be able to convince the compiler that the code is ok OR even to suppress the warning. Per discussion in the thread at https://lists.gnu.org/r/coreutils/2020-02/msg6.html, I first tried this: >> Would an `assure (buf != stack_buf)` before the `return buf` >> indicate that constraint to gcc with minimal runtime overhead? I then tried to suppress that warning in the affected file by adding these lines: /* Without this pragma, gcc 10.0.1 20200205 reports that the "function may return address of local variable". */ # pragma GCC diagnostic ignored "-Wreturn-local-addr" But, surprisingly, even with that pragma, the warning was still emitted. I ended up having to disable this normally-high-signal warning for all of coreutils/lib. The attached file is derived from gnulib's lib/careadlinkat.c.
[Bug tree-optimization/93156] abused nonnull attribute evokes new segfault in gcc 10 since Nov 4 commit, 0fb958ab8aa
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 how can the compiler ever generate code > > for that null_ptr function that results in -1? > > It is not that null_ptr can result in -1 directly but rather if it is > inlined and then later on passed to a non-null function, it will change it > to be the non-null case. Let me rephrase: how can a transformation that makes it look like null_ptr returned -1 be valid?
[Bug tree-optimization/93156] abused nonnull attribute evokes new segfault in gcc 10 since Nov 4 commit, 0fb958ab8aa
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 shows you know this already, but for others, here's a comment from the sources in gnulib: /* If you want to know why this always returns NULL, read https://en.wikipedia.org/wiki/Quadratic_residue#Prime_power_modulus . */ Note that at least some versions of canonicalize_file_name *can* take a NULL argument, so the use of the nonnull attribute in that declaration is wrong. I did notice that removing it in this reproducer and in the original makes the problem go away.
[Bug tree-optimization/93156] New: abused nonnull attribute evokes new segfault in gcc 10 since Nov 4 commit, 0fb958ab8aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156
Bug ID: 93156
Summary: abused nonnull attribute evokes new segfault in gcc 10
since Nov 4 commit, 0fb958ab8aa
Product: gcc
Version: 10.0
Status: UNCONFIRMED
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 from master ~daily, so could conveniently "bisect" to
around Nov 4 or 5. Before then, this program would exit zero. Since then, it
segfaults.
$ gcc -O0 -ggdb3 k.c && ./a.out; echo $?
0
$ gcc -O1 -ggdb3 k.c && ./a.out
zsh: segmentation fault (core dumped) ./a.out
[Exit 139 (SEGV)]
$ gdb a.out
Reading symbols from a.out...
(gdb) r
Starting program: /home/j/w/co/sed/gnulib-tests/a.out
warning: Loadable section ".note.gnu.property" outside of ELF segments
Program received signal SIGSEGV, Segmentation fault.
0x77e15107 in __GI___realpath (name=name@entry=0x
,
resolved=resolved@entry=0x0) at canonicalize.c:50
50if (name == NULL)
$ cat k.c
extern char *canonicalize_file_name (const char *__name) __attribute__
((__nonnull__ (1)));
extern int rand (void);
/* Return NULL.
Usual compilers are not able to infer something about the return value. */
static void *
null_ptr (void)
{
unsigned int x = rand ();
unsigned int y = x * x;
if (y & 2)
return (void *) -1;
else
return (void *) 0;
}
int
main (void)
{
return !!canonicalize_file_name (null_ptr ());
}
I bisected to this commit:
--
commit 0fb958ab8aadda977333cd8a5fbd349babd2807c
Author: aldyh
Date: Mon Nov 4 22:05:26 2019 +
Remove handle_pointers argument from all the vrp_val*{min,max} functions.
Always
assume pointers should be handled.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@277796
138bc75d-0d04-0410-961f-82ee72b054a4
gcc/ChangeLog | 23 +++
gcc/tree-vrp.c | 70 --
gcc/tree-vrp.h | 10 -
[Bug c/80528] reimplement gnulib's "useless-if-before-free" script as a compiler warning
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 --- Comment #4 from jim at meyering dot net --- Thanks for considering the addition. IME, the vast majority (probably "all I've seen") of such "useless" if stmts have been attempts to avoid what used to be UB/segfault on old systems, or simply due to people not realizing that free(NULL) is now known to be ok on all reasonable portability targets.
[Bug middle-end/86528] strlen of constant string malfunction -- had to back out fix for PR middle-end/77357
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.
[Bug middle-end/86528] New: strlen of constant string malfunction -- had to back out fix for PR middle-end/77357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86528 Bug ID: 86528 Summary: strlen of constant string malfunction -- had to back out fix for PR middle-end/77357 Product: gcc Version: 9.0 Status: UNCONFIRMED 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 warning from emacs. This one is ok: /p/emacs-2018-07-11.10h58/bin/emacs k this one and all subsequent (up to at least 2018-07-15) emit a warning: /p/emacs-2018-07-12.10h35/bin/emacs k Here's the warning: Warning (initialization): Unable to access `user-emacs-directory' (~/.emacs.d/). Any data that would normally be written there may be lost! If you never want to see this message again, customize the variable `user-emacs-directory-warning'. That's obviously wrong, because that directory *does* exist. Running it under strace shows a suspicious file name. It looks like use of uninitialized memory: $ strace -efile -ok.log emacs -q k $ grep -m3 x/.ema k.log faccessat(AT_FDCWD, "/m/.emacs.d/abbrev_defs", R_OK) = 0 openat(AT_FDCWD, "/m/.emacs.d", O_RDONLY|O_DIRECTORY|O_CLOEXEC|O_PATH) = 7 faccessat(AT_FDCWD, "/m/.emacs.d/\10YY|\376\177", F_OK) = -1 ENOENT (No such file or directory) Once the debugger showed which lines were involved, I found that this patch works around it. Besides, I have a tiny preference for memcpy over strcpy, since the length is known. diff --git a/src/fileio.c b/src/fileio.c index 5a1c7ae10e..3363cc0cf6 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -2861,9 +2861,11 @@ file_accessible_directory_p (Lisp_Object file) here. After appending '.', append another '/' to work around a macOS bug (Bug#30350). */ static char const appended[] = "/./"; + bool trailing_slash = data[len - 1] == '/'; char *buf = SAFE_ALLOCA (len + sizeof appended); memcpy (buf, data, len); - strcpy (buf + len, [data[len - 1] == '/']); + memcpy (buf + len, [trailing_slash], + sizeof appended - trailing_slash); dir = buf; } Then, I realized: it's related to a recent change in gcc and optimization. I had built latest emacs with latest built-from-git gcc. Emacs works when built with gcc from around July 8: rm src/fileio.o;make CC=/p/p/gcc-2018-07-08.16h57/bin/gcc CFLAGS='-ggdb3 -O2' Yet fails when built with gcc from July 11: rm src/fileio.o;make CC=/p/p/gcc-2018-07-11.11h00/bin/gcc CFLAGS='-ggdb3 -O2' Also, -O0 works in either case. Bisecting gcc led me to a commit that involves strlen of constant, which is what the replaced strcpy uses. 47d2cd73185a207ecc90970a73f5b38b114c48c2 PR middle-end/77357 - strlen of constant strings not folded Revert that, and emacs once again works when compiled with latest gcc.
[Bug tree-optimization/84921] New: [5 Regression] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movdqa) can be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84921 Bug ID: 84921 Summary: [5 Regression] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movdqa) can be used Product: gcc Version: 5.5.0 Status: UNCONFIRMED 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=edit 5.5 reproducer, with g++ -O3 Much like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598, this affects only the gcc-5-branch (I tested with head of 5) and appears to have been fixed on trunk by a combination of changes terminating with the 2015-06-18 commit, PR tree-optimization/66510 (git commit c1bee668987f371617586edafa0dfccf04162a83). This may also be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564, but someone claimed that was still present in 6.3, which this is not. Bisection suggests that this was fixed on master before the gcc-6-branch point by the commit mentioned above. Running the following minimized reproducer elicits a segfault from 5.5, but not from 6.1 (6.1 generates a movdqu rather than movdqa): g++ -std=c++14 -O3 unaligned-movdqa.cpp && ./a.out I considered back-porting the above commit and even took a shot at resolving the four conflicts, but that commit introduces uses of two functions (vect_slp_analyze_operations and vect_update_vf_for_slp) that were added in preceding diffs, so did not pursue it.
[Bug sanitizer/80659] [7/8 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr
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
[Bug sanitizer/80659] [7/8 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr
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=edit process.i.xz Thanks for the quick work. Here's the original process.i file. Had to compress it, because it was just larger than the 1000kb maximum.
[Bug c/80659] New: [7 regression] -fsanitize=address evokes ICE in in gimplify_switch_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80659
Bug ID: 80659
Summary: [7 regression] -fsanitize=address evokes ICE in in
gimplify_switch_expr
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
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-82ee72b054a4), yet gets no ICE with fedora 25's 6.3.1
20161221.
FYI, this was minimized using creduce from emacs/src/process.c.
$ cat bad.c
typedef a;
typedef b;
struct c {
b d
} e() {
union {
struct c f
} g;
switch (g.f.d) {
(a[]){};
h();
}
}
$ gcc -c -fsanitize=address bad.c
bad.c:1:9: warning: type defaults to 'int' in declaration of 'a'
[-Wimplicit-int]
typedef a;
^
bad.c:2:9: warning: type defaults to 'int' in declaration of 'b'
[-Wimplicit-int]
typedef b;
^
bad.c:5:1: warning: no semicolon at end of struct or union
} e() {
^
bad.c: In function 'e':
bad.c:8:3: warning: no semicolon at end of struct or union
} g;
^
bad.c:11:5: warning: implicit declaration of function 'h'
[-Wimplicit-function-declaration]
h();
^
bad.c:10:10: warning: statement will never be executed [-Wswitch-unreachable]
(a[]){};
^
bad.c:9:3: internal compiler error: in gimplify_switch_expr, at gimplify.c:2301
switch (g.f.d) {
^~
0x7c6d6d gimplify_switch_expr
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:2301
0x7c890a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:11466
0x7ca888 gimplify_stmt(tree_node**, gimple**)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:6517
0x7c8e6b gimplify_statement_list
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:1718
0x7c8e6b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:11686
0x7ca888 gimplify_stmt(tree_node**, gimple**)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:6517
0x7cb1c8 gimplify_bind_expr
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:1292
0x7c86ea gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:11458
0x7ca888 gimplify_stmt(tree_node**, gimple**)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:6517
0x7cbbe7 gimplify_body(tree_node*, bool)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:12455
0x7cbf95 gimplify_function_tree(tree_node*)
/data/users/meyering/x/w/co/gcc/gcc/gimplify.c:12613
0x69cf0f cgraph_node::analyze()
/data/users/meyering/x/w/co/gcc/gcc/cgraphunit.c:657
0x69f6f7 analyze_functions
/data/users/meyering/x/w/co/gcc/gcc/cgraphunit.c:1118
0x6a00d2 symbol_table::finalize_compilation_unit()
/data/users/meyering/x/w/co/gcc/gcc/cgraphunit.c:2603
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c/78539] New: feature request: __noextension__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78539
Bug ID: 78539
Summary: feature request: __noextension__
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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's definition of
assert:
#define assert(expr) \
__extension__ ({ \
if (__noextension__ (expr)) \
; \
else
__assert_failed (...); \
(void)0; \
})
Without that, I have to resort to using two cases: one for __STRICT_ANSI__
and one without, so that gcc -Wpedantic can still reliably diagnose "assert(
({1;}) );"
This was first suggested in https://gcc.gnu.org/ml/gcc/2001-04/msg00642.html
If you do add this, please ensure that the __noextension__(...) parentheses do
not end up suppressing the detection performed by gcc's -Wparentheses.
For reference, this came up recently in the following thread:
https://sourceware.org/ml/libc-alpha/2016-11/msg00866.html
[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective
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 just leave that there. The alternative of using an empty "__attribute__((__fallthrough__));" statement would require a macro expanding to that or to nothing.
[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective
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 */
#undef X
case 2:
x = 4;
}
return x;
}
$ /p/p/gcc-2016-10-02.12h48/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1
-Wimplicit-fallthrough /t/ft.c
foo
Analyzing compilation unit
/t/ft.c: In function ‘foo’:
/t/ft.c:20:9: warning: this statement may fall through [-Wimplicit-fallthroug ]
x = 3;
~~^~~
/t/ft.c:23:5: note: here
case 2:
^~~~
[Bug c/77817] New: -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817
Bug ID: 77817
Summary: -Wimplicit-fallthrough: cpp directive renders FALLTHRU
comment ineffective
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: minor
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 directive appears in the
vicinity of that comment, the comment becomes ineffective and we get the
warning anyway.
Here is a minimal example (without the "#undef", that comment *does* suppress
the warning):
int
foo (int x)
{
switch (x)
{
case 1:
x = 3;
#undef X
/* fallthrough */
case 2:
x = 4;
}
return x;
}
$ gcc -c -O -Wimplicit-fallthrough /t/ft.c
/t/ft.c: In function ‘foo’:
/t/ft.c:20:9: warning: this statement may fall through [-Wimplicit-fallthrough]
x = 3;
~~^~~
/t/ft.c:23:5: note: here
case 2:
^~~~
The above was compiled with yesterday's GCC 7:
gcc version 7.0.0 20161001 (experimental) (GCC)
I encountered an actual instance of this in gnulib's vasnprintf.c:
http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/vasnprintf.c#n4823
[Bug debug/72828] ICE in clone_tree_partial when compiling with -fdebug-types-section
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 --- Comment #6 from jim at meyering dot net --- I have just confirmed that this still elicits an ICE using Monday's just-built compiler: gcc version 7.0.0 20160919 (experimental) (GCC)
[Bug c++/70538] deprecated "access declaration" evokes gcc_unreachable ICE
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".
[Bug c++/70538] deprecated "access declaration" evokes gcc_unreachable ICE
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
[Bug c++/70538] New: deprecated "access declaration" evokes gcc_unreachable ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70538
Bug ID: 70538
Summary: deprecated "access declaration" evokes gcc_unreachable
ICE
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: 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 favour of
using-declarations; suggestion: add the ‘using’ keyword [-Wdeprecated]
gcc reaches a gcc_unreachable call at gcc/cp/pt.c:17317:
17312 /* Look for the clone. */
17313 FOR_EACH_CLONE (clone, spec)
17314 if (DECL_NAME (clone) == DECL_NAME (tmpl))
17315 return clone;
17316 /* We should always have found the clone by now. */
17317 gcc_unreachable ();
17318 return NULL_TREE;
Here is a 'creduce'd input that triggers that error:
$ g++ --version|head -1 && cat x.ii && ./cc1plus x.ii
g++ (GCC) 6.0.0 20160405 (experimental)
struct A;
template class C;
using PathComponentPiece = C;
class B {
B(int);
template B(T);
B(C);
};
template class C : B {
using base_type = B;
base_type::base_type;
PathComponentPiece m_fn1() {}
};
x.ii:11:3: warning: access declarations are deprecated in favour of
using-declarations; suggestion: add the ‘using’ keyword [-Wdeprecated]
base_type::base_type;
^
x.ii: In substitution of ‘template C::C(T) [with T = int]’:
x.ii:11:14: recursively required by substitution of ‘template
C::C(T) [with T = int]’
x.ii:11:14: required from ‘class C’
x.ii:12:30: required from here
x.ii:11:14: internal compiler error: in instantiate_template_1, at
cp/pt.c:17317
base_type::base_type;
^
0x62362a instantiate_template_1
../../gcc/cp/pt.c:17317
0x623a1c instantiate_template(tree_node*, tree_node*, int)
../../gcc/cp/pt.c:17449
0x624326 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/cp/pt.c:17808
0x5d085d add_template_candidate_real
../../gcc/cp/call.c:3089
0x5d0fbc add_template_candidate
../../gcc/cp/call.c:3171
0x5d0fbc add_candidates
../../gcc/cp/call.c:5344
0x5ce443 build_user_type_conversion_1
../../gcc/cp/call.c:3687
0x5cee30 implicit_conversion
../../gcc/cp/call.c:1863
0x5d02b8 add_function_candidate
../../gcc/cp/call.c:2121
0x5d0f5f add_candidates
../../gcc/cp/call.c:5354
0x5d14f4 build_new_method_call_1
../../gcc/cp/call.c:8293
0x5d14f4 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:8489
0x6b5bce locate_fn_flags
../../gcc/cp/method.c:900
0x6b65d8 synthesized_method_walk
../../gcc/cp/method.c:1477
0x6b6f54 deduce_inheriting_ctor(tree_node*)
../../gcc/cp/method.c:1711
0x61273c tsubst_decl
../../gcc/cp/pt.c:11941
0x614b94 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:12817
0x6238b5 instantiate_template_1
../../gcc/cp/pt.c:17398
0x623a1c instantiate_template(tree_node*, tree_node*, int)
../../gcc/cp/pt.c:17449
0x623480 instantiate_template_1
../../gcc/cp/pt.c:17307
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/66921] [4.9/5/6 Regression] failure to determine size of static constexpr array that is nested within a templated class
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 --- Comment #3 from jim at meyering dot net --- I too have just found my upgrade to 4.9.x blocked by many instances of this problem. Any fix in gcc would be most welcome.
[Bug middle-end/67861] [6 Regression] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944
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=edit wc.i Attaching wc.i:
[Bug middle-end/67861] New: coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67861 Bug ID: 67861 Summary: coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944 Product: gcc Version: unknown Status: 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 write_counts function is no longer compiled correctly, yielding a "wc" command that prints only a newline, regardless of optimization level. To reproduce, I bootstrapped and installed gcc, then built coreutils from git, then ran this: echo | src/wc and since that commit, it prints only a newline. Normally it would print this 24-byte sequence: 1 0 1 I confirmed that it is also reproduced when building from the latest released tarball: wget http://ftp.gnu.org/gnu/coreutils/coreutils-8.24.tar.xz tar xf coreutils-8.24.tar.xz && cd coreutils-8.24 && ./configure && make When built with a recently-bootstrapped gcc, wc malfunctions like this: $ echo | src/wc|od -An -a nl
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
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
--- Comment #10 from jim at meyering dot net ---
I have just encountered this problem and reduced a large input file to this:
$ cat z.cpp
struct A {
typedef A B;
int m;
struct {
V(B);
}
}
$ g++ --version|head -1
g++ (GCC) 6.0.0 20150801 (experimental)
That provokes the same ICE with this command:
$ g++ -g -fpermissive z.cpp
z.cpp:5:8: warning: ISO C++ forbids declaration of ‘V’ with no type
[-fpermissive]
V(B);
^
z.cpp:4:10: error: TYPE_CANONICAL is not compatible
struct {
^
record_type 0x7f3208e9e1f8 A type_5 VOID
align 8 symtab 148250704 alias set -1 canonical type 0x7f3208e9e1f8
fields field_decl 0x7f3208e9b558 m
type integer_type 0x7f3208d3c7e0 int asm_written public SI
size integer_cst 0x7f3208d5a0a8 constant 32
unit size integer_cst 0x7f3208d5a0c0 constant 4
align 32 symtab 148250944 alias set -1 canonical type
0x7f3208d3c7e0 precision 32 min integer_cst 0x7f3208d5a060 -2147483648 max
integer_cst 0x7f3208d5a078 2147483647
pointer_to_this pointer_type 0x7f3208d5e930
decl_3 VOID file z.cpp line 3 col 7
align 1 offset_align 1 context record_type 0x7f3208e9e1f8 A
chain type_decl 0x7f3208e9b428 A type record_type 0x7f3208e9e2a0 A
used nonlocal decl_4 VOID file z.cpp line 1 col 10
align 1 context record_type 0x7f3208e9e1f8 A result record_type
0x7f3208e9e1f8 A
chain type_decl 0x7f3208e9b4c0 B context translation_unit_decl
0x7f32107ca1e0 D.1
full-name struct A
n_parents=0 use_template=0 interface-unknown
chain type_decl 0x7f3208e9b390 A
record_type 0x7f3208e9e348 B type_5 VOID
align 8 symtab 0 alias set -1 canonical type 0x7f3208e9e1f8
fields type_decl 0x7f3208e9b428 A
type record_type 0x7f3208e9e2a0 A type_5 VOID
align 8 symtab 0 alias set -1 canonical type 0x7f3208e9e1f8 context
translation_unit_decl 0x7f32107ca1e0 D.1
full-name struct A
n_parents=0 use_template=0 interface-unknown
chain type_decl 0x7f3208e9b390 A
used nonlocal decl_4 VOID file z.cpp line 1 col 10
align 1 context record_type 0x7f3208e9e1f8 A
result record_type 0x7f3208e9e1f8 A type_5 VOID
align 8 symtab 148250704 alias set -1 canonical type 0x7f3208e9e1f8
fields field_decl 0x7f3208e9b558 m context translation_unit_decl
0x7f32107ca1e0 D.1
full-name struct A
n_parents=0 use_template=0 interface-unknown
chain type_decl 0x7f3208e9b390 A
chain type_decl 0x7f3208e9b4c0 B type record_type 0x7f3208e9e348 B
used nonlocal VOID file z.cpp line 2 col 13
align 1 context record_type 0x7f3208e9e1f8 A result record_type
0x7f3208e9e1f8 A
chain type_decl 0x7f3208e9b688 ._0 context
translation_unit_decl 0x7f32107ca1e0 D.1
full-name A::B
n_parents=0 use_template=0 interface-unknown
chain type_decl 0x7f3208e9b390 A
z.cpp:4:10: internal compiler error: verify_type failed
0xfe0959 verify_type(tree_node const*)
../../gcc/tree.c:13570
0x965ed4 gen_type_die_with_usage
../../gcc/dwarf2out.c:20685
0x967506 gen_type_die
../../gcc/dwarf2out.c:20879
0x96837c modified_type_die
../../gcc/dwarf2out.c:10810
0x968b84 add_type_attribute
../../gcc/dwarf2out.c:17486
0x968db7 gen_formal_parameter_die
../../gcc/dwarf2out.c:18100
0x9692c1 gen_formal_types_die
../../gcc/dwarf2out.c:18198
0x960ab7 gen_subprogram_die
../../gcc/dwarf2out.c:19083
0x96483b gen_decl_die
../../gcc/dwarf2out.c:21442
0x963b54 gen_member_die
../../gcc/dwarf2out.c:20377
0x963b54 gen_struct_or_union_type_die
../../gcc/dwarf2out.c:20461
0x963b54 gen_tagged_type_die
../../gcc/dwarf2out.c:20662
0x9669bd gen_type_die_with_usage
../../gcc/dwarf2out.c:20824
0x967506 gen_type_die
../../gcc/dwarf2out.c:20879
0x964bbe gen_decl_die
../../gcc/dwarf2out.c:21465
0x965794 dwarf2out_decl
../../gcc/dwarf2out.c:21915
0x965a6b dwarf2out_type_decl
../../gcc/dwarf2out.c:21625
0xc8446f rest_of_type_compilation(tree_node*, int)
../../gcc/passes.c:336
0x698ef3 finish_struct_1(tree_node*)
../../gcc/cp/class.c:6738
0x69a5a4 finish_struct(tree_node*, tree_node*)
../../gcc/cp/class.c:6904
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Exit 1]
[Bug c/63445] New: request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
Bug ID: 63445
Summary: request: make -Wstrict-overflow avoid a class of false
positives
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
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 reduced test case:
In this example, the code ensures j - i will be positive before assigning
that value to an unsigned int n. Can gcc be taught to avoid this obvious
false positive?
$ cat f.c
int
f (int i, int j)
{
unsigned int c = 0;
if (i j)
{
unsigned int n = j - i;
for (unsigned int i = 0; i n; i++)
{
c++;
}
}
return c;
}
$ gcc -O2 -std=c99 -Wstrict-overflow -c f.c
f.c: In function ‘f’:
f.c:9:7: warning: assuming signed overflow does not occur when simplifying
conditional [-Wstrict-overflow]
for (unsigned int i = 0; i n; i++)
^
$ gcc -v 21|tail -2
gcc version 5.0.0 20141002 (experimental) (GCC)
[Bug c++/56493] Performance regression in google dense hashmap
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 --- Comment #12 from jim at meyering dot net --- Thank you, Jakub.
[Bug tree-optimization/56210] invalid -Warray-bounds warning
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.
[Bug middle-end/56210] New: invalid -Warray-bounds warning
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: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@meyering.net
The following code evokes what looks like an invalid warning with
-Warray-bounds.
It is independent of char signedness (same with -funsigned-char or with
-fsigned-char), so should be different from bug#35903.
$ cat k.c
#include string.h
#include stdio.h
void
f (void)
{
char *p = ;;
while (*p) {
static char key[] = abc;
if (strncmp(p, key, 3) == 0) {
p += 3;
printf(%s\n, p);
return;
}
if ((p = strchr(p, ';')) == NULL)
return;
p++;
}
}
$ gcc -save-temps -O2 -Wall -c k.c
k.c: In function 'f':
k.c:12:19: warning: array subscript is above array bounds [-Warray-bounds]
printf(%s\n, p);
^
$ gcc -v
Using built-in specs.
COLLECT_GCC=/p/bin/gcc
COLLECT_LTO_WRAPPER=/p/p/gcc-2013-01-16.09h15/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /h/j/w/co/gcc/configure --prefix=/p/p/gcc-2013-01-16.09h15
--enable-languages='c++ go'
Thread model: posix
gcc version 4.8.0 20130116 (experimental) (GCC)
Attaching the .i file momentarily...
[Bug middle-end/56210] invalid -Warray-bounds warning
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
[Bug c/54409] New: internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710
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: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@meyering.net I happened to have the latest gcc in my shell's search path when testing a linux kernel change, and fs/cifs/connect.c provoked this internal error: the exact version of GCC: gcc version 4.8.0 20120829 (experimental) (GCC) the system type: x86_64 (Fedora 17) the options given when GCC was configured/built: CC=/usr/bin/gcc $srcdir/configure --prefix=$prefix --disable-multilib \ --disable-libmudflap --disable-nls --enable-languages='c go' make bootstrap the complete command line that triggers the bug: $ gcc -Iarch/x86/include -Iarch/x86/include/generated -Iinclude \ -include include/linux/kconfig.h -D__KERNEL__ -Os -c -o fs/cifs/connect.o \ fs/cifs/connect.c the compiler output (error messages, warnings, etc.): fs/cifs/connect.c:4302:1: internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. the preprocessed file (*.i*): Attached.
[Bug c/54409] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710
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
[Bug c/54409] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710
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 at meyering dot net 2012-08-29 14:41:52 UTC --- note that this affects latest from git: 4.8.0
[Bug c/53053] New: code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
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
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@meyering.net
Background, gcc-compiled emacs (bzr trunk) began to segfault
differently when compiled with yesterday's gcc-trunk.
Given this function from emacs' dispnew.c,
(LAST_AREA is an enum with value 3)
static __attribute__((noinline)) void
swap_glyph_pointers (struct glyph_row *a, struct glyph_row *b)
{
unsigned int i;
unsigned hash_tem = a-hash;
for (i = 0; i LAST_AREA + 1; ++i)
{
struct glyph *temp = a-glyphs[i];
short used_tem = a-used[i];
a-glyphs[i] = b-glyphs[i];
b-glyphs[i] = temp;
a-used[i] = b-used[i];
b-used[i] = used_tem;
}
a-hash = b-hash;
b-hash = hash_tem;
}
*** FAILURE: using yesterday's gcc
Compiling dispnew with -O1 or less there is no problem.
Compiling just dispnew.c with -O2 (all the rest is compiled with -ggdb3)
via make CFLAGS='-O2 -ggdb3' CC=/p/p/gcc-2012-04-19.16h18/bin/gcc
* currently-generated code, i increases until segfault:
0120 swap_glyph_pointers:
120:31 c0xor%eax,%eax
122:66 0f 1f 44 00 00nopw 0x0(%rax,%rax,1)
128:48 8b 0c 87 mov(%rdi,%rax,4),%rcx
12c:4c 8b 04 86 mov(%rsi,%rax,4),%r8
130:0f b7 54 07 20 movzwl 0x20(%rdi,%rax,1),%edx
135:4c 89 04 87 mov%r8,(%rdi,%rax,4)
139:48 89 0c 86 mov%rcx,(%rsi,%rax,4)
13d:0f b7 4c 06 20 movzwl 0x20(%rsi,%rax,1),%ecx
142:66 89 4c 07 20 mov%cx,0x20(%rdi,%rax,1)
147:66 89 54 06 20 mov%dx,0x20(%rsi,%rax,1)
14c:48 83 c0 02 add$0x2,%rax
150:eb d6jmp128 swap_glyph_pointers+0x8
152:66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw
%cs:0x0(%rax,%rax,1)
159:1f 84 00 00 00 00 00
*** SUCCESS: using gcc from Wed April 18
Compiling the same file with gcc built from a snapshot a day earlier,
make CFLAGS='-O2 -ggdb3' CC=/p/p/gcc-2012-04-18.15h00/bin/gcc
* code generated by svn/trunk of gcc-2012-04-18.15h00 (UTC),
This loop terminates normally.
0120 swap_glyph_pointers:
120:44 8b 4f 4c mov0x4c(%rdi),%r9d
124:31 c0xor%eax,%eax
126:48 8b 0c 87 mov(%rdi,%rax,4),%rcx
12a:4c 8b 04 86 mov(%rsi,%rax,4),%r8
12e:0f b7 54 07 20 movzwl 0x20(%rdi,%rax,1),%edx
133:4c 89 04 87 mov%r8,(%rdi,%rax,4)
137:48 89 0c 86 mov%rcx,(%rsi,%rax,4)
13b:0f b7 4c 06 20 movzwl 0x20(%rsi,%rax,1),%ecx
140:66 89 4c 07 20 mov%cx,0x20(%rdi,%rax,1)
145:66 89 54 06 20 mov%dx,0x20(%rsi,%rax,1)
14a:48 83 c0 02 add$0x2,%rax
14e:48 83 f8 08 cmp$0x8,%rax
152:75 d2jne126 swap_glyph_pointers+0x6
154:8b 46 4c mov0x4c(%rsi),%eax
157:89 47 4c mov%eax,0x4c(%rdi)
15a:44 89 4e 4c mov%r9d,0x4c(%rsi)
15e:c3 retq
15f:90 nop
[Bug c/53053] code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
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.
[Bug c/53053] code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
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 --prefix=$prefix --disable-multilib \ --disable-libmudflap --disable-nls --enable-languages=c make bootstrap
[Bug c/53053] code-gen (missing loop-termination test) bug introduced between April 18 and April 19th
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 invalid input. Thank you both. definitely NOTABUG.
[Bug c/52560] if (r == -1) causes 'assuming signed overflow does not occur when simplifying conditional to constant'
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
[Bug c/49426] New: unwarranted warning from -Wsign-compare
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.gnu.org
ReportedBy: j...@meyering.net
In the following function, the compiler can deduce that c
is positive when it is compared with k, so should not emit a warning:
$ cat k.c
int
f (int c, unsigned int k)
{
if (c 0)
return -1;
return c k;
}
$ gcc -c -O2 -Wsign-compare k.c
k.c: In function 'f':
k.c:6:12: warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
Using built-in specs.
COLLECT_GCC=/p/bin/gcc
COLLECT_LTO_WRAPPER=/h/p/p/gcc-2011-06-14.11h16/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /h/j/w/co/gcc-svn/configure --prefix=/p/p/gcc-2011-06-14.11h16
--disable-multilib --disable-libmudflap --disable-nls --enable-languages=c
Thread model: posix
gcc version 4.7.0 20110613 (experimental) (GCC)
[Bug c/49262] New: 3-yr-old infinite loop in dwarf2out.c
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.gnu.org
ReportedBy: j...@meyering.net
coverity pointed out the infinite loop below, in dwarf2out.c.
I guess it is unreachable or at least hard to reach,
or it would have been reported/fixed before now:
17605 if (index TREE_CODE (index) == RANGE_EXPR)
17606{
17607 int count = tree_low_cst (TREE_OPERAND (index, 1), 0)
17608 - tree_low_cst (TREE_OPERAND (index, 0), 0);
Event loop_top: Top of the loop.
Event loop_condition: 0 count must remain true for the loop to
continue.
Also see events: [loop_bottom]
17609 while (count 0)
17610{
17611 if (val)
17612memcpy (array + curpos, array + pos, fieldsize);
Event loop_bottom: Bottom of the loop.
Also see events: [loop_top][loop_condition]
17613 curpos += fieldsize;
17614}
17615}
[Bug c/49234] New: -Wstrict-overflow gives obviously unwarranted warning
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: unassig...@gcc.gnu.org
ReportedBy: j...@meyering.net
Given this code, in file k.c, -O2 -Wstrict-overflow evokes a warning.
However, since the only values assigned to state are 0, 1 and 2,
gcc should be able to determine that no overflow is possible,
and hence should issue no warning:
char *
trim2 (char *d)
{
int state = 0;
char *r;
int i;
for (i = 0; d[i]; i++)
{
if (state == 0 d[i] == ' ')
continue;
if (state == 0) /* line 13 */
state = 1;
if (state == 1)
{
state = 2;
r = d + i;
}
}
if (state == 2)
*r = '\0';
return d;
}
$ gcc -O2 -Wstrict-overflow -c k.c
k.c: In function 'trim2':
k.c:13:10: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
For the record, until recently I would not have bothered enabling
-Wstrict-overflow, due to the high proportion of false-positives,
but since I've learned about the risk of this bug,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33498
I am now more inclined to use -Wstrict-overflow in spite of that.
[Bug c/44806] New: 4.5.0 i686 code generation regression with -O2
This bug manifests on i686, and not on x86_64.
[FYI, pared down from a proposed patch for coreutils' du.c. ]
The following code, compiled with 4.5.0 and -O2 exits with status 1.
Compile with 4.4.4 and any optimization or 4.5.0 with -O1 and it exits with
status 0.
$ cat k.c
#include stdint.h
#define N_DEV_BITS_4 5
#define N_INO_BITS_4 (32 - N_DEV_BITS_4 - 2 - 1)
#define N_DEV_BITS_8 8
#define N_INO_BITS_8 (64 - N_DEV_BITS_8 - 2 - 1)
struct dev_ino_4
{
uint32_t mode:2;
uint32_t short_ino:N_INO_BITS_4;
uint32_t mapped_dev:N_DEV_BITS_4;
uint32_t always_set:1;
};
struct dev_ino_8
{
uint32_t mode:2;
uint64_t short_ino:N_INO_BITS_8;
uint32_t mapped_dev:N_DEV_BITS_8;
uint32_t always_set:1;
};
struct dev_ino_full
{
uint32_t mode:2;
uint32_t dev;
uint32_t ino;
};
enum di_mode
{
DI_MODE_4 = 1,
DI_MODE_8 = 2,
DI_MODE_FULL = 3
};
struct di_ent
{
union
{
struct dev_ino_4 di4;
struct dev_ino_8 di8;
struct dev_ino_full full;
uint32_t u32;
uint64_t u64;
void *ptr;
} u;
};
static struct di_ent
decode_ptr (struct di_ent const *v)
{
struct di_ent di;
di.u.ptr = (void *) v;
return di;
}
static int
di_ent_equal (void const *x, void const *y)
{
struct di_ent a = decode_ptr (x);
struct di_ent b = decode_ptr (y);
if (a.u.di4.mode != b.u.di4.mode)
return 0;
if (a.u.di4.mode == DI_MODE_4)
return (a.u.di4.short_ino == b.u.di4.short_ino
a.u.di4.mapped_dev == b.u.di4.mapped_dev);
if (a.u.di8.mode == DI_MODE_8)
return (a.u.di8.short_ino == b.u.di8.short_ino
a.u.di8.mapped_dev == b.u.di8.mapped_dev);
return (a.u.full.ino == b.u.full.ino
a.u.full.dev == b.u.full.dev);
}
int
main ()
{
return di_ent_equal ((void *) 0x80143c4d, (void *) 0x80173851);
}
$ /p/p/gcc-4.5.0/bin/gcc -Wall -O2 k.c ./a.out
[Exit 1]
$ /p/p/gcc-4.5.0/bin/gcc -Wall -O1 k.c ./a.out; echo $?
0
$ gcc -v 21|tail -1
gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC)
$ gcc -Wall -O2 k.c ./a.out; echo $?
0
configured with: ../configure --disable-nls --enable-languages=c
--prefix=/p/p/gcc-4.5.0
--
Summary: 4.5.0 i686 code generation regression with -O2
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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
[Bug other/44435] gengtype: don't test undefined value after vasprintf failure
--- 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
[Bug c/44435] New: gengtype: don't test undefined value after vasprintf failure
Harmless, but distracting... This is present is the latest sources on trunk. gengtype: don't test undefined value after vasprintf failure While libiberty's asprintf function does guarantee that the pointer is set to NULL upon asprintf failure, POSIX/glibc make no such guarantee. * gengtype.c (xasprintf): Don't test an undefined value upon vasprintf failure. * gengtype.c (oprintf): Likewise. Patch attached. -- Summary: gengtype: don't test undefined value after vasprintf failure Product: gcc Version: 4.6.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
[Bug c/44435] gengtype: don't test undefined value after vasprintf failure
--- 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=20851action=view) gengtype: don't test undefined value after vasprintf failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
[Bug c/39589] New: make -Wmissing-field-initializers=2 work with designated initializers ?
Compiling this with -Wmissing-field-initializers evokes a warning:
struct foo { int a; int b; };
struct foo f = { 1 };
but with designated initializers it does not:
struct foo { int a; int b; };
struct foo f = { .a = 1 };
That -Wmissing-field-initializers works this way is even documented.
My quandary is that I'd prefer to use the more readable and
maintainable c99 form, especially with long lists of member names:
foo = {
.f1 = callback_a,
.f2 = callback_b,
.f3 = callback_c,
...
.fn = callback_n,
};
Then, it's obvious that foo.f23 is initialized to callback_23,
whereas with old-style initializations, I'd have to count,
and if ever I had the misfortune to reorder member names,
and signatures are similar, it'd be easy to miss the error.
However, the old-style initialization has the advantage that
when I add a new member, gcc -Wmissing-field-initializers will
prompt me to add a new initializer. With the c99-style, there
seems to be no way to evoke a similar prod.
Maybe we can get the best of both worlds?
Paolo Bonzini mentioned that this would be easy to implement,
and that -Wmissing-field-initializers=2 may be the way to do it,
given the precedent of -Wstrict-overflow and -Wstrict-overflow=N.
--
Summary: make -Wmissing-field-initializers=2 work with
designated initializers ?
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
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
