[Bug c/111526] inconsistent handling of declaration after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111526 --- Comment #4 from Pádraig Brady --- Interestingly, gcc 13 _does_ warn with -Wc11-c2x-compat, but does not warn with -Wpedantic
[Bug c/111526] inconsistent handling of declaration after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111526 --- Comment #3 from Pádraig Brady --- Created attachment 55964 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55964=edit coreutils tail.c compilation unit This should warn with -Wpedantic, but doesn't on gcc 13
[Bug c/111526] New: inconsistent handling of declaration after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111526
Bug ID: 111526
Summary: inconsistent handling of declaration after label
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: P at draigBrady dot com
Target Milestone: ---
Created attachment 55963
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55963=edit
coreutils fix for non gcc >= 11
Ever since https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8b7a9a24
declarations after labels are allowed by default,
and only disabled with -pedantic etc.
I.e. the following simple code compiles on gcc >= 11,
but will fail when tried to be compiled with gcc <= 10, or clang for e.g.
This is exacerbated by the fact there is no compiler option
to avoid the issue on gcc <= 10 or clang,
as that code is explicitly disallowed by C11 and earlier.
int f(int x) { switch (x) { case 1: int i=f(x); } return 0; }
There is also a more subtle related issue
(which I haven't fully reduced but can easily reproduce),
where the warning will NOT fire even with -Wpedantic on gcc 13 at least.
If one compiles GNU coreutils with the attached commit reverted,
and with -Wpedantic on newer gcc, it will _NOT_ issue a warning.
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428 --- Comment #3 from Pádraig Brady --- I've not got a reduced example where clang is generating the call, but it could be a linker issue as the two constructors are aliased to the same address. The linker used here was lld.
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #2 from Pádraig Brady ---
The test case is in bug #70462.
Copying here...
g++ -std=c++11 -c -o t.o -x c++ - << EOF
struct Bar final
{
Bar();
};
Bar::Bar()
{}
EOF
$ nm t.o | grep C2 || echo ABI issue
[Bug c++/95428] New: ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428 Bug ID: 95428 Summary: ABI breakage for "base object constructor" for final classes Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: P at draigBrady dot com Target Milestone: --- The change to elide the "base object constructor" for final classes in bug #70462 introduces an ABI incompatibility with clang 9 at least. I'm seeing this with kuduraft-1.8 compiled with GCC 10, giving linker errors from clang 9.0.20190721 like: error: undefined symbol: kudu::consensus::OpId::OpId() Reverting the change in #70462 fixes the issue
[Bug c++/70462] Unnecessary "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70462 Pádraig Brady changed: What|Removed |Added CC||P at draigBrady dot com --- Comment #6 from Pádraig Brady --- This does introduce an ABI incompatibility. I'm seeing this with kuduraft-1.8 compiled with GCC 10, giving linker errors from clang 9.0.20190721 like: error: undefined symbol: kudu::consensus::OpId::OpId() Reverting this patch fixes the issue here.
[Bug c++/85400] invalid Local Dynamic TLS relaxation for symbol defined in method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85400 Pádraig Brady changed: What|Removed |Added CC||P at draigBrady dot com --- Comment #9 from Pádraig Brady --- Note this isn't sparc specific. I've also seen this when compiling CGAL 4.11 where gcc produced R_X86_64_DTPOFF32 relocations for thread_local vars which lld wasn't happy with at least. Applying this patch to 8.3.0 (on x86_64) fixed the issue. Seems this should be considered for 8.x branch. thanks
[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 --- Comment #9 from Pádraig Brady --- Facebook
[Bug c++/84726] [8 regression] Unnecessary lambda capture of constant variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84726
Pádraig Brady changed:
What|Removed |Added
CC||P at draigBrady dot com
--- Comment #4 from Pádraig Brady ---
Note bug 87185, mentions this snippet which is currently not handled by this
change:
void f() { const int i=0; [&]() noexcept {i;}; }
Specifically the "noexcept" causes non traversal of the statements, and thus
"i" remains captured in this example.
[Bug c++/87185] ICE in prune_lambda_captures()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87185 --- Comment #1 from Pádraig Brady --- Created attachment 44646 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44646=edit ICE avoidance patch and test case
[Bug c++/87185] New: ICE in prune_lambda_captures()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87185
Bug ID: 87185
Summary: ICE in prune_lambda_captures()
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: P at draigBrady dot com
Target Milestone: ---
bug 84726 introduced a regression in GCC 8.0 causing a compiler crash with:
void f() { const int i=0; [&]() noexcept {i;}; }
This crashes in prune_lambda_captures as we assume const_vars.get(var) in
lambda.c returns non NULL.
The reason it's NULL is that var_to_maybe_prune() is not a subset of
mark_const_cap_r(). Specifically is_constant_capture_proxy() returns false
in mark_const_cap_r(), but in var_to_maybe_prune() we return candidates
where is_normal_capture_proxy() is false.
Also "noexcept" is significant here since it stops traversal
down the statement list subtree, thus not populating const_vars.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #11 from Pádraig Brady ---
I agree that -Wno-... should never be promoted to an error as we see with:
$ echo 'int maint(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
-Wextra -Wno-error=return-type -
: In function ‘maint’:
:1:1: warning: control reaches end of non-void function [-Wreturn-type]
: At top level:
cc1: error: unrecognized command line option ‘-Wno-unknown-warning-option’
[-Werror]
cc1: all warnings being treated as errors
However it's worth noting that one can suppress the other warnings entirely
that trigger the promotion. This may be ok as a workaround for some:
$ echo 'int maint(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
-Wextra -Wno-return-type -
[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 --- Comment #7 from Pádraig Brady --- Have been running with these patches on an extremely large code base for the last few months, without issue
[Bug c++/81976] bad is_standard_layout/has_unique_object_representations results with a chain of empty bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81976 --- Comment #4 from Pádraig Brady --- According to the previous comment this depends on PR 82764 and the target milestone is 7.4
[Bug c++/84497] link errors with trivial external thread_local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497 --- Comment #1 from Pádraig Brady --- Created attachment 43479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43479=edit Proposed patch and testcase. This passes the full testsuite
[Bug c++/84497] New: link errors with trivial external thread_local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497
Bug ID: 84497
Summary: link errors with trivial external thread_local
variables
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: P at draigBrady dot com
Target Milestone: ---
In some cases extern thread_local vars will generate a reference
to a tls_init function, when there is none generated for the translation unit
defining the variable, essentially due to it being std::is_trivial.
This used to work with gcc-5.3.1 and gcc-6.3.1,
the reason being that they were less efficient and
always exported the tls_init function, even for these std::is_trivial vars.
With gcc-7 the tls_init function is not emitted for these types,
but there is a mismatch in the logic determining if the extern thread_local
should call the tls_init function.
Specifically, in the module local to the var
if DECL_NONTRIVIALLY_INITIALIZED_P is false
then the tls_init function is not generated.
However in a translation unit that references such
an extern tls variable and TYPE_NEEDS_CONSTRUCTING is true
then a non weak call to the tls_init function is generated,
resulting in a link error.
$ cat a.cpp
#include
struct Test { std::atomic x; };
thread_local Test t;
$ cap main.cpp
#include
struct Test { std::atomic x; };
extern thread_local Test t;
int main() {
return t.x.load();
}
$ g++ -std=c++11 a.cpp main.cpp
/tmp/ccvPDpE2.o: In function `TLS wrapper function for t':
main.cpp:(.text._ZTW1t[_ZTW1t]+0x5): undefined reference to `TLS init function
for t'
collect2: error: ld returned 1 exit status
[Bug c++/66971] thread_local with external linkage and constructor cannot be compiled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66971 Pádraig Brady changed: What|Removed |Added CC||P at draigBrady dot com --- Comment #2 from Pádraig Brady --- This is an issue with gcc 5.3.1 This is _not_ an issue with gcc 6.3.1 or gcc 7.3 I'm thinking this was addressed in the significant refactoring for bug #66653
[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 Pádraig Brady changed: What|Removed |Added CC||P at draigBrady dot com --- Comment #5 from Pádraig Brady --- Seeing this also with GCC 7.3. Will try proposed patches
[Bug libstdc++/61582] C++11 regex memory corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 Pádraig Brady changed: What|Removed |Added CC||P at draigBrady dot com --- Comment #20 from Pádraig Brady --- Any status update on this. GCC7 is looming... Thanks.
[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71913 --- Comment #15 from Pádraig Brady --- Actually it is backported to 5. So it would be good to set the "Target Milestone" to 5.5 so this is obvious from this bug and from the list of bugs fixed in 5.5 https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED_id=166767=FIXED_milestone=5.5 thanks!
[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71913 Pádraig Brady changed: What|Removed |Added CC||P at draigBrady dot com --- Comment #13 from Pádraig Brady --- It would be good to have this backported to the 5 branch. thanks
[Bug libgcc/78252] New: C++ demangler crashes with infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78252 Bug ID: 78252 Summary: C++ demangler crashes with infinite recursion Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: P at draigBrady dot com Target Milestone: --- Created attachment 39991 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39991=edit problematic symbol There is an infinite recursion in d_print_comp() in gcc-5 to gcc-6.2 at least. Simple reproducer attached
[Bug c++/71528] New: multiple extern reference declarations produce uninitialized access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71528
Bug ID: 71528
Summary: multiple extern reference declarations produce
uninitialized access
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: P at draigBrady dot com
Target Milestone: ---
This is a regression since 5.1 which works with clang and gcc 4.x
The issue is due to the redundant extern reference declaration,
which results in use of an unitialized reference. I.E. in this snippet,
x will have the NULL pointer rather than that of the "new int":
extern int& x;
int& x = *(new int);
int main() { return !(); }
// Comment out the following line for expected operation
extern int& x;
https://godbolt.org/g/dDDPnw
[Bug c++/70452] New: regression in C++ parsing performance between 4.9.3 and 5.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
Bug ID: 70452
Summary: regression in C++ parsing performance between 4.9.3
and 5.3.1
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: P at draigBrady dot com
Target Milestone: ---
Created attachment 38130
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38130=edit
test source generator
The attached shell script will generate a larger version
of the following:
constexpr bool static_str_equal(const char* x, const char* y) {
return (*x == 0 || *y == 0) ?
(*x == *y) :
((*x == *y) && static_str_equal(x + 1, y + 1));
}
int main(void)
{
static_assert( !static_str_equal("unspecified1", "unspecified"), "");
}
There is a significant slow down and increase in ram usage
compiling that, between gcc 4.9.3 and 5.3.1 (20151207):
$ sh cstrcmp.sh > cstrcmp.cpp
$ ~/gcc-4.9.3/g++ -ftime-report --std=gnu++11 cstrcmp.cpp
Execution times (seconds)
phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 1%) wall
1445 kB ( 1%) ggc
phase parsing : 0.91 (100%) usr 0.16 (100%) sys 1.08 (99%)
wall 149089 kB (99%) ggc
|name lookup: 0.03 ( 3%) usr 0.00 ( 0%) sys 0.02 ( 2%) wall
89 kB ( 0%) ggc
|overload resolution: 0.01 ( 1%) usr 0.00 ( 0%) sys 0.02 ( 2%) wall
628 kB ( 0%) ggc
preprocessing : 0.02 ( 2%) usr 0.05 (31%) sys 0.04 ( 4%) wall
2048 kB ( 1%) ggc
parser (global) : 0.02 ( 2%) usr 0.03 (19%) sys 0.08 ( 7%) wall
16178 kB (11%) ggc
parser function body: 0.87 (96%) usr 0.08 (50%) sys 0.96 (88%) wall
130855 kB (87%) ggc
TOTAL : 0.91 0.16 1.09
150594 kB
$ g++ -ftime-report --std=gnu++11 cstrcmp.cpp # default fedora version
Execution times (seconds)
phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
1408 kB ( 0%) ggc
phase parsing : 1.90 (99%) usr 0.26 (100%) sys 2.16 (100%)
wall 469089 kB (100%) ggc
phase opt and generate : 0.01 ( 1%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
53 kB ( 0%) ggc
|name lookup: 0.04 ( 2%) usr 0.00 ( 0%) sys 0.05 ( 2%) wall
93 kB ( 0%) ggc
|overload resolution: 0.01 ( 1%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
628 kB ( 0%) ggc
garbage collection : 0.20 (10%) usr 0.02 ( 8%) sys 0.21 (10%) wall
0 kB ( 0%) ggc
preprocessing : 0.01 ( 1%) usr 0.05 (19%) sys 0.08 ( 4%) wall
2048 kB ( 0%) ggc
parser (global) : 0.02 ( 1%) usr 0.04 (15%) sys 0.05 ( 2%) wall
16181 kB ( 3%) ggc
parser function body: 1.67 (87%) usr 0.15 (58%) sys 1.82 (84%) wall
450852 kB (96%) ggc
integrated RA : 0.01 ( 1%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
24 kB ( 0%) ggc
TOTAL : 1.91 0.26 2.17
470569 kB
Note I compiled the gcc 5 branch at 20160302 with the same results.
[Bug middle-end/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #9 from Pádraig Brady P at draigBrady dot com --- I'm not understanding completely TBH. Are flexible array members not special? Should the optimizations be restricted on access through the flexible array, because I presume most/all existing allocation code is not considering this alignment/padding issue. I certainly didn't notice any examples when looking into a workaround which I came up with independently. For my reference there are some notes RE GCC's divergence from C99 re padding and flexi arrays at: https://sites.google.com/site/embeddedmonologue/home/c-programming/data-alig
[Bug middle-end/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #4 from Pádraig Brady P at draigBrady dot com --- I should note that I worked around the issue by increasing the allocation for the structure on the heap up to a multiple of alignof(the_struct). See: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=49078a78
[Bug middle-end/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #7 from Pádraig Brady P at draigBrady dot com --- Created attachment 35852 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35852action=edit reproducer
[Bug c/66661] New: incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 Bug ID: 1 Summary: incorrect memory access in optimization with flexible array member Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: P at draigBrady dot com Target Milestone: --- On a heap allocated structure, direct access to flexible array members with optimization at -O2 can result in reads to memory beyond the heap object. I.E. gcc assumes alignment/padding is allocated when accessing flexible array members. The attached file is a summary of the code involved though does _not_ reproduce the issue. To reproduce one can: git clone --depth=1 git://git.sv.gnu.org/coreutils.git cd coreutils/ git checkout 53883af0 export LSAN_OPTIONS=exitcode=0 ./bootstrap ./configure --quiet \ make -j8 AM_CFLAGS='-fsanitize=address -fsanitize=undefined' src/chmod a+rx .. Also attached is the disassembly of the problematic code, and for comparison good code achieved by using a (char*) cast on the flexi array to force byte at a time access.
[Bug middle-end/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #3 from Pádraig Brady P at draigBrady dot com --- Created attachment 35851 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35851action=edit disassembly of forced good mem access
[Bug c/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #1 from Pádraig Brady P at draigBrady dot com --- Created attachment 35849 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35849action=edit summary code (does not reproduce issue)
[Bug middle-end/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #2 from Pádraig Brady P at draigBrady dot com --- Created attachment 35850 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35850action=edit disassembly of problematic mem access
[Bug c/53131] -Wlogical-op: ready for prime time in -Wall ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53131 Bug 53131 depends on bug 43772, which changed state. Bug 43772 Summary: Errant -Wlogical-op warning when testing limits https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/43772] Errant -Wlogical-op warning when testing limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772 Pádraig Brady P at draigBrady dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.2 Resolution|--- |FIXED Known to fail||4.6.3 --- Comment #23 from Pádraig Brady P at draigBrady dot com --- This is fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=187194 To see where it was first released we can quickly see the tags at: https://github.com/mirrors/gcc/commit/686369e8 Which indicates this was fixed as part of the 4.8.0 release. I've confirmed it's OK in gcc 4.8.2
[Bug c/36750] -Wmissing-field-initializers relaxation request
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750 --- Comment #1 from Pádraig Brady P at draigBrady dot com 2010-11-24 12:09:33 UTC --- A related thread: http://gcc.gnu.org/ml/gcc-bugs/1998-07/msg00031.html
[Bug c/43772] Errant -Wlogical-op warning when testing limits
--- Comment #3 from P at draigBrady dot com 2010-04-22 00:37 --- I've confirmed that this is _not_ an issue with the previous gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
[Bug c/4412] possible warning of logic errors not given
--- Comment #3 from P at draigBrady dot com 2010-04-22 00:40 --- Actually gcc 4.5 was the first version to mention -Wlogical-op in the release notes, but that option has actually been available since gcc 4.3.0 (5 Mar 2008) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4412
[Bug c/43772] Errant -Wlogical-op warning when testing limits
--- Comment #2 from P at draigBrady dot com 2010-04-17 17:40 --- Well the warning should at least change. However the logical operation itself is not an issue, so I think a warning should not be issued at all. I.E. if TOP and BOT are defined as a narrower range then we don't get a warning currently. When TOP and BOT do encompass the whole range then the compiler should just optimize out the conditional test without warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
[Bug c/43772] New: Errant -Wlogical-op warning when testing limits
/* compile with: gcc -Werror -Wlogical-op */
#include limits.h
# define BOT INT_MIN
# define TOP INT_MAX
int main(void)
{
int i=42;
i = (i BOTi TOP); //OK
i = (i = BOT+1 i = TOP-1); //OK
i = (i = BOTi = TOP); //Oops!
}
--
Summary: Errant -Wlogical-op warning when testing limits
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: P at draigBrady dot com
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=43772
[Bug c/4412] possible warning of logic errors not given
--- Comment #2 from P at draigBrady dot com 2010-04-15 09:00 --- GCC 4.5 was released yesterday with -Wlogical-op Thanks :) -- P at draigBrady dot com changed: What|Removed |Added CC||P at draigBrady dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4412
[Bug c/36750] New: -Wmissing-field-initializers relaxation request
While trying to compile coreutils with -Wextra,
I noticed many warnings due to automatic variables
initialized with { 0, }.
As I understand it, since C90 the above will initialize
[all members of] the type to that used in static scope,
including any unused padding space in the structure.
I.E. the following is valid:
mbstate_t m = { 0, };
int i = { 0, };
struct { int a; int b; } s = { 0, };
It would be great if gcc would relax this warning
when a trailing ',' is specified as that would be clear indication
that one wants to init all [other] elements to 0, and that
we haven't just forgotten some members.
At least the warning should be suppressed for the specific
most common case is where { 0, } is specified.
thanks.
--
Summary: -Wmissing-field-initializers relaxation request
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: P at draigBrady dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
