[Bug c/80868] "Duplicate const" warning emitted in `const typeof(foo) bar;`

[george.burgess.iv at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868

George Burgess IV  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from George Burgess IV  ---
> George, do you agree with closing this?

Sounds good to me.

Thanks everyone!

[Bug c/80868] New: "Duplicate const" warning emitted in `const typeof(foo) bar;`

[george.burgess.iv at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868

Bug ID: 80868
   Summary: "Duplicate const" warning emitted in `const
typeof(foo) bar;`
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: george.burgess.iv at gmail dot com
  Target Milestone: ---

Minimal test-case (repros with 7.1: https://godbolt.org/g/A2dTCP):

$ cat tc.c
const int i;
const typeof(i) j;

$ gcc -std=gnu89 -pedantic tc.c
2:17: warning: duplicate 'const' [-Wpedantic]
 const typeof(i) j;

Expected behavior: no duplicate const warning when there's only one `const` on
the decl for `j`.

While the current behavior is understandable, I think it would be good to relax
the warning in this case. typeof is often used in macros, so silencing this
warning isn't always trivial. Since typeof is also a language extension, I
don't believe that C89 6.5.3 (which I assume is the only reason GCC is emitting
these complaints in the first place) needs to apply here.

Thank you for your time :)

[Bug c/80868] "Duplicate const" warning emitted in `const typeof(foo) bar;`

[george.burgess.iv at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868

--- Comment #3 from George Burgess IV  ---
Thanks for the response!

From the standpoint of consistency, I agree.

My point is more that GCC isn't bound by the standard to be as strict with
`typeof`, and making an exception for `typeof` here would make it easier to use
in macros. I believe the gain in usability here outweighs the cost of having
this inconsistency.

(I also feel that this warning in general isn't useful when the only
"duplicate" const has been inferred from an expression, but it seems that
__auto_type has the same "duplicate const" behavior as typeof, so...)

[Bug c/83223] New: -fconserve-stack outlined code isn't dropped if it's logically unreachable

[george.burgess.iv at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83223

Bug ID: 83223
   Summary: -fconserve-stack outlined code isn't dropped if it's
logically unreachable
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: george.burgess.iv at gmail dot com
  Target Milestone: ---

GCC version: Reproed on godbolt's GCC trunk, 7.2, and 4.9.

Test case (godbolt link, if you'd prefer: https://godbolt.org/g/zxhjPV):

$ echo 'struct data { char foo[64]; };

void complain() __attribute__((warning("oh no!")));
void panic(const char *) __attribute__((noreturn, cold));
void *foo_real(void *, const void *);

void bar(struct data *ptr) {
  char tmp[sizeof(ptr->foo)];
  if (__builtin_object_size(ptr->foo, 0) >= sizeof(ptr->foo)) {
foo_real(ptr->foo, tmp);
  } else {
complain();
panic("");
  }
}

__auto_type v = bar;' | gcc -x c -fconserve-stack -O2 - -o /dev/null -c

: In function ‘bar.part.0’:
:12:5: warning: call to ‘complain’ declared with attribute warning: oh
no!

It looks like the outlined part sticks around if `bar`'s address is taken.
Normally, this isn't a problem. However, it can cause false-positives in code
that uses the warning or error attributes (as shown above).