Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
Link at Compiler Explorer:
https://godbolt.org/z/b1oW566E5
I stumbled on this while compiling some invalid code during refactoring.
Test case has been reduced by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606
--- Comment #6 from Markus F.X.J. Oberhumer ---
@Andrew Pinksi Many thanks for cleaning up the bug case!
cvise (https://github.com/marxin/cvise) did correctly reduce the original from
~5 lines to 18 lines, but the result looked extremely st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606
--- Comment #1 from Markus F.X.J. Oberhumer ---
Created attachment 55999
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55999&action=edit
bug.cpp
Added attachment bug.cpp
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
Link at Compiler Explorer:
https://godbolt.org/z/EbPWr3qxx
I stumbled on this while compiling some invalid code during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #6 from Markus F.X.J. Oberhumer ---
Please note that I'm explicitly using "int_max" and not "INT_MAX", and I'd
appreciate if you could give me a link where the standard says this is
"ill-formed". Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #3 from Markus F.X.J. Oberhumer ---
Indeed.
And just for reference I had also reported this as clang bug in
https://github.com/llvm/llvm-project/issues/59195
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
C++ static_assert() does not honor -fwrapv, leading to compilation error
godbolt link: https://gcc.godbolt.org/z/Po8vc5Kex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #54 from Markus F.X.J. Oberhumer ---
Many thanks for finally fixing this!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29823
Markus F.X.J. Oberhumer changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64698
--- Comment #2 from Markus F.X.J. Oberhumer ---
Still a problem in 2021 with gcc-11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920
Markus F.X.J. Oberhumer changed:
What|Removed |Added
CC||markus at oberhumer dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #9 from Markus F.X.J. Oberhumer ---
[ Just for reference, created bug 95908 ]
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
[this issue has been extraced from bug 95903]
Link at Compiler Explorer: https://gcc.godbolt.org/z/mRf2kd
The function below does compute the address in 64 (and not in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #8 from Markus F.X.J. Oberhumer ---
Got it, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #6 from Markus F.X.J. Oberhumer ---
Thanks for the quick fix!
And no need to be grumpy, I'm just trying to nail down those pesky edge
cases...
As for ILP32, here is another suspicious test case, now only using just a
little bit more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #4 from Markus F.X.J. Oberhumer ---
Yes, ilp32 might be a corner case.
Still, clang-10 does create the expected code.
See https://gcc.godbolt.org/z/aEokbX for
clang-10 -target arm64_32-ios -O2 -fomit-frame-pointer -fwrapv
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #2 from Markus F.X.J. Oberhumer ---
Somewhat related: the same code compiled with arm64-gcc -mabi=ilp32 -frwapv
does miscompile *both* functions.
See https://gcc.godbolt.org/z/uxDAtx
Should I open a new issue for this?
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
Link at Compiler Explorer: https://godbolt.org/z/VgNLcX
The following 2 functions should generate identical code when using "-fwrapv",
but
the second function is missin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
--- Comment #5 from Markus F.X.J. Oberhumer ---
I see, many thanks for the clarification.
Still this is not nice from a usability perspective - why did the standard make
this a declaration instead of a statement?
Well, will revert back to using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
--- Comment #2 from Markus F.X.J. Oberhumer ---
This is somewhat unexpected, and I do not get any warnings when using clang:
$ clang-9 -Wdeclaration-after-statement test.c
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
gcc 9 under Fedora 31: gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
The small program below creates spurious warnings:
$ gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516
--- Comment #11 from Markus F.X.J. Oberhumer ---
Did you have a chance to backport this for 5.5 yet ?
Thanks,
Markus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516
--- Comment #8 from Markus F.X.J. Oberhumer ---
Richard, many thanks for finally fixing this issue.
Will there be a backport to 4.9.4 and/or 5.4 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516
--- Comment #3 from Markus F.X.J. Oberhumer ---
Just for reference, here is the expected result:
$ clang -target armv5-unknown-linux-gnu -marm -mfloat-abi=soft --version
clang version 3.5.1 (tags/RELEASE_351/final)
Target: armv5-unknown-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516
Markus F.X.J. Oberhumer changed:
What|Removed |Added
Known to work||4.3.3
--- Comment #2 from Mark
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
This could be related to bug 53431, though this report is about C and not C++.
Actually I had thought that "-save-temps" just dumps th
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Created attachment 34391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34391&action=edit
unaligned_load_bug.c to reproduce the problem.
arm: bad code generated => run time crash
- gcc 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
Markus F.X.J. Oberhumer changed:
What|Removed |Added
CC||markus at oberhumer dot
ion: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29823
--- Comment #10 from markus at oberhumer dot com 2006-01-27 18:03 ---
What is the status of this bug for gcc 4.0.3 ?
According to the thread at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00542.html it seems it has been
approved a while ago.
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from markus at oberhumer dot com 2005-12-01 06:06 ---
Created an attachment (id=10373)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10373&action=view)
wrong_args.c
Please try "gcc-4.0.2 -march=i386 -O3 -fomit-frame-pointer wrong_args.c"
--
h
nt: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
GCC host triplet: i386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
--
What|Removed |Added
Keywords||missed-optimization
Known to fail||4.0.0 4.1.0
Known to work|
D
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86_64-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
--- Additional Comments From markus at oberhumer dot com 2005-04-25 01:01
---
Ah, many thanks for the clarification. Still it's somewhat confusing that f1()
and g1() don't agree after inlining, but "undefined" probably means exactly
that...
--
http://
--- Additional Comments From markus at oberhumer dot com 2005-04-25 00:38
---
Is this optimization really legal in C/C++? Could some language lawyer look at
this (and check the output when compiling with -O3):
#include
int f1(int i) { return (i - 2) > i; }
int f2(int i) { return
--- Additional Comments From markus at oberhumer dot com 2005-01-21 02:14
---
Just a short update that the MIPS -mint64 option works again in mainline, so the
ICE reported here is back for both the 3.4 and 4.0 branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18744
--- Additional Comments From markus at oberhumer dot com 2005-01-21 02:10
---
What is the status of the latest patch from Giovanni ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
--- Additional Comments From markus at oberhumer dot com 2005-01-21 02:02
---
This seems to be fixed for 3.4 and 4.0 now, so the bug should be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17115
--- Additional Comments From markus at oberhumer dot com 2005-01-21 02:02
---
This seems to be fixed for 3.4 and 4.0 now, so the bug should be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17361
--- Additional Comments From markus at oberhumer dot com 2004-12-02 23:12
---
I'm reopening this against gcc-3.4.3 then, as the warning has vanished - a
possible regression against 3.2 and 3.3.
Note that gcc-3.4.3/gcc/c-decl.c talks about -Wtraditional, but even that
doesn'
--- Additional Comments From markus at oberhumer dot com 2004-12-02 21:28
---
Might this be a candidate for 3.3/3.4 backporting ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18759
Summary: error: static declaration of 'x' follows non-static
declaration
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned
dTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18759
--- Additional Comments From markus at oberhumer dot com 2004-11-30 21:18
---
Point taken. Still please note that gcc-3.4 MIPS -mint64 does work, so IMHO this
is not an unsupported target.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18745
--- Additional Comments From markus at oberhumer dot com 2004-11-30 21:04
---
Created an attachment (id=7644)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7644&action=view)
md5.h patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18745
x for gcc/include/md5.h
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
--- Additional Comments From markus at oberhumer dot com 2004-11-30 20:56
---
I'm not sure if this is really related to bug18442 - actually I've ported
current mainline to generate ILP64 code on AMD64, and __mode__(__SI__) works
without problems there.
But it's the inc
--- Additional Comments From markus at oberhumer dot com 2004-11-30 20:42
---
Created an attachment (id=7643)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7643&action=view)
Quick and dirty patch for gcc/cp/mangle.c .
This is just a quick patch, but I think this issue sh
--- Additional Comments From markus at oberhumer dot com 2004-11-30 20:39
---
Created an attachment (id=7642)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7642&action=view)
Testcase to reproduce the ICE.
Testcase to reproduce the ICE.
--
http://gcc.gnu.org/b
unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18744
--
What|Removed |Added
GCC host triplet||hppa-linux-gnu
GCC target triplet|hppa-unknown-linux-gnu |hppa-linux-gnu
http://gcc.gnu.org/bugzilla/sho
--- Additional Comments From markus at oberhumer dot com 2004-11-30 19:54
---
Just a short note that the testcase has a typo and should read
...
k |= f.a(r); k |= f.b(r); k |= f.c(r);
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
hr (>>) in templates
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18140
--- Additional Comments From markus at oberhumer dot com 2004-10-20 05:55 ---
Mayn thanks for the fix. May I also draw your attention to bug18071 (-Winline
does not respect -fno-default-inline), and I'd also appreciate comments on
bug18070 (Contradicting function attri
--- Additional Comments From markus at oberhumer dot com 2004-10-20 05:49 ---
Created an attachment (id=7383)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7383&action=view)
Test program, and log of compilation with various gcc versions.
--
http://gcc.gnu.org/b
s not respect -fno-default-inline
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
--- Additional Comments From markus at oberhumer dot com 2004-10-20 05:24 ---
Created an attachment (id=7382)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7382&action=view)
Test program, and log of compilation with various gcc versions.
--
http://gcc.gnu.org/b
nt: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18070
--- Additional Comments From markus at oberhumer dot com 2004-10-20 04:58 ---
Created an attachment (id=7381)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7381&action=view)
Test program and log of failure.
g++-3.4 and g++.4.0 fail. All other (including gcc-3.4 and gcc-4.
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-linux-gnu
http
61 matches
Mail list logo
