[Bug lto/64373] New: [5 regression] ICE with lto related to variably modified type

2014-12-21 Thread uecker at eecs dot berkeley.edu
Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu Created attachment 34309 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34309action=edit minimized test case xgcc (GCC) 5.0.0 20141221 (experimental

[Bug c/69193] New: ICE: openmp + nested function + VLA

2016-01-08 Thread uecker at eecs dot berkeley.edu
Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu Target Milestone: --- Created attachment 37269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37269=edit test case Trying to get openmp to make a private copy of an array passed to a function

[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address

2018-01-26 Thread uecker at eecs dot berkeley.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046 --- Comment #3 from Martin Uecker --- (In reply to Richard Biener from comment #1) > Confirmed. I think the C language doesn't specify this since zero-sized > arrays are a GNU extension and thus in C no zero-sized types/decls exist? > > So

[Bug c/84046] New: global zero-sized objects may have same address

2018-01-25 Thread uecker at eecs dot berkeley.edu
: c Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu Target Milestone: --- Created attachment 43246 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43246=edit test case With newer versions of gcc (tested: 6.3.0 and recent git) global z

[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address

2018-01-27 Thread uecker at eecs dot berkeley.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046 --- Comment #5 from Martin Uecker --- (In reply to Jakub Jelinek from comment #4) > If you want aggregate with size 1 and isn't used to store information, use > typedef struct { char : 1; } zero; > instead. Yes, thank you. But for my

[Bug tree-optimization/86884] aggressive loop optimization and effective type

2018-08-11 Thread uecker at eecs dot berkeley.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86884 Martin Uecker changed: What|Removed |Added CC||uecker at eecs dot berkeley.edu

[Bug c/91038] New: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2786

2019-06-30 Thread uecker at eecs dot berkeley.edu
: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu Target Milestone: --- Created attachment 46536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46536=edit reduced test case This happ

[Bug sanitizer/91707] New: spurious stringop-overflow warning with -fsanitize=undefined

2019-09-09 Thread uecker at eecs dot berkeley.edu
Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin

[Bug c/93949] [8/9/10 Regression] Register const local var will not compile since r0-58166

2020-02-29 Thread uecker at eecs dot berkeley.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93949 Martin Uecker changed: What|Removed |Added CC||uecker at eecs dot berkeley.edu

[Bug translation/96159] New: atomic creates incorrect code for possible isaligned struct

2020-07-10 Thread uecker at eecs dot berkeley.edu
Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu Target Milestone: ---

[Bug translation/96159] atomic creates incorrect code for possible isaligned struct

2020-07-10 Thread uecker at eecs dot berkeley.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159 --- Comment #2 from Martin Uecker --- Clang produces a call to __atomic_load. Also here is a godbolt link: https://godbolt.org/z/39PE1G

[Bug translation/96159] atomic creates incorrect code for possible isaligned struct

2020-07-10 Thread uecker at eecs dot berkeley.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159 --- Comment #1 from Martin Uecker --- On x86-64 the following struct has alignment 4 but gcc creates a single mov instruction which according to my understanding may fail to be atomic when it crosses a cache line boundary. Documentation

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

2020-11-25 Thread uecker at eecs dot berkeley.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702 --- Comment #6 from Martin Uecker --- https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=32934a4f45a72144cdcd0712cc294fe88c36f13d Author Martin Uecker Fri, 20 Nov 2020 06:21:40 + (07:21 +0100) commit

[Bug c/98029] [11 Regression] volatile triggers incorrect "warning: right-hand operand of comma expression has no effect [-Wunused-value]" since r11-5188-g32934a4f45a72144

2020-11-28 Thread uecker at eecs dot berkeley.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98029 Martin Uecker changed: What|Removed |Added CC||uecker at eecs dot berkeley.edu

[Bug c/98047] New: assignment does not drop qualifier as observed by typeof

2020-11-28 Thread uecker at eecs dot berkeley.edu via Gcc-bugs
Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu Target Milestone: --- In the following example, the qualifier should be dropped according to 6.5.15.1 "the type of an assignment expression is the type the

[Bug c/97702] New: comma operator does not drop qualifiers during lvalue conversion

2020-11-03 Thread uecker at eecs dot berkeley.edu via Gcc-bugs
Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu Target Milestone: --- The following code const int x = 0; typeof(0, x) y = 0; y = x; yields an error because '(0, x)' and then 'y' is const qualified

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

2020-11-03 Thread uecker at eecs dot berkeley.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702 --- Comment #2 from Martin Uecker --- Thank you for the explanation. Interestingly, from the following list, the only example that removes the cast is the last one (which seems correct as ISO C specifies casts to produce a value with the