[Bug c/71538] New: Obvious optimization related to arrays aren't performed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71538
Bug ID: 71538
Summary: Obvious optimization related to arrays aren't
performed.
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sasho648 at gmail dot com
Target Milestone: ---
Consider this code:
#include
extern void f(int *p)
{
p = *((int (*)[6])p);
if(p == NULL)
printf("NULL");
}
It's obvious (at least for me) that p can't be possibly NULL because it's
assigned the value of pointer to the first element of array with 6 elements.
However the assembly output of this code for my native machine compiled on
linux (x86-64 - dumped using ida pro with general assembler for intel) is:
;f function
testrdi, rdi
jz short loc_400550
rep retn
; ---
align 10h
loc_400550:
mov edi, (offset format+4) ; "NULL"
xor eax, eax
jmp _printf
;f function end
As you see the branch where printf is called with "NULL" is still present in
the code although on theory it should never be reached.
I don't think there is requirement by the standard to disallow evaluation of
this expression (as opposed to for example *&p).
[Bug c/71538] Obvious optimization related to arrays aren't performed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71538 --- Comment #1 from sasho648 at gmail dot com --- The exact command used to compile this code was "gcc -O3 test.c" (as test.c containing the snippet above).
[Bug c/71538] Obvious optimization related to arrays aren't performed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71538 --- Comment #3 from sasho648 at gmail dot com --- But if it's NULL for the cast it'll invoke UB I believe. Shouldn't the optimizer assume that UB never occur?
[Bug c/71538] Obvious optimization related to arrays aren't performed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71538
--- Comment #4 from sasho648 at gmail dot com ---
More *shocking* example will be:
struct tx { int a[6], b[6]; } *f();
void (main)()
{
int *p = f()->b;
if(p == NULL)
printf("What?");
}
Compiling with "gcc -Ofast -c test.c -o a.out" will result in this assembly
output:
;main function
sub rsp, 8
xor eax, eax
callf
cmp rax, 0FFE8h
jz short loc_26
loc_21:
add rsp, 8
retn
; ---
loc_26:
pop rdx
mov edi, offset format ; "What?"
xor eax, eax
loc_2E:
jmp printf
;main function end
Keeping the printf branch which at least for me is amazing.
[Bug c/70093] New: Instancing function with VM type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093
Bug ID: 70093
Summary: Instancing function with VM type cases internal
compiler error in 'assign_stack_temp_for_type'.
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sasho648 at gmail dot com
Target Milestone: ---
Consider this example:
int main(int argc, char **argv)
{
struct {int _[argc];} fn() { }
fn(); //comment to trigger error on the next line
__typeof__(fn()) *p;
}
At the time local function 'fn' is instanced (either explicitly or using
'__typeof__') the following error is displayed:
internal compiler error: in assign_stack_temp_for_type, at function.c:793
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 --- Comment #1 from sasho648 at gmail dot com --- As a comment - I'll add that this feature looks fascinating and my personal opinion is that code like this should be allowed. I even suggest a way of allowing the return VM type access to the function parameters or locals. This way we could write self-contained functions which can directly return VLA (with size varying on each instance) without the need of the caller to maintain storage life-time (compared to 'malloc').
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 --- Comment #2 from sasho648 at gmail dot com --- The bug occurs at the most simple 'gcc test_code.c' command.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093
--- Comment #12 from sasho648 at gmail dot com ---
I would really love you guys if you actually could implement something like
this:
void fun(int a)
{
struct {int _[a];} fun();
}
In order to allow functions returning self-managed VLAs. What I'm proposing is
very simple. When a function is declared with the incomplete type 'void' - it
could be re-declared in it's definition scope with a VM type which will
complete it.
This isn't breaking any existing code nor introducing new complex syntax
(current compiler will emit error message for my above example stating
"conflicting types for 'fun'"). But it's providing us with a way for the return
type to access function local variables and so it's extending our possibilities
for writing code.
We can easily define the rules for such function definitions - first the
function re-declaration must be preceding any return statements. Second this
re-declaration syntax will be only valid for inside a 'void' function
definition and nowhere else. So if we have for example:
void fun(int a);
void fun(int a)
{
struct {int _[a];} fun();
}
The compiler should emit error for conflicting types as the 'fun' declaration
is of type 'void' and it's definition of VM type 'struct {int _[a];}'.
[Bug c/70418] New: VM structure type specifier in list of parameter declarations function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418 Bug ID: 70418 Summary: VM structure type specifier in list of parameter declarations function definition Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sasho648 at gmail dot com Target Milestone: ---
[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418
sasho648 at gmail dot com changed:
What|Removed |Added
Summary|VM structure type specifier |VM structure type specifier
|in list of parameter |in list of parameter
|declarations function |declarations within nested
|definition |function definition ices.
--- Comment #1 from sasho648 at gmail dot com ---
Consider this self-contained example:
main()
{
void func(int a, struct {int _[a];} v) {}
}
When compiled it Ices both on GCC 6.0 and GCC 4.8.2 .
[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418
--- Comment #2 from sasho648 at gmail dot com ---
Must be noted that such code must be valid and actually currently working fine
and as expected when the function is not nested. Eg.:
#include
extern void fp(int a, const struct {int _[a];} *b)
{
for(size_t i=0; i < sizeof(b->_) / sizeof(b->_[0]); ++i)
printf("%d ", b->_[i]);
printf("%zu\n", sizeof(b->_));
}
void f(int a, struct {int _[a];} b)
{
for(size_t i=0; i < sizeof(b._) / sizeof(b._[0]); ++i) //modify while
retaining the passed argument
b._[i] *= 9;
fp(a, &b); //prints 81 as many times as 'a'
}
main(int n, char **pp)
{
scanf("%i", &n);
struct {int _[n];} tmp;
for(int i; i < n; ++i)
tmp._[i] = 9;
((void (*)(int a, __typeof__(tmp) b))f)(n, tmp); //cast required as VM
types aren't equal in the case
fp(n, &tmp); //should print 9 as many times as 'n'
}
[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418 --- Comment #3 from sasho648 at gmail dot com --- currently *is* working fine and as expected when the function is not nested
[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418 --- Comment #4 from sasho648 at gmail dot com --- The full ice message is: test_bug_0.c: In function ‘main’: test_bug_0.c:24:1: internal compiler error: Segmentation fault 0xb482ef crash_signal ../../gcc/gcc/toplev.c:335 0xbda96a get_frame_type ../../gcc/gcc/tree-nested.c:208 0xbda96a get_chain_decl ../../gcc/gcc/tree-nested.c:314 0xbddde9 get_chain_decl ../../gcc/gcc/tree-nested.c:826 0xbddde9 get_nonlocal_debug_decl ../../gcc/gcc/tree-nested.c:830 0xbde1d8 convert_nonlocal_reference_op ../../gcc/gcc/tree-nested.c:909 0xde8ac2 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/gcc/tree.c:11531 0x8d6960 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gcc/gimple-walk.c:201 0x8d6edc walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gcc/gimple-walk.c:584 0x8d70c8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gcc/gimple-walk.c:51 0x8d6f82 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gcc/gimple-walk.c:594 0x8d70c8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gcc/gimple-walk.c:51 0x8d6f82 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gcc/gimple-walk.c:594 0x8d70c8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gcc/gimple-walk.c:51 0xbda371 walk_body ../../gcc/gcc/tree-nested.c:573 0xbda3c8 walk_function ../../gcc/gcc/tree-nested.c:584 0xbda3c8 walk_all_functions ../../gcc/gcc/tree-nested.c:649 0xbe2562 lower_nested_functions(tree_node*) ../../gcc/gcc/tree-nested.c:3133 0x7738b6 cgraph_node::analyze() ../../gcc/gcc/cgraphunit.c:631 0x776e33 analyze_functions ../../gcc/gcc/cgraphunit.c:1086
[Bug c/94692] New: Zero-sized arrays shouldn't require a complete element type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94692
Bug ID: 94692
Summary: Zero-sized arrays shouldn't require a complete element
type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sasho648 at gmail dot com
Target Milestone: ---
Because they don't reserve any storage.
union db { union dd dd[0]; unsigned char udb; signed char sdb; } *ptr;
union dd { union db db[0]; unsigned long udd; signed long sdd; }
data = *(ptr+0x3B)->dd;
[Bug c/88523] New: Allow slick and sick incomplete variably modified function return type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88523
Bug ID: 88523
Summary: Allow slick and sick incomplete variably modified
function return type.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sasho648 at gmail dot com
Target Milestone: ---
Consider the following code:
main()
{
auto a(char a, struct t { char t[a] } t)
{
}
}
It currently ICEs and has no actual purpose but what if we use this opportunity
to introduce:
main()
{
auto struct t main(char a, struct t { char t[a] } t)
{
return t;
}
}
The above code will complete the composite type of main on each instance after
its arguments were evaluated.
[Bug c/88523] Allow slick and sick variably modified function return type constructed on each instance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88523 sasho648 at gmail dot com changed: What|Removed |Added Summary|Allow slick and sick|Allow slick and sick |variably modified function |variably modified function |return type created on |return type constructed on |instance. |each instance. --- Comment #1 from sasho648 at gmail dot com --- Allow this behavior only on functions without linkage like the one above.
[Bug c/88523] Allow slick and sick variably modified function return type constructed on each instance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88523 --- Comment #2 from sasho648 at gmail dot com --- I'm referring to the function without linkage main. The one with linkage that is declared at file scope has no relation at all with my proposal - I'm just using the opportunity to introduce as few identifiers as possible.
[Bug c/88523] Allow slick and sick variably modified function return type constructed on each instance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88523 --- Comment #3 from sasho648 at gmail dot com --- The included phrase in the standard would read something like: If an incomplete structure type is the composite type of a function - it's allowed to be completed inside its prototype in which case a X function is created which type will be evaluated on each instance after its argument values are evaluated.
[Bug c/88532] New: variable has initializer but incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
Bug ID: 88532
Summary: variable has initializer but incomplete type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sasho648 at gmail dot com
Target Milestone: ---
Consider the following snippet:
main()
{
struct t a = (sizeof(struct t { }), a);
}
It currently fails with variable 'a' has initializer but incomplete type. The
above code works fine with clang.
[Bug c/88532] variable has initializer but incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532 --- Comment #2 from sasho648 at gmail dot com --- Related points from the standard: 6.7.9 p3 states: The type of the entity to be initialized shall be an array of unknown size or a complete object type that is not a variable length array type. However 6.2.5 p22 says that a structure or union type of unknown content is an incomplete type. It is completed, for all declarations of that type, by declaring the same structure or union tag with its defining content later in the same scope. @Andrew Pinski I don't think the sizeof operator introduces a new identifiers scope.
