https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95152
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95152
--- Comment #4 from Fredrik Hederstierna
---
Stripped down example:
File :
typedef struct {
int var;
} info_t;
extern void *_data_offs;
void test()
{
info_t *info = ((void *)((void *)1) + ((unsigned int)&_data_offs));
my_func(info->var
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
Target Milestone: ---
Created attachment 49156
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49156&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96847
--- Comment #2 from Fredrik Hederstierna
---
Ok thanks, just wanted also to clarify that the size increase was not actually
due to changing array sizes, but it was difference between GCC-9.2 and GCC-10.2
for the _same_ array lengths. So GCC-10.2
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fredrik.hederstie...@securitas-direct.com
Created attachment 25729
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25729
Example file with warnings for unreacha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50997
--- Comment #2 from Fredrik Hederstierna
2011-11-07 07:33:19 UTC ---
Ok, I didn't know that checks for unreachable-code was removed.
Though I would like to know about the background/discussion behind this
decision - do anyone have a link or refe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50997
--- Comment #3 from Fredrik Hederstierna
2011-11-07 21:11:13 UTC ---
Ok, answer to myself. I found the patch:
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00169.html
I think the patch is very unfortunate, if I knew I should have objected.
It's
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fredrik.hederstie...@securitas-direct.com
Created attachment 27123
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27123
Example code with functions returning w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923
--- Comment #4 from Fredrik Hederstierna
2012-04-10 12:52:36 UTC ---
Maybe it have advantages to have a "pointer-deref" analysis pass rather than a
"point-to" analysis pass. Then GCC could warn only if the pointer is being
dereferenced for real,
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
Target Milestone: ---
Created attachment 44164
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44164&action=edit
Example file
Starting with GCC-8.1.0 the code gen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85880
--- Comment #1 from Fredrik Hederstierna
---
Created attachment 44165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44165&action=edit
Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85880
--- Comment #2 from Fredrik Hederstierna
---
All old GCC < 8
---
Disassembly of section .text:
:
0: 2000movsr0, #0
2: 4770bx lr
0004 :
4: b500push{lr}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85880
--- Comment #4 from Fredrik Hederstierna
---
Ok, you are probably right. I just was surprised that all GCC 4,5,6,7 gave same
result, but something changed with 8. But you are right, its unpredictable
results since its undefined. I practice it ga
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
Target Milestone: ---
Created attachment 46284
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46284&action=edit
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #1 from Fredrik Hederstierna
---
Stripped down the testcase some, this version gives +35% code size increase.
With gcc-8.2.0 it was 536 bytes, when gcc-9.1.0 gives 724 bytes (+188 bytes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #2 from Fredrik Hederstierna
---
Created attachment 46297
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46297&action=edit
Stripped down testcase, gives +35% code size increase
Stripped down testcase, gives +35% code size incr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #5 from Fredrik Hederstierna
---
I use patched sources from
http://gcc.hederstierna.com/csibe
I think you could download and try it out.
Toolchain I build with
https://github.com/fredrikhederstierna/buildbuddy
Otherwise I think the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #8 from Fredrik Hederstierna
---
Ok, thannks, I will try to have a look at it later tonight (I'm at my regular
job now ;-)
Thanks/Fredrik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #9 from Fredrik Hederstierna
---
I did the test suggested, the results was as follows
A. gcc-8.2.0
B. gcc-9.1.0
C. gcc-9.1.0 -fno-jump-tables
D. gcc-9.1.0 patched "max_ratio_for_size = 2"
Overall CSiBE was
A: 2 413 510 bytes
B: 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #10 from Fredrik Hederstierna
---
Tested also gcc-9.1.0 "max_ratio_for_size = 1" just out of curiosity
results was similar compared to gcc-8.2.0:
Overall CSiBE was
2 417 695 bytes (+4185 bytes, +0.17%)
Example file CSiBE "vsprint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #16 from Fredrik Hederstierna
---
Still you cannot reach code size as gcc-8.3.0 ? So something in new switch-case
compilation generates larger code still?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #22 from Fredrik Hederstierna
---
Was "max_ratio_for_size = 2" as default changed?
Also changing this to "1" did not by far reach size of gcc-8.2 unfortunately,
I guess we are assuming this code growth depends on other regression fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #6 from Fredrik Hederstierna
---
Created attachment 46397
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46397&action=edit
Some more patterns
Looking into this I found some more places where it seems to be non-optimal
code, ma
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
Target Milestone: ---
Created attachment 46441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46441&action=edit
test.c
When compili
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9663
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9663
--- Comment #12 from Fredrik Hederstierna
---
Created attachment 46458
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46458&action=edit
range ran through preprocessor using -E -P
I'm not sure if this is what you wanted, but here is file st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #38 from Fredrik Hederstierna
---
I guess this 'meta-bugreport' have become lightly fuzzy with all kinds of CSiBE
code size increase issues,
so maybe better to identify these issues on a more detailed level and create
smaller specifi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #39 from Fredrik Hederstierna
---
Created attachment 38036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38036&action=edit
CSiBE results for arm thumb1 and thumb2 code generation for various toolchains.
CSiBE results for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
--- Comment #4 from Fredrik Hederstierna
---
I've investigated this issue some further, and I believe the problem might be
that we allow too many iterations when doing complete peeling of loops on ARM.
The heuristics in "tree-ssa-loop-ivcanon.c
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
Target Milestone: ---
Created attachment 38049
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38049&action=edit
test_switch.c
Starting w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #41 from Fredrik Hederstierna
---
Ok, I will mark this as resolved if noone object.
I tried the ip-fixed again on master, but the gain was very little, so I do not
think this is any way forward currently.
I created this new separat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341
--- Comment #1 from Fredrik Hederstierna
---
Created attachment 38051
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38051&action=edit
switch.c
Added additional slightly larger test case that also show problems for
cortex-m0 and thumb1.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
Target Milestone: ---
Created attachment 38058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38058&action=edit
inttostr.c
Code size increase on master for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
--- Comment #6 from Fredrik Hederstierna
---
Thanks for your analysis on this. One comment on this 'complaint', it's not
only about size - in my example the compiler uses 2 more regs push and pop, and
several more instructions, so I think causin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
--- Comment #15 from Fredrik Hederstierna
---
Created attachment 38185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38185&action=edit
tok.c
I took another example for CSiBE and stripped it down. I'm not 100% sure it is
the exact same is
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
Target Milestone: ---
Created attachment 41814
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41814&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #20 from Fredrik Hederstierna
---
Simplest fix might be something like?
- else
+ else if (access->grp_no_warning)
so we do not always suppress warnings, but name will look funny for temp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #21 from Fredrik Hederstierna
---
Started with fix for PR 43347 to not warn on artificial aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #23 from Fredrik Hederstierna
---
Ah ok, yes I think you are right. The check could possibly be in "cp/typeck.c"
and "cp/tree.c"? but I'm not familiar with this C++ parsing code.
Interesting that this code gets warning:
B* foo(A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524
--- Comment #3 from Fredrik Hederstierna
---
Isn't AddressSanitizer checking in run-time? There are several tools that can
find this bugs in runtime I think like Valgrind, but I need to find this at
compile-time.
I use embedded arm-eabi target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81625
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81625
--- Comment #5 from Fredrik Hederstierna
---
I tried build several AVR toolchains from 3.4.6 to 7.1.0 and I can confirm that
code size increases as described. I suspect for AVR this might start already
from 3.x -> 4.x
Checked Bug 17549 - [4.0 R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
--- Comment #5 from Fredrik Hederstierna
---
Still same in GCC-7.1.0.
I analyzed using -fdump-tree-cunroll-details
void test_iter_6(void)
{
int i;
for (i = 0; i < 6; i++) {
data[i] = i;
}
}
The function was generated "test_iter_6":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
--- Comment #6 from Fredrik Hederstierna
---
Same thing for x86, not only ARM:
bash# gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
bash# gcc -c test.c -Os --param max-completely-peel-times=5
bash# objdump -dath test.o
Di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341
--- Comment #8 from Fredrik Hederstierna
---
Could it be something in tree-ssa-forwprop pass?
This pass is executed 4 times in -Os, and starting with GCC-4.9 it seems like
statements that seems to generate instructions that are hard to eliminat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341
--- Comment #10 from Fredrik Hederstierna
---
Can it be related to some missing code hoisting in eg. combiner or gcse?
I found this old PR 11832 on similar issue, can it be related, or have a common
solution?
Bug 11832 - Optimization of common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
We have problems when trying to switch from GCC 4.8.3 to GCC 4.9.0 (arm-eabi
thumb1 for arm966e-s core) due to significant code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #1 from Fredrik Hederstierna
---
Created attachment 32980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32980&action=edit
Toolchain build script.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #2 from Fredrik Hederstierna
---
Created attachment 32981
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32981&action=edit
Toolchain build script 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #3 from Fredrik Hederstierna
---
Created attachment 32982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32982&action=edit
Makefile for examples.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #4 from Fredrik Hederstierna
---
Created attachment 32983
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32983&action=edit
Example source 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #5 from Fredrik Hederstierna
---
Created attachment 32984
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32984&action=edit
Example source 2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
Fredrik Hederstierna changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #23 from Fredrik Hederstierna
---
Thanks for your patch, I tried it out, and it solves the small example fine,
the code now is similar to GCC 4.8 for this particular example.
Though when I ran the full CSiBE benchmark, the code size
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
Target Milestone: ---
Created attachment 36308
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36308&action=edit
Examp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #25 from Fredrik Hederstierna
---
I've but this last example in a separate issue:
Bug 67507 - Code size increase with -Os from GCC 4.8.x to GCC 4.9.x for ARM
thumb1.
I've also previously put this one that causes size increase
Bug 672
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #14 from Fredrik Hederstierna
---
Created attachment 34916
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34916&action=edit
CSiBE benchmark with gnu89, updates with newer trunk as reference.
I added attachment with new CSiBE m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #9 from Fredrik Hederstierna
---
Created attachment 33866
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33866&action=edit
Simple patch to exclude use of ip
Simple patch that make it possible to optionally exclude use of ip fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #10 from Fredrik Hederstierna
---
Created attachment 33867
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33867&action=edit
Size benchmark gcc 4.8, gcc 4.9 and trunk.
Added updated CSiBE benchmark for GCC 4.8, GCC 4.9 and trun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #21 from Fredrik Hederstierna
---
I filed this previously, maybe its duplicate
Bug 61578 - Code size increase for ARM thumb compared to 4.8.x when compiling
with -Os
BR Fredrik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #8 from Fredrik Hederstierna
---
Created attachment 33544
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33544&action=edit
CSiBE test results size
Attached some tests with CSiBE v2.1.1 for arm-eabi.
It seems like the results a
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fredrik.hederstie...@securitas-direct.com
Target Milestone: ---
When compiling thumb1 code for size with -Os some loops can be larger due to
complete peeling.
Example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
--- Comment #1 from Fredrik Hederstierna
---
Created attachment 36185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36185&action=edit
Example files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
--- Comment #3 from Fredrik Hederstierna
---
Created attachment 36186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36186&action=edit
Dump from tree-ssa-loop-ivcanon.c
In the function iter_6 it seems like it will keep cost 5 when unrolli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #17 from Fredrik Hederstierna
---
Created attachment 36201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36201&action=edit
Simple example giving +50% code size increase compared gcc-4.8.5 and gcc-5.2.0
Simple example giving +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #18 from Fredrik Hederstierna
---
Created attachment 36202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36202&action=edit
Disasm for -mthumb also, code size increase was +48%.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #19 from Fredrik Hederstierna
---
I'm not sure why bug 59535 was closed, same problem might still exist, quote:
> Zhenqiang Chen 2014-09-03 06:17:44 UTC
>
> Here is a small case to show lra introduces one more register copy (tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #21 from Fredrik Hederstierna
---
Great, thanks!
Just a note as you are looking into this,
neither GCC 4.8.x nor GCC 5.2.x produces the optimal code I think for this
case,
isn't it better to load result register r0, instead of go ov
: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fredrik.hederstie...@securitas-direct.com
I had some problems with memcpy() when copying unaligned integers for ARM.
For intel target it worked fine, and I concluded that if I overloaded gcclib
weak memcpy-reference I had the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46483
--- Comment #1 from Fredrik Hederstierna
2010-11-15 14:42:48 UTC ---
Created attachment 22399
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22399
Script to build arm-elf toolchain
iority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fredrik.hederstie...@securitas-direct.com
Assume we want to declare a pointer to constant data.
This can be done by e.g.
int const * ptrToConst1;
But C/C++ also accepts:
//identical to:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46765
--- Comment #1 from Fredrik Hederstierna
2010-12-02 13:34:26 UTC ---
Created attachment 22602
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22602
example file for const.
iority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fredrik.hederstie...@securitas-direct.com
It is valid to return a void-function, or cast a variable to void, from a
void-function.
This makes some sense, in particular in C++ since we might have a tem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #2 from Fredrik Hederstierna
2010-12-02 14:42:35 UTC ---
Ok, but also f1() declares that it does not return any parameters, still it can
return (void)0;
I'm not saying either is wrong, I just though it should be consistent.
If its o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #4 from Fredrik Hederstierna
2010-12-02 15:55:05 UTC ---
Yes, I agree its EURGH.
I guess its not preferred to make C++ template-alike code in C.
I think its worth avoid stuff like:
#ifdef BLAH_BLAH_BLAH
#define RETURN_TYPE_C_TEMPLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341
--- Comment #7 from Fredrik Hederstierna
---
Tested with GCC 6.2 and still same behaviour.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
--- Comment #19 from Fredrik Hederstierna
---
Tested GCC-6.2, still same behavior.
81 matches
Mail list logo
