Pelles C > Announcements
Release Candidate for version 11.00 is now available
Pelle:
--- Quote from: frankie on July 30, 2021, 09:46:44 PM ---
--- Quote from: Pelle on July 30, 2021, 09:00:29 PM ---This is happening on the intermediate code, after front end parsing and possible simplification of expressions. Intrinsic functions in it's enabled/intrinsic form are handled differently, but otherwise a call is always either call(...) or tmp = call (...). Both call forms/statements are assumed to have side-effects, and can't be removed, unless the call site is unreachable and the code is optimized. A single comparison is another type of intermediate statement: a larger C condition like "a > 0 && b > 0" will result in two comparison statements jumping to different true/false labels. All intermediate statements can have associated source coordinates for warnings and errors.
--- End quote ---
Thanks for the confirmation, that's what I supposed should be the correct behavior.
--- Quote from: Pelle on July 30, 2021, 09:10:55 PM ---This uses the SSA form. Apparently you are not optimizing, which would have been good to know, to get this warning. I'm not sure how useful this is anymore. Anyway, not optimizing at all will leave some artifacts in the SSA form (unreferenced SSA variables, PHI-functions). These can probably be removed fairly easy, but if the promise is to not optimize at all this is at least borderline...
--- End quote ---
You're right I'm not optimizing, and after optimizations the warning doesn't appear anymore.
What's impressive indeed is the optimization workout. The following snippet don't produce the waning anyway:
--- Code: ---bool build_regs(int n)
{
REGS *regs = calloc(sizeof(REGS), n);
if (!regs)
return false;
if(!init_regs(regs))
{
if (n<100)
free(regs);
printf("blah blah blah\n");
return false;
}
if (!check(regs))
{
free(regs);
return false;
}
return true;
}
--- End code ---
Notwithstanding the difference in the two if's it could understand that the two free() calls are mutually exclusive. :o
Really good job indeed 8)
--- End quote ---
Looks like a selective "dead code elimination", for non-optimized code, can silence the most obvious warnings (without changing much else). This is now added to the compiler.
Pelle:
--- Quote from: Marco on July 31, 2021, 06:00:16 PM ---Hi Pelle. Today I was adding some new functions to my personal library. I changed the parameter type of a function but I forgot to change the same type parameter also in the prototype of that function. Due to this, the compiler showed the following fatal error:
--- Code: ---fatal error: Internal error: composite_type().
--- End code ---
A very simple example to replicate the error:
--- Code: ---void foo(int, void *); <-- definition
void foo(int n, int *p) <-- function
{
n = 0;
}
--- End code ---
There is no need to call the 'foo' function somewhere in the code. The error occurs during the compilation. Just to let you know.
--- End quote ---
This is wrong, but the error could be better. I will see what I can do...
frankie:
--- Quote from: Pelle on August 01, 2021, 08:11:57 PM ---
--- Quote from: frankie on July 30, 2021, 09:46:44 PM ---
--- Quote from: Pelle on July 30, 2021, 09:00:29 PM ---This is happening on the intermediate code, after front end parsing and possible simplification of expressions. Intrinsic functions in it's enabled/intrinsic form are handled differently, but otherwise a call is always either call(...) or tmp = call (...). Both call forms/statements are assumed to have side-effects, and can't be removed, unless the call site is unreachable and the code is optimized. A single comparison is another type of intermediate statement: a larger C condition like "a > 0 && b > 0" will result in two comparison statements jumping to different true/false labels. All intermediate statements can have associated source coordinates for warnings and errors.
--- End quote ---
Thanks for the confirmation, that's what I supposed should be the correct behavior.
--- Quote from: Pelle on July 30, 2021, 09:10:55 PM ---This uses the SSA form. Apparently you are not optimizing, which would have been good to know, to get this warning. I'm not sure how useful this is anymore. Anyway, not optimizing at all will leave some artifacts in the SSA form (unreferenced SSA variables, PHI-functions). These can probably be removed fairly easy, but if the promise is to not optimize at all this is at least borderline...
--- End quote ---
You're right I'm not optimizing, and after optimizations the warning doesn't appear anymore.
What's impressive indeed is the optimization workout. The following snippet don't produce the waning anyway:
--- Code: ---bool build_regs(int n)
{
REGS *regs = calloc(sizeof(REGS), n);
if (!regs)
return false;
if(!init_regs(regs))
{
if (n<100)
free(regs);
printf("blah blah blah\n");
return false;
}
if (!check(regs))
{
free(regs);
return false;
}
return true;
}
--- End code ---
Notwithstanding the difference in the two if's it could understand that the two free() calls are mutually exclusive. :o
Really good job indeed 8)
--- End quote ---
Looks like a selective "dead code elimination", for non-optimized code, can silence the most obvious warnings (without changing much else). This is now added to the compiler.
--- End quote ---
Very good. thanks.
Navigation
[0] Message Index
[*] Previous page
Go to full version