Re: [Mspgcc-users] code size
Hi, I'm also getting the same errors, which varies a bit depending on optimization level. With -O3: Keccak-simple.c: In function ‘crypto_hash_keccakc512_simple’: Keccak-simple.c:91:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ XBD_APP.c: In function ‘FRW_msgRecHand’: XBD_APP.c:545:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ At top level: lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] XBD_HAL.c: In function ‘XBD_countStack’: XBD_HAL.c:235:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ At top level: lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] With -Os: XBD_APP.c: In function ‘FRW_msgTraHand’: XBD_APP.c:606:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ XBD_APP.c: In function ‘FRW_msgRecHand’: XBD_APP.c:545:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ At top level: lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] XBD_debug.c: In function ‘XBD_debugOutHex32Bit’: XBD_debug.c:29:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ XBD_debug.c: In function ‘XBD_debugOutHexByte’: XBD_debug.c:12:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ XBD_crc.c: In function ‘crc16buffer’: XBD_crc.c:27:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ XBD_HAL.c: In function ‘XBD_countStack’: XBD_HAL.c:235:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ XBD_HAL.c: In function ‘XBD_paintStack’: XBD_HAL.c:220:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] } ^ At top level: lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] I don't have a reduced test case, but I can release my code. I've posted it at: http://knzl.me/compile.tar.gz , with gcc command line used in compile.sh On 2014-12-16 14:39:24 Eric Price price@sm... wrote: On Tue, 16 Dec 2014 10:47:30 + Nicholas Clifton nickc@... wrote: Hi Eric, there are still some bugs, for example if linking a lot of code
Re: [Mspgcc-users] code size
On Wed, 17 Dec 2014 17:04:08 +
Nicholas Clifton ni...@redhat.com wrote:
Hang on - you say that you are getting this message during
*linking* ? The error message comes from the compiler, not the
linker, so why is it turning up in the linker's output ? Do you have
LTO enabled ? (If you do, does disabling LTO make the problem go
away ?)
Yes, The error only happens with -flto enabled, disabling -flto makes
the error disappear.
(but NOT using -flto also increases the resulting code size by a quite
significant factor, so that's unfortunately not a solution)
No other optimization flags are needed to reproduce the error. No
linker flags need to be enabled explicitly either.
I could reproduce the issue by simply compiling all files with:
msp430-elf-gcc -Wall -g -c -O0 -flto file.c -o file.o
(this does not cause any errors)
and then linking them with
msp430-elf-gcc *.o -o file.elf
(this does cause the errors)
Once the errors start appearing, there are always LOTS of them,
but they always have one of the following forms:
variant 1:
myfile.c: In function ‘xy’:
myfile.c:88:1: warning: visibility attribute not supported in this
configuration; ignored [-Wattributes]
}
^
where the error always point to the line with the closing bracket at the
end of a function.
This is repeated for many functions throughout the codebase (hundreds)
but interestingly not all functions used. I could not find out why this
would appear for one function and not for another.
for example I haven't seen this appear at the end of main() {}
variant 2:
At top level:
lto1: warning: visibility attribute not supported in this configuration;
ignored [-Wattributes]
lto1: warning: visibility attribute not supported in this configuration;
ignored [-Wattributes]
lto1: warning: visibility attribute not supported in this configuration;
ignored [-Wattributes]
lto1: warning: visibility attribute not supported in this configuration;
ignored [-Wattributes]
lto1: warning: visibility attribute not supported in this configuration;
ignored [-Wattributes]
... (repeated a hundred times)
cheers
Eric
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] code size
Hi Eric,
warning: visibility attribute not supported in this configuration;
ignored [-Wattributes]
The problem is, I was only able to reproduce it when linking together
a relatively large code base with lots of functions, and only when many
of these functions were actually being used.
Hang on - you say that you are getting this message during *linking* ?
The error message comes from the compiler, not the linker, so why is it
turning up in the linker's output ? Do you have LTO enabled ? (If you
do, does disabling LTO make the problem go away ?)
Also, if you add -Wno-attributes to the command line, does the problem
go away ? (I assume that you are not otherwise using unsupported
attributes, so disabling the warning would not be a big issue). Just a
thought - I know that this is not a real solution to the problem.
Any attempt to simplify the test case by reducing code, or even
just calls to that code - which was the first thing I tried, made the
error magically disappear. That happened regardless of which function
calls were eliminated.
I hate these kinds of bugs. :-{
Are there any clues as to where the compiler/linker thinks that the
visibility attribute is being used ?
Cheers
Nick
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] code size
Hi Eric, there are still some bugs, for example if linking a lot of code together the compiler suddenly issues a lot of warning: visibility attribute not supported in this configuration; ignored [-Wattributes] warnings for no apparent reason in random places in the code. That sounds interesting. Could you send me a small testcase to reproduce the problem ? Or better yet file a bug report (with the FSF or TI) including the testcase, and then I can look into it. Cheers Nick -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] code size
On Tue, 16 Dec 2014 10:47:30 +
Nicholas Clifton ni...@redhat.com wrote:
Hi Eric,
there are still some bugs, for example if linking a lot of code
together the compiler suddenly issues a lot of
warning: visibility attribute not supported in this configuration;
ignored [-Wattributes]
warnings for no apparent reason in random places in the code.
That sounds interesting. Could you send me a small testcase to
reproduce the problem ? Or better yet file a bug report (with the
FSF or TI) including the testcase, and then I can look into it.
Cheers
Nick
The only test case I have so far that reproduces it contains a lot of
proprietary code that I unfortunately cannot share here. I yet have to
create an artificial simplified test case.
The problem is, I was only able to reproduce it when linking together
a relatively large code base with lots of functions, and only when many
of these functions were actually being used.
Any attempt to simplify the test case by reducing code, or even
just calls to that code - which was the first thing I tried, made the
error magically disappear. That happened regardless of which function
calls were eliminated.
That way I couldn't pinpoint any specific code as the culprit, it
rather looks like the error only appears when a certain code complexity
is surpassed. I'd guess maybe because it overwhelms the linker garbage
collector or makes it switch optimization schemes internally or
something. It's hard to tell without more detailed knowledge of whats
going on linker-internally.
Assume the following program was triggering the bug (with function1
and 2 implemented in previously compiled and now to be linked in object
files)
void function1(void);
void function2(void);
int main() {
function1();
function2();
exit 0;
}
then these two simplified programs both did not trigger it:
int main() {
function1();
/* function2(); */
exit 0;
}
int main() {
/* function1(); */
function2();
exit 0;
}
--
Eric Price
TTI GmbH - TGU Smartmote
Pfaffenwaldring 4
D-70569 Stuttgart
Tel.: +49 0711 - 6856 5369
Fax.: +49 0711 - 6856 6818
E-mail: pr...@smartmote.de
Homepage: http://www.smartmote.de
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] code size
The E2E response hints that we're running into an organizational conflict of interest at TI. the main thing I miss from TI's side is communication. All we've heard so far is, We have this new toolchain thingy here. Like it or lump it. This is not open source development. It would be good, if TI could be more open and explain, what they're going to do, why and how. So that if a RH engineer shows up here, willing to help, he wouldn't receive all the blames. I remember an Atmel engineer doing this a couple of years ago with avr-gcc and I always found that very informative. Might be, that TI's ignorance of the previous community efforts happens for a reason, e.g. not getting in touch with poisonous code (license). But that's hard to believe. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] code size
I tried the newer msp-GCC (TI/RedHat) distribution on my project(s). It still builds with _far_ more code then my present msp430-gcc (4.7.0). This compiler has also some minor habits but produces compact code. So for the moment I will not switch to the newer version, my project would not fit in the flash. best regards, Kees -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] code size
On Fri, 12 Dec 2014 11:43:59 +0100 Kees Schoenmakers ksli...@gmail.com wrote: I tried the newer msp-GCC (TI/RedHat) distribution on my project(s). It still builds with _far_ more code then my present msp430-gcc (4.7.0). This compiler has also some minor habits but produces compact code. So for the moment I will not switch to the newer version, my project would not fit in the flash. I have had similar issues in the beginning. It seems the new compiler does link in every function present in the code and libc - even if its not used, bloating up the code significantly. This however can be worked around with some additional compiler flags, to turn on link time optimization and garbage collection, which the new compiler does support, but is not turned on by default. add to compiler flags: -fdata-sections -ffunction-sections -fno-asynchronous-unwind-tables -flto and to linker flags --gc-sections --print-gc-sections this will cause the compiler to mark each function and data section in the resulting object file, which allows the linker to garbage collect unused functions (stripped functions are printed thanks to print-fc-sections) there are still some bugs, for example if linking a lot of code together the compiler suddenly issues a lot of warning: visibility attribute not supported in this configuration; ignored [-Wattributes] warnings for no apparent reason in random places in the code. This was also the case with the previous version of the TI/Redhat compiler released in the middle of the year. As far as I could see so far these linker warnings can be safely ignored, the resulting code still works and is still significantly smaller than without -flto and --gc-sections hope that helps. cheers Eric -- Eric Price TTI GmbH - TGU Smartmote Pfaffenwaldring 4 D-70569 Stuttgart Tel.: +49 0711 - 6856 5369 Fax.: +49 0711 - 6856 6818 E-mail: pr...@smartmote.de Homepage: http://www.smartmote.de -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] code size
On Fri, Dec 12, 2014 at 4:43 AM, Kees Schoenmakers ksli...@gmail.com wrote: I tried the newer msp-GCC (TI/RedHat) distribution on my project(s). It still builds with _far_ more code then my present msp430-gcc (4.7.0). This compiler has also some minor habits but produces compact code. So for the moment I will not switch to the newer version, my project would not fit in the flash. Yes, code size is not as one might wish. See http://e2e.ti.com/support/development_tools/compiler/f/343/p/384317/1356674#1356674 for some information, as well as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027 Those issues, unfortunately, are not solved by linker optimizations. (IRT Eric: I was unaware of the visibility attribute, so haven't run into that, though I can see it will be useful in the future.) My core blockers for msp430-elf are an official patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160 and a new release of the support headers/linker scripts that reverts the broken initialization infrastructure (which I assume TI is working on). But since mspgcc doesn't build on Ubuntu 14.04 the code size issue does become more important. The E2E response hints that we're running into an organizational conflict of interest at TI. Peter -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] code size
Hi On 12.12.2014, at 12:57, Peter Bigot big...@acm.org wrote: .. But since mspgcc doesn't build on Ubuntu 14.04 the code size issue does become more important. ... not really related to the code size problem but I'd like to recommend the use of Docker for the case where the default compiler causes problems. After failing to properly compile our desktop apps for 32-bit on a 64-bit built machine, we switched to compiling it from a 32-bit linux Docker container. As it is a container and we only use for this particular built task, we're free to try to use newer linux distributions easily. (note: this is not intended to stop Peter from helping out in getting the msp430-elf usable by the masses) Best Matthias -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] code size
Hello All, I have a project that build fine with the 'old' mspgcc (4.7.0). I managed to get it build and linked with the new toolkit. At first the code did not fit, where it did before. I disabled some features in the source tree and now I can build with both GCC versions (4.7.0 vs 4.9.1). However the difference in code size is significant, se the following comparison: mspgcc 4.7.0 .text sizes Main.o 0x184 Timers.o 0x226 Subroutine.o 0x21e Eerom.o0x51c Modbusmaster.o 0x1fa Hartserial.o 0x422 Hartprocess.o 0x8ae Hartunivers.o 0xa60 Hartcompractice.o 0x1a52 Hartransmspec.o 0xbfe Hartmain.o 0x81a Harttimers.o 0xb4 Sensors.o 0x2ee Modbuserial.o 0x11e Hartconversion.o 0x348 Hartplatformdep.o 0x2d0 libs 0xe4c etext=0x9664 mspgcc 4.9.1 .text sizes Main.o 0x1f4 Timers.o 0x27e Subroutine.o 0x30a Eerom.o0x68a Modbusmaster.o 0x22a Hartserial.o 0x436 Hartprocess.o 0xc5c Hartunivers.o 0xb30 Hartcompractice.o 0x1c98 Hartransmspec.o 0xdda Hartmain.o 0xa24 Harttimers.o 0xc0 Sensors.o 0x452 Modbuserial.o 0x142 Hartconversion.o 0x3dc Hartplatformdep.o 0x32c libs 0x306c etext= 0xc906 I hope someone can use these numbers. I compiled with the same CCFLAGS, optimizing etc. best regards Kees -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] Code Size
I have ported a Rowley project to mspgcc and have gotten it to compile. The code size from gcc is 8100 Bytes while in Rowley it was ~4K, a problem. What am I missing that would account for the size difference? Optimization is set for -O2. Thanks Rich
Re: [Mspgcc-users] Code size IAR / gcc
Peter Mueller wrote: Hi, I want to use gcc instead of IAR. My application is around 3k with IAR but about 4k with gcc. I tried -Os and -O2 with gcc. Any other compiler switches that further reduce code size? Thanks, Peter If you use floating point (even one single definition of a floating point value) a binary produced by IAR is considerably smaller than one produced by GCC. It is also faster. This is because we have never done any significant work to optimise the floating point library. However, with -O2 most integer only programs compile to a smaller binary using GCC. Not every program is the same, though. I have found examples which are a few percent bigger using GCC. A integer only binary which is 1/3rd bigger using GCC would be strange. Regards, Steve
[Mspgcc-users] Code size IAR / gcc
Hi, I want to use gcc instead of IAR. My application is around 3k with IAR but about 4k with gcc. I tried -Os and -O2 with gcc. Any other compiler switches that further reduce code size? Thanks, Peter
Re: [Mspgcc-users] Code size IAR / gcc
Hi, mspgcc produces bigger code when you use floating point operations. In the manual you can find tips for reducing code size. Regards, Rolf mspgcc-users@lists.sourceforge.net schrieb am 25.08.05 18:00:07: Hi, I want to use gcc instead of IAR. My application is around 3k with IAR but about 4k with gcc. I tried -Os and -O2 with gcc. Any other compiler switches that further reduce code size? Thanks, Peter --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
