[Bug c/65244] Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65244 --- Comment #1 from Ulf Magnusson ulfalizer at gmail dot com --- This warning did not occur for GCC 4.8.2 (or whatever the most recent GCC version is on Ubuntu 14.04) by the way.
[Bug c/65244] New: Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65244
Bug ID: 65244
Summary: Bogus -Wmaybe-uninitialized warning with
posix_memalign() and -Og
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ulfalizer at gmail dot com
The warning
posix_memalign_warn.c: In function ‘f’:
posix_memalign_warn.c:9:5: warning: ‘ptr’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
return ptr;
^
is generated when compiling the following with
gcc -Og -Wmaybe-uninitialized -c posix_memalign_warn.c
No warning is produced for -O0/1/2/3/fast.
#include stdlib.h
void *f(void) {
void *ptr;
if (posix_memalign(ptr, 16, 256) != 0)
exit(EXIT_FAILURE);
return ptr;
}
[Bug c/65244] Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65244
--- Comment #6 from Ulf Magnusson ulfalizer at gmail dot com ---
Comment on attachment 34894
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34894
-Wmaybe-uninitialized-warning with -Og with GCC 4.9.1
void exit(int __status) __attribute__ ((__noreturn__));
int posix_memalign(void **__memptr, __SIZE_TYPE__ __alignment, __SIZE_TYPE__
__size);
void *f(void) {
void *ptr;
if (posix_memalign(ptr, 16, 256) != 0)
exit(1);
return ptr;
}
[Bug c/65244] Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65244 --- Comment #7 from Ulf Magnusson ulfalizer at gmail dot com --- Created attachment 34895 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34895action=edit Headerless version Sorry -- thought my previous action would edit the attachment directly. I've now attached an equivalent headerless version (by keeping the relevant parts of the preprocessed source). This is on Ubuntu 14.10 BTW, not OS X.
[Bug c/65244] Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65244 --- Comment #4 from Ulf Magnusson ulfalizer at gmail dot com --- Created attachment 34894 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34894action=edit -Wmaybe-uninitialized-warning with -Og with GCC 4.9.1 The testcase was in the comment. I'm attaching it. I don't have access to GCC 5.0. Perhaps the behavior changed between GCC 4.9.1 and that version.
[Bug c/65244] Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65244 --- Comment #9 from Ulf Magnusson ulfalizer at gmail dot com --- Created attachment 34897 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34897action=edit Reduce testcase using __builtin_posix_memalign(). The warning goes away with -fno-builtin. I didn't realize posix_memalign() existed as a builtin (documentation bug?). Attaching a further reduced testcase.
[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767 --- Comment #2 from Ulf Magnusson ulfalizer at gmail dot com --- Looks like -Wnon-literal-null-conversion is intended to warn for the comparison case too, though it doesn't seem to be implemented yet as of clang 3.4: http://llvm.org/klaus/clang/commit/50800fc551ac6b8a95cca662223e7f061bbd169a/
[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767 --- Comment #3 from Ulf Magnusson ulfalizer at gmail dot com --- clang also generates a warning for C programs with void *a = '\0' by the way, so it seems to be able to look at the form of the integral constant there.
[Bug c++/64767] New: Could GCC warn when a pointer is compared against '\0'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767 Bug ID: 64767 Summary: Could GCC warn when a pointer is compared against '\0'? Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ulfalizer at gmail dot com This would detect e.g. ptr == '\0' when *ptr == '\0' was intended, which could be very dangerous (and just bit me). This might be tricky to implement in C since '\0' has type int and comparing a pointer against 0 is common. In C++ it has type char, so maybe a warning could be generated for ptr == (char)0 there. Thoughts?
[Bug c++/54807] New: Names declared in a for's for-init-statement and condition should be in the same declarative region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54807 Bug #: 54807 Summary: Names declared in a for's for-init-statement and condition should be in the same declarative region Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ulfali...@gmail.com for (int i; int i = 0;) should give an error but currently doesn't. 14882:2003 6.5.3.1: ...except that names declared in the for-init-statement are in the same declarative-region as those declared in the condition.
[Bug c++/54807] Names declared in a for's for-init-statement and condition should be in the same declarative region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54807 --- Comment #2 from Ulf Magnusson ulfalizer at gmail dot com 2012-10-04 04:57:42 UTC --- Could very well be the same problem, but I don't have 4.7 handy to confirm.
[Bug c/47130] New: Problem with macro expansion in GDB when using PCHs and #including .cpp files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47130
Summary: Problem with macro expansion in GDB when using PCHs
and #including .cpp files
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ulfali...@gmail.com
Take the following three files (this occurs for us as part of a system for
speeding up compiles, where one .cpp file includes many others):
bug.h:
#define FOO 1
bug.cpp:
#include bug.h
#include bug2.cpp
bug2.cpp:
int main() {}
The header is precompiled and the program built using
g++ -ggdb3 bug.h
g++ -ggdb3 bug.cpp -o bug
If I run GDB and break in main() I ought to be able to expand FOO, but GDB
seems unable to find the macro:
(gdb) start
Temporary breakpoint 1, main () at bug2.cpp:1
(gdb) print FOO
No symbol FOO in current context.
(gdb) macro expand FOO
expands to: FOO
If I move main() to bug.cpp (or remove the precompiled header), everything
works fine.
Thanks in advance,
Ulf Magnusson
-save-temps output:
bug.h.ii:
# 1 bug.h
# 1 /home/ulf/devel/cpp//
# 1 built-in
#define __STDC__ 1
#define __cplusplus 1
#define __STDC_HOSTED__ 1
#define __GNUC__ 4
#define __GNUC_MINOR__ 4
#define __GNUC_PATCHLEVEL__ 3
#define __GNUG__ 4
#define __SIZE_TYPE__ unsigned int
#define __PTRDIFF_TYPE__ int
#define __WCHAR_TYPE__ int
#define __WINT_TYPE__ unsigned int
#define __INTMAX_TYPE__ long long int
#define __UINTMAX_TYPE__ long long unsigned int
#define __CHAR16_TYPE__ short unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __GXX_WEAK__ 1
#define __DEPRECATED 1
#define __GXX_RTTI 1
#define __EXCEPTIONS 1
#define __GXX_ABI_VERSION 1002
#define __SCHAR_MAX__ 127
#define __SHRT_MAX__ 32767
#define __INT_MAX__ 2147483647
#define __LONG_MAX__ 2147483647L
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __WCHAR_MAX__ 2147483647
#define __CHAR_BIT__ 8
#define __INTMAX_MAX__ 9223372036854775807LL
#define __FLT_EVAL_METHOD__ 2
#define __DEC_EVAL_METHOD__ 2
#define __FLT_RADIX__ 2
#define __FLT_MANT_DIG__ 24
#define __FLT_DIG__ 6
#define __FLT_MIN_EXP__ (-125)
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MAX_EXP__ 128
#define __FLT_MAX_10_EXP__ 38
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MIN__ 1.17549435e-38F
#define __FLT_EPSILON__ 1.19209290e-7F
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __FLT_HAS_DENORM__ 1
#define __FLT_HAS_INFINITY__ 1
#define __FLT_HAS_QUIET_NAN__ 1
#define __DBL_MANT_DIG__ 53
#define __DBL_DIG__ 15
#define __DBL_MIN_EXP__ (-1021)
#define __DBL_MIN_10_EXP__ (-307)
#define __DBL_MAX_EXP__ 1024
#define __DBL_MAX_10_EXP__ 308
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __DBL_HAS_DENORM__ 1
#define __DBL_HAS_INFINITY__ 1
#define __DBL_HAS_QUIET_NAN__ 1
#define __LDBL_MANT_DIG__ 64
#define __LDBL_DIG__ 18
#define __LDBL_MIN_EXP__ (-16381)
#define __LDBL_MIN_10_EXP__ (-4931)
#define __LDBL_MAX_EXP__ 16384
#define __LDBL_MAX_10_EXP__ 4932
#define __DECIMAL_DIG__ 21
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __LDBL_HAS_DENORM__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __DEC32_MANT_DIG__ 7
#define __DEC32_MIN_EXP__ (-94)
#define __DEC32_MAX_EXP__ 97
#define __DEC32_MIN__ 1E-95DF
#define __DEC32_MAX__ 9.99E96DF
#define __DEC32_EPSILON__ 1E-6DF
#define __DEC32_SUBNORMAL_MIN__ 0.01E-95DF
#define __DEC64_MANT_DIG__ 16
#define __DEC64_MIN_EXP__ (-382)
#define __DEC64_MAX_EXP__ 385
#define __DEC64_MIN__ 1E-383DD
#define __DEC64_MAX__ 9.999E384DD
#define __DEC64_EPSILON__ 1E-15DD
#define __DEC64_SUBNORMAL_MIN__ 0.001E-383DD
#define __DEC128_MANT_DIG__ 34
#define __DEC128_MIN_EXP__ (-6142)
#define __DEC128_MAX_EXP__ 6145
#define __DEC128_MIN__ 1E-6143DL
#define __DEC128_MAX__ 9.9E6144DL
#define __DEC128_EPSILON__ 1E-33DL
#define __DEC128_SUBNORMAL_MIN__ 0.1E-6143DL
#define __REGISTER_PREFIX__
#define __USER_LABEL_PREFIX__
#define __VERSION__ 4.4.3
#define __GNUC_GNU_INLINE__ 1
#define __NO_INLINE__ 1
#define __FINITE_MATH_ONLY__ 0
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_DWARF2_CFI_ASM 1
#define __SSP__ 1
#define __SIZEOF_INT__ 4
#define __SIZEOF_LONG__ 4
#define __SIZEOF_LONG_LONG__ 8
#define __SIZEOF_SHORT__ 2
#define __SIZEOF_FLOAT__ 4
#define __SIZEOF_DOUBLE__ 8
#define __SIZEOF_LONG_DOUBLE__ 12
#define __SIZEOF_SIZE_T__ 4
#define __SIZEOF_WCHAR_T__ 4
#define __SIZEOF_WINT_T__ 4
#define __SIZEOF_PTRDIFF_T__ 4
[Bug pch/47130] Problem with macro expansion in GDB when using PCHs and #including .cpp files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47130 --- Comment #2 from Ulf Magnusson ulfalizer at gmail dot com 2010-12-30 21:30:47 UTC --- (In reply to comment #1) presumably component should be pch or c++ ... not c though Didn't notice the pch category - sorry about that.
[Bug c/22539] New: Internal compiler error with maximum sized array
Compiling this:
#define SIZE 2u 31 - 2
int main() {
char a[SIZE], b[SIZE];
}
Gives this compilation error:
bigcp.c: In function `main':
bigcp.c:7: error: unrecognizable insn:
(insn/f 34 33 35 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -2147483656 [0x7ff8])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) -1 (nil)
(nil))
bigcp.c:7: internal compiler error: in insn_default_length, at
insn-attrtab.c:435
Only the maximum allowed array size gives the error, and at least two objects
must be allocated on stack.
--
Summary: Internal compiler error with maximum sized array
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ulfalizer at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: FreeBSD 5.4-RELEASE i386
GCC host triplet: FreeBSD 5.4-RELEASE i386
GCC target triplet: FreeBSD 5.4-RELEASE i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22539
