On 01/27/2014 10:51 PM, Senthil Kumar Selvaraj wrote: > This is on trunk - I was under the impression that it is always trunk, > unless otherwise stated? > > getpid doesn't really make sense for bare metal targets, I would think? > > Regards > Senthil > > On Mon, Jan 27, 2014 at 01:04:48PM +0000, Umesh Kalappa wrote: >> Senthil, >> Please do let us know the gcc version ,I couldn't locate the file pr58419.c >> in the GCC 4.8.1 source . >> >> To go with the below problem ,you can attributed the getpid() function as >> weak (http://www.embedded-bits.co.uk/2008/gcc-weak-symbols/). >> >> ~Umesh >> >> -----Original Message----- >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of >> Senthil Kumar Selvaraj >> Sent: 27 January 2014 15:18 >> To: gcc@gcc.gnu.org >> Subject: [Testsuite] getpid in gcc.c-torture/execute/pr58419.c >> >> All, >> >> gcc.c-torture/execute/pr58419.c has a call to getpid, and this causes >> a linker error on the AVR (embedded) target. Is the call intentional, >> and if yes, how should this be fixed for targets that don't support an >> OS? >> >> Regards >> Senthil > >
The testcase in the PR had a call to printf. The modified test doesn't call printf, and doesn't declare getpid. I assume that getpid is called simply to have an external call, but there must be something that could be used instead that is available for any target. Jeff, you added this test, would you please take a look at it? Janis
