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
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=edit
Exam
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
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=9663
--- Comment #12 from Fredrik Hederstierna
---
Created attachment 46458
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46458=edit
range ran through preprocessor using -E -P
I'm not sure if this is what you wanted, but here is file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9663
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
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=edit
test.c
When compiling this sim
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=edit
Some more patterns
Looking into this I found some more places where it seems to be non-optimal
code, maybe
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
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 #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
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 #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 #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
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=edit
Stripped down testcase, gives +35% code size increase
Stripped down testcase, gives +35% code size increase.
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).
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=edit
Testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85880
--- Comment #4 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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 unpredi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85880
--- Comment #2 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
All old GCC < 8
---
Disassembly of section .text:
:
0: 2000movsr0, #0
2: 4770b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85880
--- Comment #1 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
Created attachment 44165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44165=edit
Makefile
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=edit
Example file
Starting with GCC-8.1.0 the code generat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81625
--- Comment #5 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81625
Fredrik Hederstierna <fredrik.hederstie...@securitas-direct.com> changed:
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524
--- Comment #3 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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 t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #23 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #21 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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 #20 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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
Fredrik Hederstierna <fredrik.hederstie...@securitas-direct.com> changed:
What|Removed |Added
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=e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
Fredrik Hederstierna <fredrik.hederstie...@securitas-direct.com> changed:
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
--- Comment #6 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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-comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
--- Comment #5 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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++) {
da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341
--- Comment #10 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341
--- Comment #8 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
--- Comment #19 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
Tested GCC-6.2, still same behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341
--- Comment #7 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
Tested with GCC 6.2 and still same behaviour.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
--- Comment #15 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
Created attachment 38185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38185=edit
tok.c
I took another example for CSiBE and stripped it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
--- Comment #6 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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 a
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=edit
inttostr.c
Code size increase on master for ARM target compa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341
--- Comment #1 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
Created attachment 38051
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38051=edit
switch.c
Added additional slightly larger test case that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #41 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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 a
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=edit
test_switch.c
Starting with GCC-4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
--- Comment #4 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #39 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
Created attachment 38036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38036=edit
CSiBE results for arm thumb1 and thumb2 code g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #38 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
I guess this 'meta-bugreport' have become lightly fuzzy with all kinds of CSiBE
code size increase issues,
so maybe better to identify these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
Fredrik Hederstierna <fredrik.hederstie...@securitas-direct.com> changed:
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #25 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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 prev
: 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=edit
Example code
Start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #23 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #21 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #19 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #18 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 36202
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36202action=edit
Disasm for -mthumb also, code size increase was +48%.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #17 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 36201
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36201action=edit
Simple example giving +50% code size increase compared gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
--- Comment #3 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 36186
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36186action=edit
Dump from tree-ssa-loop-ivcanon.c
In the function iter_6
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
fredrik.hederstie...@securitas-direct.com ---
Created attachment 36185
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36185action=edit
Example files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #14 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 34916
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34916action=edit
CSiBE benchmark with gnu89, updates with newer trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #9 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 33866
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33866action=edit
Simple patch to exclude use of ip
Simple patch that make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #10 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 33867
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33867action=edit
Size benchmark gcc 4.8, gcc 4.9 and trunk.
Added updated CSiBE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #8 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 33544
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33544action=edit
CSiBE test results size
Attached some tests with CSiBE v2.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #21 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
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
: 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
fredrik.hederstie...@securitas-direct.com ---
Created attachment 32980
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32980action=edit
Toolchain build script.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #2 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 32981
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32981action=edit
Toolchain build script 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #3 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 32982
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32982action=edit
Makefile for examples.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #4 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 32983
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32983action=edit
Example source 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #5 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com ---
Created attachment 32984
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32984action=edit
Example source 2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com changed:
What|Removed |Added
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com changed:
What|Removed |Added
CC
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923
--- Comment #4 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50997
--- Comment #3 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com 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
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 unreachable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50997
--- Comment #2 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com 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
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: int const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46765
--- Comment #1 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com 2010-12-02 13:34:26 UTC ---
Created attachment 22602
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22602
example file for const.
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 template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #2 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46766
--- Comment #4 from Fredrik Hederstierna
fredrik.hederstie...@securitas-direct.com 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
: 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
fredrik.hederstie...@securitas-direct.com 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
81 matches
Mail list logo
