[Bug c/93181] New: -Wuninitialized fails to warn about uninitialized value; -Wmaybe-uninitialized should also warn.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93181
Bug ID: 93181
Summary: -Wuninitialized fails to warn about uninitialized
value; -Wmaybe-uninitialized should also warn.
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: intvnut at gmail dot com
Target Milestone: ---
GCC 4.1.2 previously warned about p being used uninitialized in code such as
the following:
#include
void ub_express(int);
void test(void);
struct foo {
int count;
};
extern struct foo a, b;
struct foo a, b;
void ub_express(int x) {
struct foo *p;
if (x == 1) {
p =
}
if (x == 2) {
p =
}
p->count++;
}
void test(void) {
for (int i = 0; i < 3; ++i) {
ub_express(i);
}
}
https://godbolt.org/z/xd8vsL
:21: warning: 'p' is used uninitialized in this function
With every later version of GCC I tried at Godbolt's compiler explorer up
through 9.2.0 and trunk (and the few I tried locally on my workstation), it no
longer warns.
Furthermore, 4.1.2 only warns if I retain the function 'test', as that
definitely includes a code path where 'p' is used uninitialized.
It seems like GCC should warn about ub_express() even if 'test' isn't present
according to the description for -Wmaybe-uninitialized. It's a similar code
pattern to the one that appears in the documentation to -Wmaybe-uninitialized:
{
int x;
switch (y)
{
case 1: x = 1;
break;
case 2: x = 4;
break;
case 3: x = 5;
}
foo (x);
}
I've tagged this as 9.1.0 and "C" as this oversight is present in that version,
but I see similar behavior across many GCC versions and in both the C and C++
compilers.
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #6 from intvnut at gmail dot com 2008-04-29 03:42 --- (In reply to comment #5) It should be possible to have an alternate implementation in libgcc2.c by means of just selecting on a proper architecture define or the size of the argument mode. I see where it would go in libgcc2.c, but I don't know the appropriate architecture defines to key off of, since I really do know nothing about GCC's internals. Since the method I used above is likely to be a strict improvement over the table driven method on 32-bit and 64-bit targets, is it enough to, say, key off of #if W_TYPE_SIZE == 32 and #if W_TYPE_SIZE == 64? Is there some documentation I can read to know how best to propose a patch? (I'm just a motivated user, not a compiler developer, in case you couldn't tell.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #4 from intvnut at gmail dot com 2008-04-25 12:29 --- Is there a mechanism to provide different implementations based on the target (or in this case, class of target)? The byte count approach certainly is more appropriate for 8-bit targets, sure, but what about the rest of us? How are targets handled that might have this as an instruction? FWIW, I'd be happy to write a 32-bit version to complement the 64-bit version I provided with my report if there's a way to build a different implementation based on the class of target being compiled for. That way, embedded 8/16 bit, 32 bit and 64 bit targets can each have a version that's appropriate for that class of target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug c/36041] New: Speed up builtin_popcountll
The current __builtin_popcountll (and likely __builtin_popcount) are fairly
slow as compared to a simple, short C version derived from what can be found in
Knuth's recent publications. The following short function is about 3x as fast
as the __builtin version, which runs counter to the idea that __builtin_XXX
provides access to implementations that are exemplars for a given platform.
unsigned int popcount64(unsigned long long x)
{
x = (x 0xULL) + ((x 1) 0xULL);
x = (x 0xULL) + ((x 2) 0xULL);
x = (x 0x0F0F0F0F0F0F0F0FULL) + ((x 4) 0x0F0F0F0F0F0F0F0FULL);
return (x * 0x0101010101010101ULL) 56;
}
This version has the additional benefit that it omits the lookup table that the
current builtin version uses.
I measured the above function vs. __builtin_popcountll with a loop like the
following:
t1 = clock();
for (j = 0; j 100; j++)
for (i = 0; i 1024; i++)
pt = popcount64(data[i]);
t2 = clock();
printf(popcount64 = %d clocks\n, t2 - t1);
...where data[] is a u64 that's preinitialized.
I'll attach the exact source I used, which also includes two other possible
implementations of popcountll.
--
Summary: Speed up builtin_popcountll
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: intvnut at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug c/36041] Speed up builtin_popcountll
--- Comment #1 from intvnut at gmail dot com 2008-04-25 00:36 --- Created an attachment (id=15529) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15529action=view) Popcount sample implementations These implementations are derived from insights in Henry S. Warren's Hacker's Delight and Knuth's recent fascicle regarding boolean tips and tricks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #2 from intvnut at gmail dot com 2008-04-25 00:39 --- When run on my Opteron 280 system, the four separate implementations give the following run times: popcount64_1 = 1313 clocks popcount64_2 = 648 clocks popcount64_3 = 374 clocks popcount64_4 = 549 clocks As one can see, the popcount64_3 implementation is over 3.5x the speed of the __builtin_popcountll implementation. -- intvnut at gmail dot com changed: What|Removed |Added CC||intvnut at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
