possible bug in gcc compiler
I goofed and failed to put a space after the "case" word:
switch(nu){
case1: v1 =val;break;
case2: v2 =val;break;
case3: v3 =val;break;
case4: v4 =val;break;
}
gcc compiler showed NO errors or warnings. Execution of the code produced
incorrect results.
After I added a space(no other changes), everything compiled and ran perfectly.
switch(nu){
case 1: v1 =val;break;
case 2: v2 =val;break;
case 3: v3 =val;break;
case 4: v4 =val;break;
}
version info:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Thanks,
wl jackson
Sent with [ProtonMail](https://protonmail.com/) secure email.
Re: possible bug in gcc compiler
Note, this mailing list is for development of gcc, gcc-help
would be more appropriate.
On Fri, Mar 11, 2022 at 07:53:32PM +, Larry Jackson via Gcc wrote:
> I goofed and failed to put a space after the "case" word:
>
> switch(nu){
> case1: v1 =val;break;
> case2: v2 =val;break;
> case3: v3 =val;break;
> case4: v4 =val;break;
> }
That is valid code, case1: etc. is a user label, you could goto case1; to
reach it etc. So no wonder you don't get any diagnostics.
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
>
> Apple clang version 13.0.0 (clang-1300.0.29.30)
This means you even aren't using gcc at all but a different compiler.
Jakub
gcc-10-20220311 is now available
Snapshot gcc-10-20220311 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20220311/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision ba125ce7bdc6382ace5a89033f1a5ffa1f874071 You'll find: gcc-10-20220311.tar.xz Complete GCC SHA256=e7c323097ec7149dd5f62d1f5d10489c98871ba1dec144ac34149ffd6beb SHA1=e4f2caa8426a845ea67b8a50166db676be3dad87 Diffs from 10-20220304 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Is this a possible wrong-code issue?
Dear developers,
May I seek your confirmation to check whether the following program
triggers a true wrong-code issue or not? I don't want to make noise to the
bug repository so I'd like to seek your confirmation here first.
The following case makes GCC outputs differ under -O1 below vs -O1 above
optimization levels. Here is the program (s.c):
```
#include
union {
int32_t a;
uint16_t b;
} c;
static uint16_t *d = &c.b;
int32_t *e = &c.a;
int32_t **f = &e;
int32_t ***g = &f;
int32_t *h = &c.a;
int64_t i() {
int8_t j = 5;
*h = j;
***g = *d;
return 0;
}
int main() {
c.a = 1;
c.b = 1;
i();
printf("%d\n", c.a);
}
```
```
$gcc-trunk -O0 -w s.c ; ./a.out
5
$gcc-trunk -O1 -w s.c ; ./a.out
5
$gcc-trunk -O2 -w s.c ; ./a.out
1
$gcc-trunk -O3 -w s.c ; ./a.out
1
$gcc-trunk -Os -w s.c ; ./a.out
1
```
What surprised me was that almost all GCC versions produce different
results (please check more details here: https://godbolt.org/z/vTzhhvnGE).
Besides, clang also has the same issue with -O0 vs the above versions. So,
does this program have any UB? If not, I would like to file new bug reports
then. Thank you so much!
Best regards,
Haoxin
Re: Is this a possible wrong-code issue?
On Fri, Mar 11, 2022 at 8:21 PM Haoxin Tu via Gcc wrote:
>
> Dear developers,
>
> May I seek your confirmation to check whether the following program
> triggers a true wrong-code issue or not? I don't want to make noise to the
> bug repository so I'd like to seek your confirmation here first.
>
> The following case makes GCC outputs differ under -O1 below vs -O1 above
> optimization levels. Here is the program (s.c):
> ```
> #include
> union {
> int32_t a;
> uint16_t b;
> } c;
> static uint16_t *d = &c.b;
> int32_t *e = &c.a;
> int32_t **f = &e;
> int32_t ***g = &f;
> int32_t *h = &c.a;
> int64_t i() {
> int8_t j = 5;
> *h = j;
> ***g = *d;
> return 0;
> }
> int main() {
> c.a = 1;
> c.b = 1;
> i();
> printf("%d\n", c.a);
> }
> ```
>
> ```
> $gcc-trunk -O0 -w s.c ; ./a.out
> 5
> $gcc-trunk -O1 -w s.c ; ./a.out
> 5
> $gcc-trunk -O2 -w s.c ; ./a.out
> 1
> $gcc-trunk -O3 -w s.c ; ./a.out
> 1
> $gcc-trunk -Os -w s.c ; ./a.out
> 1
> ```
>
> What surprised me was that almost all GCC versions produce different
> results (please check more details here: https://godbolt.org/z/vTzhhvnGE).
> Besides, clang also has the same issue with -O0 vs the above versions. So,
> does this program have any UB? If not, I would like to file new bug reports
> then. Thank you so much!
Yes it looks like a strict aliasing issue though GCC does not
implement some aliasing rules sometimes with unions, see PR 82224.
Thanks,
Adnrew Pinski
>
>
> Best regards,
> Haoxin
Re: Is this a possible wrong-code issue?
Hi Andrew,
I see. Thanks for your speedy reply for clearing my confusion!
Have a great day!
Best regards,
Haoxin
Andrew Pinski 于2022年3月12日周六 12:33写道：
> On Fri, Mar 11, 2022 at 8:21 PM Haoxin Tu via Gcc wrote:
> >
> > Dear developers,
> >
> > May I seek your confirmation to check whether the following program
> > triggers a true wrong-code issue or not? I don't want to make noise to
> the
> > bug repository so I'd like to seek your confirmation here first.
> >
> > The following case makes GCC outputs differ under -O1 below vs -O1 above
> > optimization levels. Here is the program (s.c):
> > ```
> > #include
> > union {
> > int32_t a;
> > uint16_t b;
> > } c;
> > static uint16_t *d = &c.b;
> > int32_t *e = &c.a;
> > int32_t **f = &e;
> > int32_t ***g = &f;
> > int32_t *h = &c.a;
> > int64_t i() {
> > int8_t j = 5;
> > *h = j;
> > ***g = *d;
> > return 0;
> > }
> > int main() {
> > c.a = 1;
> > c.b = 1;
> > i();
> > printf("%d\n", c.a);
> > }
> > ```
> >
> > ```
> > $gcc-trunk -O0 -w s.c ; ./a.out
> > 5
> > $gcc-trunk -O1 -w s.c ; ./a.out
> > 5
> > $gcc-trunk -O2 -w s.c ; ./a.out
> > 1
> > $gcc-trunk -O3 -w s.c ; ./a.out
> > 1
> > $gcc-trunk -Os -w s.c ; ./a.out
> > 1
> > ```
> >
> > What surprised me was that almost all GCC versions produce different
> > results (please check more details here: https://godbolt.org/z/vTzhhvnGE
> ).
> > Besides, clang also has the same issue with -O0 vs the above versions.
> So,
> > does this program have any UB? If not, I would like to file new bug
> reports
> > then. Thank you so much!
>
> Yes it looks like a strict aliasing issue though GCC does not
> implement some aliasing rules sometimes with unions, see PR 82224.
>
> Thanks,
> Adnrew Pinski
>
> >
> >
> > Best regards,
> > Haoxin
>
