[Bug c++/71943] New: Wreturn-type when combining destructor + return + __noreturn__ function

2016-07-20 Thread sigmaepsilon92 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71943

Bug ID: 71943
   Summary: Wreturn-type when combining destructor + return +
__noreturn__ function
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sigmaepsilon92 at gmail dot com
  Target Milestone: ---

The following code gives me a Wreturn-type warning:

extern void die(void) __attribute__((__noreturn__));

struct AutoDec{
~AutoDec() { }
};

bool testfn(void)
{
AutoDec ad;
return false;
((0) ? (void)0 : die());
}

I'm not sure how these three lines are related but if I remove any of it(the
struct, the return which causes unreachable code, or the condition around
die()) the warning goes away.

this happens on both ARM and x86/x64, using the following g++ options:
g++ -Wall -c -o /tmp/test.o /tmp/test.cpp

[Bug c/106929] New: declaration in switch-case doesn't fail since GCC 11

2022-09-13 Thread sigmaepsilon92 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106929

Bug ID: 106929
   Summary: declaration in switch-case doesn't fail since GCC 11
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sigmaepsilon92 at gmail dot com
  Target Milestone: ---

this code should fail because declarations inside switch-cases aren't allowed
without {}:
void fn(int a) {
switch (a) {
case 0:
int c = 5;
break;
}
}

Starting with gcc 11 this doesn't fail to compile anymore though.
The expected error message would look like this:

: In function 'fn':
:4:13: error: a label can only be part of a statement and a declaration
is not a statement
4 | int c = 5;
  | ^~~
Compiler returned: 1

[Bug c/106929] declaration in switch-case doesn't fail since GCC 11

2022-09-13 Thread sigmaepsilon92 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106929

--- Comment #4 from Michael Zimmermann  ---
Interesting, but IMO it should still fail if you specify an older C standard
e.g. using `-std=c89`, but currently it doesn't.