[Bug c/98047] New: assignment does not drop qualifier as observed by typeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98047
Bug ID: 98047
Summary: assignment does not drop qualifier as observed by
typeof
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
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 left operand would have after lvalue conversion."
void f(void)
{
volatile int xv;
extern int x;
extern typeof(xv = 1) x;
}
[Bug c/98029] [11 Regression] volatile triggers incorrect "warning: right-hand operand of comma expression has no effect [-Wunused-value]" since r11-5188-g32934a4f45a72144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98029 Martin Uecker changed: What|Removed |Added CC||uecker at eecs dot berkeley.edu --- Comment #2 from Martin Uecker --- It seems with the changes to lvalue conversion the code volatile int x; int i; (x = 1, i = 2); gets rewritten to ((x = 1, 1), i = 2) and then build_compound_expr introduces the spurious warning. There is a another possible related issue: volatile int x; (x, 0); warns about warning: variable ‘x’ set but not used
[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion
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 32934a4f45a72144cdcd0712cc294fe88c36f13d C: Drop qualifiers during lvalue conversion [PR97702] 2020-11-20 Martin Uecker gcc/ * gimplify.c (gimplify_modify_expr_rhs): Optimizie NOP_EXPRs that contain compound literals. gcc/c/ * c-typeck.c (convert_lvalue_to_rvalue): Drop qualifiers. gcc/testsuite/ * gcc.dg/cond-constqual-1.c: Adapt test. * gcc.dg/lvalue-11.c: New test. * gcc.dg/pr60195.c: Add warning.
[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion
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
unqualified type, for whatever reason).
#define T1(x) ((void)0,x)
#define T2(x) (+x)
#define T3(x) (-x)
#define T4(x) (1?x:x)
#define T5(x) (*&(x))
#define T6(x) ((const int)x)
int f(void)
{
const int j = 0;
__typeof__(T6(j)) i = 0;
i = 0;
return i;
}
[Bug c/97702] New: comma operator does not drop qualifiers during lvalue conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702 Bug ID: 97702 Summary: comma operator does not drop qualifiers during lvalue conversion Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal 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. This is incorrect as lvalue conversion should remove the qualifier (ISO C17 6.3.2.1p2). I assume this is a residual problem from the time where GCC had generalized lvalues.
[Bug translation/96159] atomic creates incorrect code for possible isaligned struct
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
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 seems to imply that __atomic_load is
supposed to work for all types. It also compiles
without warning.
typedef struct { float re; float im; } foo_t;
int foo_align(void)
{
foo_t x;
return _Alignof(x);
}
foo_t foo_load(foo_t* x)
{
foo_t r;
__atomic_load(x, , __ATOMIC_SEQ_CST);
return r;
}
assembler:
foo_align:
mov eax, 4
ret
foo_load:
movqxmm0, QWORD PTR [rdi]
ret
[Bug translation/96159] New: atomic creates incorrect code for possible isaligned struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159 Bug ID: 96159 Summary: atomic creates incorrect code for possible isaligned struct Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu Target Milestone: ---
[Bug c/93949] [8/9/10 Regression] Register const local var will not compile since r0-58166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93949 Martin Uecker changed: What|Removed |Added CC||uecker at eecs dot berkeley.edu --- Comment #4 from Martin Uecker --- One other simply fix would be to simple remove the error in varasm.c. This then allows also register variables without __asm at file scope but does not seem to have any other negative effect. Register at file scope is also already diagnosed by the C FE when using --pedantic, so at some point this was supposed to work I think. There is a proposal for C2x which would allow register at file scope: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2486.htm
[Bug sanitizer/91707] New: spurious stringop-overflow warning with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91707
Bug ID: 91707
Summary: spurious stringop-overflow warning with
-fsanitize=undefined
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
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 at
gcc dot gnu.org
Target Milestone: ---
Created attachment 46854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46854=edit
test case
With recent GCC versions from git there is a spurious warning
when the undefined behavior sanitizer is used.
$ ../gcc_build_clean/gcc/xgcc -B ../gcc_build_clean/gcc -Wall -O2
-fsanitize=undefined -c strop.c
In function ‘real_from_complex_dims’,
inlined from ‘md_test’ at strop.c:14:2:
strop.c:7:11: warning: writing 8 bytes into a region of size 0
[-Wstringop-overflow=]
7 | odims[0] = 2;
| ~^~~
$ ../gcc_build_clean/gcc/xgcc --version
xgcc (GCC) 10.0.0 20190907 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat strop.c
extern void md_copy_dims(unsigned int D, long odims[D], const long idims[D]);
extern void md_test(unsigned int D, const long idims[D]);
static void real_from_complex_dims(unsigned int D, long odims[D + 1], const
long idims[D])
{
odims[0] = 2;
md_copy_dims(D, odims + 1, idims);
}
void md_test(unsigned int D, const long idims[D])
{
long dimsR[D + 1];
real_from_complex_dims(D, dimsR, idims);
long strsR[D + 1];
(void)strsR;
return;
}
[Bug c/91038] New: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91038
Bug ID: 91038
Summary: internal compiler error: in gimplify_var_or_parm_decl,
at gimplify.c:2786
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: 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 happens with older versions (test 6.3.0)
but also on very recent versions:
lbm_broken.c: In function ‘zouhe_left’:
lbm_broken.c:17:51: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:2786
17 | (*({ struct lbm __x = D2Q9; ((const int(*)[9][__x.D])__x.DQ);
}))[1][0];
|~~~^~
0x61ace0 gimplify_var_or_parm_decl
../../gcc/gcc/gimplify.c:2786
0xacc50f gimplify_compound_lval
../../gcc/gcc/gimplify.c:2906
0xac5710 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:12677
0xacbb20 internal_get_tmp_var
../../gcc/gcc/gimplify.c:609
0xac6696 get_initialized_tmp_var(tree_node*, gimple**, gimple**, bool)
../../gcc/gcc/gimplify.c:663
0xac6696 gimplify_save_expr
../../gcc/gcc/gimplify.c:6013
0xac6696 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:13025
0xac5f54 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:12828
0xac5ba9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:13465
0xac5ba9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:13465
0xacc646 gimplify_compound_lval
../../gcc/gcc/gimplify.c:3007
0xac5710 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:12677
0xac9706 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6754
0xaca46e gimplify_bind_expr
../../gcc/gcc/gimplify.c:1395
0xac6882 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:12926
0xac9706 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6754
0xacb19b gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:13944
0xacb577 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:14088
0x939b87 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:667
0x93c910 analyze_functions
../../gcc/gcc/cgraphunit.c:1126
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug tree-optimization/86884] aggressive loop optimization and effective type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86884
Martin Uecker changed:
What|Removed |Added
CC||uecker at eecs dot berkeley.edu
--- Comment #1 from Martin Uecker ---
Here are some additional comments, which may help to analyze this (or not).
The optimization also works without struct Y, the initialization, and the
memcpy in which case the example is not undefined by itself (see case 1 below).
From a C language point of view (I can't comment about GIMPLE), the
optimization seems legal as from the access p->c one can infer the effective
type. In case 3, one cannot infer the effective type and gcc also does not
optimize this case. Case 2 is interesting. I think using p->c to construct a
pointer to c implies that the storage at p must have correct effective type,
but I am not entirely sure. For strlen, case 1 and case 2 are optimized, but
not case 3. (tested with gcc from recent git).
#include
#include
#include
struct X { int i; char c[4]; int j;};
void f(struct X *p)
{
int n = 0;
#if 1
// case 1
while (p->c[n]) // uncond. abort
++n;
#else
#if 1
// case 2
char* pc = p->c; // no uncond. abort
#else
// case 3
char* pc = (char*)p + offsetof(struct X, c); // no uncond. abort
#endif
while (pc[n])
++n;
#endif
if (n < 7)
abort();
}
void g(struct X *p)
{
int n = 0;
#if 1
// case 1
n = strlen(p->c); // uncond. abort
#else
#if 1
// case 2
char* pc = p->c; // uncond. abort
#else
// case 3
char* pc = (char*)p + offsetof(struct X, c); // no uncond. abort
#endif
n = strlen(pc);
#endif
if (n < 7)
abort();
}
[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address
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 understanding: Is there a reason why it is important that zero-sized
objects should sometimes have the same address? I am wondering because I think
zero-sized arrays would make sense to allow in C (it sometimes makes
programming edge cases simpler in numerical code) and at the same time I think
it might be a nice principle to require that all unique objects existing at the
same time should also have a unique address.
[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address
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 not sure if there's anything to fix - Joseph?
>
> Note that for global unique addresses you can use global objects of size 1,
> like a char object. Not sure why you think using a GNU extension is
> superior?
It makes it clear in a nice way that these variables are not used to store
information.
(In reply to Jakub Jelinek from comment #2)
> Zero sized objects of course can have the same address and always had.
> Just in your testcase the comparison used to be optimized away before
> r218462.
> If you hide it from the optimizers, like with:
> int *p = a;
> int *q = b;
> asm ("" : "+r" (p), "+r" (q));
> if(p == q) __builtin_abort ();
> you'll get aborts all the way to r104500 (oldest revision I have around).
Oh well, so this was simply an incorrect optimization.
[Bug c/84046] New: global zero-sized objects may have same address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046 Bug ID: 84046 Summary: global zero-sized objects may have same address Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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 zero-sized objects may have the same address. The only real use of such objects at a global level is to create unique addresses, but this newer behavior breaks this use case. Older versions of gcc (tested: 4.8 and 4.9) seem to always assign different addresses and the same is true for clang 3.8 and 3.9.
[Bug c/69193] New: ICE: openmp + nested function + VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69193 Bug ID: 69193 Summary: ICE: openmp + nested function + VLA Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c 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, I tried to use a nested function which produces the following ICE (recent gcc build from git): $ ~/src/gcc_build/gcc/xgcc -fopenmp -B ~/src/gcc_build/gcc/ test.c test.c: In function ‘md_parallel_loop_r’: test.c:19:11: internal compiler error: in lower_rec_input_clauses, at omp-low.c:4756 #pragma omp parallel for firstprivate(pos) ^~~ 0x9fb368 lower_rec_input_clauses ../../gcc/gcc/omp-low.c:4756 0x9fd62e lower_omp_taskreg ../../gcc/gcc/omp-low.c:14972 0x9ef4c6 lower_omp_1 ../../gcc/gcc/omp-low.c:16345 0x9ef4c6 lower_omp ../../gcc/gcc/omp-low.c:16484 0x9ef15d lower_omp_1 ../../gcc/gcc/omp-low.c:16337 0x9ef15d lower_omp ../../gcc/gcc/omp-low.c:16484 0x9f6489 execute_lower_omp ../../gcc/gcc/omp-low.c:16522 0x9f6489 execute ../../gcc/gcc/omp-low.c:16559 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug lto/64373] New: [5 regression] ICE with lto related to variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64373 Bug ID: 64373 Summary: [5 regression] ICE with lto related to variably modified type Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal 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) test.c: In function ‘a’: test.c:8:8: warning: passing argument 2 of ‘b’ from incompatible pointer type [-Wincompatible-pointer-types] b(10, p + i); ^ test.c:2:13: note: expected ‘float (*)[(sizetype)(L)]’ but argument is of type ‘float *’ extern void b(int L, float (*data)[L]); ^ test.c:9:1: internal compiler error: Speicherzugriffsfehler } ^ 0xafb59f crash_signal ../../gcc_git/gcc/toplev.c:358 0x9e3327 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc_git/gcc/tree.h:2892 0x9e3327 tree_is_indexable ../../gcc_git/gcc/lto-streamer-out.c:153 0x9ece57 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1332 0x9ef8c8 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:654 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9ef8c8 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:654 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9ef8c8 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:654 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9ef8c8 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:654 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9ef016 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:603 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9eea95 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:522 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9eea95 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:522 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9edc97 DFS::DFS(output_block*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:495 0x9ee6cd lto_output_tree(output_block*, tree_node*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1552
