[Bug debug/91929] missing inline subroutine information in build using sin/cos
rguenther at suse dot de
gcc-bugzilla@gcc.gnu.org
Mon Oct 21 10:12:00 GMT 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 18 Oct 2019, dimhen at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929
>
> Dmitry G. Dyachenko <dimhen at gmail dot com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |dimhen at gmail dot com
>
> --- Comment #12 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
> I see new warnings -Wuninitialized and -Wmaybe-uninitialized after r276993
>
> r276992 no warnings
> r276993 warnings
>
> $ cat x_3.i
> int *a;
> int b, d;
>
> int g() {
> int *c;
> int e[6];
> int f = 1;
> if (0)
> goto cd;
> c = 0;
> for (; d; d++)
> *e = 1 ^ *(c + 1);
> if (f)
> for (b = 0;;)
> a[0] = e[b];
> cd:
> return 0;
> }
>
> $ ~/arch-gcc/gcc_276993/bin/gcc -fpreprocessed -O2 -Wall -c x_3.i
>
> x_3.i: In function ‘g’:
> x_3.i:15:15: warning: ‘e[0]’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> 15 | a[0] = e[b];
> | ~^~~
If d is zero then e[0] will be loaded uninitialized. PRE exposes
this to the uninit machinery which previously gave up for loops
by commoning e[b] with the set in the loop plus inserting
a load from e[0] on the path not coming from the loop. I guess
previously the uninit pass didn't emit warnings for the load
because it had no location.
> $ cat x.i
> typedef struct {
> int a[0];
> } c;
> typedef struct {
> c d;
> } * e;
> e a;
> void f(void);
> void f() {
> int c[1];
> for (;;) {
> unsigned long d[0];
> int b, g, h = b = h;
> unsigned long *e = d;
> for (; g; ++g)
> e[g] = 0;
> *a->d.a = *c;
> }
> }
>
> $ ~/arch-gcc/gcc_276993/bin/gcc -fpreprocessed -O2 -Wall -c x.i
> x.i: In function ‘f’:
> x.i:17:13: warning: ‘c[0]’ is used uninitialized in this function
> [-Wuninitialized]
> 17 | *a->d.a = *c;
> | ~~~~~~~~^~~~
This is the same (and g is not initialized here as well)
More information about the Gcc-bugs
mailing list