sizeof((..))
Hi,
gcc emits an error, when compiling this code-snippet:
--- snip ---
extern int x;
void
foo (void)
{
x = sizeof ((long));
}
--- snip ---
# gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function ‘foo’:
tmp.c:6:21: error: expected expression before ‘)’ token
# gcc --version
gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
# sparc-rtems4.11-gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function 'foo':
tmp.c:6:21: error: expected expression before ')' token
# sparc-rtems4.11-gcc --version
sparc-rtems4.11-gcc (GCC) 4.5.2 20101216 (RTEMS
gcc-4.5.2-3.fc14/newlib-1.19.0-1.fc14)
Any explanations? What is wrong?
FWIW: I encountered this error when checking libstdc++'s config.log,
after having noticed its configure script was producing bogus results.
The code-snippet above is a stripped down fragment of one of these
failing configure-checks.
Ralf
Re: sizeof((..))
On 31 January 2011 08:59, Ralf Corsepius wrote:
> Hi,
>
> gcc emits an error, when compiling this code-snippet:
>
> --- snip ---
> extern int x;
>
> void
> foo (void)
> {
> x = sizeof ((long));
> }
> --- snip ---
>
> # gcc -Wall -o tmp.o -c tmp.c
> tmp.c: In function ‘foo’:
> tmp.c:6:21: error: expected expression before ‘)’ token
>
> # gcc --version
> gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
>
> # sparc-rtems4.11-gcc -Wall -o tmp.o -c tmp.c
> tmp.c: In function 'foo':
> tmp.c:6:21: error: expected expression before ')' token
>
> # sparc-rtems4.11-gcc --version
> sparc-rtems4.11-gcc (GCC) 4.5.2 20101216 (RTEMS
> gcc-4.5.2-3.fc14/newlib-1.19.0-1.fc14)
>
>
> Any explanations? What is wrong?
The code is wrong. sizeof expects either an expression, or a
parenthesized type-id. (long) is not a type-id so ((long)) is not a
parenthesized type-id, therefore it must be interpreted as an
expression, but it's not a valid expression either.
Re: Confusion in setting default options for non-C/C++ languages
On Sun, 30 Jan 2011, Ian Lance Taylor wrote: > Currently toplev_main calls > init_options_once > init_options_struct > lang_hooks.init_options_struct > which all make sense. It then calls > decode_options > which calls > default_options_optimization > which sets various options based on the optimization level. > > That is fine provided all languages agree on which options are > optimization-dependent and which are not. Unfortunately, they do not > agree. For example, both Fortran and Go do > opts->x_flag_errno_math = 0; > in the init_options_struct language hook. That is a useless step now, > as that is overridden by default_options_optimization, which sets either > -ffast-math or -fno-fast-math based on whether -Ofast is used, and > -fno-fast-math implies -ferrno-math. Similarly, Java does > opts->x_flag_trapping_math = 0; > and that too is now ineffective. > > I think that the call to lang_hooks.init_option_struct must be moved > after the call to default_options_optimization, one way or another. Hmm. It indeed looks like if init_options_struct should be called after default_options_optimization. Joseph, can we somehow disentangle this by marking an option already "default-initialized" now? Ideally we'd have a Fortran testcase that verifies the default settings. Richard.
Re: sizeof((..))
On 01/31/2011 10:19 AM, Jonathan Wakely wrote:
On 31 January 2011 08:59, Ralf Corsepius wrote:
Hi,
gcc emits an error, when compiling this code-snippet:
--- snip ---
extern int x;
void
foo (void)
{
x = sizeof ((long));
}
--- snip ---
# gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function ‘foo’:
tmp.c:6:21: error: expected expression before ‘)’ token
# gcc --version
gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
# sparc-rtems4.11-gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function 'foo':
tmp.c:6:21: error: expected expression before ')' token
# sparc-rtems4.11-gcc --version
sparc-rtems4.11-gcc (GCC) 4.5.2 20101216 (RTEMS
gcc-4.5.2-3.fc14/newlib-1.19.0-1.fc14)
Any explanations? What is wrong?
The code is wrong.
It's code GCC's configure scripts apply.
AFAICT, these fragments seems to originate from autoconf and don't have
seem to cause any harm (but confusing the reader of config.logs).
ATM, I am not sure, if what autoconf does actually is useful, but this
is a different matter.
sizeof expects either an expression, or a
parenthesized type-id. (long) is not a type-id so ((long)) is not a
parenthesized type-id, therefore it must be interpreted as an
expression, but it's not a valid expression either.
Thanks for the explanation.
Ralf
Re: Making gcc -no-canonical-prefixes the default?
On 31 January 2011 01:20, Gerald Pfeifer wrote: > On Fri, 28 Jan 2011, Ian Lance Taylor wrote: >> Some archealogy turned up this as the reason canonicalization was >> inserted: >> >> http://gcc.gnu.org/ml/gcc/2003-02/msg01121.html >> http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01697.html >> >> Also relevant here is http://gcc.gnu.org/PR29931 . > > I am quite sure that the current behavior where one can have a symlink > point to an installation of GCC anywhere else (outside of any path even) > has been in place for quite a bit longer than 2003. Thanks for the notes and archaeology. My guess is that because it's easier, symlinking a single gcc binary is more common than symlinking a complete gcc tree. > On Sat, 29 Jan 2011, Dave Korn wrote: >> I think the case which is particularly common is the alternatives >> system, which has a chain of symlinks finally pointing to a real gcc. >> (That works just fine with the current default, AFAIK, although that >> may be only because the real gcc is in $PATH?) > > Nope, only the symlink(s) need to be in the path. And indeed this > usecase that you and also Joseph describe is how I've been using it > for many years. > > Given that this has een default behavior for so long (more than a > decade from what I can tell), I'd recommend not changing it. That would be as good a reason as any for not changing it. Thanks for the clarification. The patch in http://gcc.gnu.org/PR29931 uses... heuristics to detect if the gcc driver is a single symlink or part of a symlink farm (Florian Weimer's suggestion above). The patch has never been fully accepted, though; any known reason? I believe it will handle the two main use cases reliably. Combining it with -[no-]canonical-prefixes flags as overrides would cover all cases unambiguously. If heuristics aren't deemed reliable enough, another option is to set a default with a -no-canonical-prefixes-default configure flag. Less flexible because it's baked in to gcc, but simpler. On balance the PR29931 patch approach with -[no-]canonical-prefixes overrides seems to me like it will lead to least trouble in future. It also closes a long-standing gcc PR. Any dissent? Other options? Thanks. -- Google UK Limited | Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
Re: sizeof((..))
Ralf Corsepius writes: > ATM, I am not sure, if what autoconf does actually is useful, but this > is a different matter. autoconf needs to deliberately trigger errors in a lot of its tests in order to do the right thing. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: sizeof((..))
On Mon, 31 Jan 2011 09:19:07 +, Jonathan Wakely wrote: > The code is wrong. sizeof expects either an expression, or a > parenthesized type-id. (long) is not a type-id so ((long)) is not a > parenthesized type-id, therefore it must be interpreted as an > expression, but it's not a valid expression either. In sense of 6.5.3.4 - the sizeof operator where nearly every value is allowed? Why not a parenthesized parenthesized type-id? HGN
Re: sizeof((..))
On 01/31/2011 01:02 PM, Andreas Schwab wrote: Ralf Corsepius writes: ATM, I am not sure, if what autoconf does actually is useful, but this is a different matter. autoconf needs to deliberately trigger errors in a lot of its tests in order to do the right thing. I know, but ... ... the autoconf macro in question is this (from .../share/autoconf/types.m4) ... m4_define([_AC_CHECK_TYPE_NEW], [AS_VAR_PUSHDEF([ac_Type], [ac_cv_type_$1])dnl AC_CACHE_CHECK([for $1], [ac_Type], [AS_VAR_SET([ac_Type], [no]) AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT([$4])], [if (sizeof ($1)) return 0;])], [AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT([$4])], [if (sizeof (($1))) return 0;])], [], [AS_VAR_SET([ac_Type], [yes])])])]) AS_VAR_IF([ac_Type], [yes], [$2], [$3])[]dnl AS_VAR_POPDEF([ac_Type])dnl ])# _AC_CHECK_TYPE_NEW ... I.e. to check for presence of a type, it 1st tries to compile if (sizeof () return 0; and then if (sizeof (()) return 0; and expects the 1st compile to succeed and the 2nd to fail. However, the rationale why autoconf is doing so, so far escapes me. Ralf
Re: sizeof((..))
On 31 January 2011 12:16, Hagen Paul Pfeifer wrote: > > On Mon, 31 Jan 2011 09:19:07 +, Jonathan Wakely wrote: > >> The code is wrong. sizeof expects either an expression, or a >> parenthesized type-id. (long) is not a type-id so ((long)) is not a >> parenthesized type-id, therefore it must be interpreted as an >> expression, but it's not a valid expression either. > > In sense of 6.5.3.4 - the sizeof operator where nearly every value is > allowed? Why not a parenthesized parenthesized type-id? I incorrectly assumed Ralf's example code was C++, because he mentioned the libstdc++'s config.log, so that's the standard I referred to. The C standard has similar wording. In any case, EDG and Clang give the same error as GCC, for C or C++, so the question is moot: the standards say it's invalid and conforming compilers agree.
Re: GCC 4.3.5 Status Report (2010-05-22)
On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song
wrote:
> It's very simple (only for trunk, although it maybe more useful for
> branches):
Or simply put Last-Changed-Date into DATESTAMP, not the
current date.
Richard.
> Index: update_version_svn
> ===
> --- update_version_svn (revision 169428)
> +++ update_version_svn (working copy)
> @@ -42,6 +42,12 @@
> SVNROOT2=${SVNROOT}/branches/${BRANCH}
> fi
>
> + LAST_COMMITER=`${SVN} log -q -l 1 ${SVNROOT2} | awk '{if (NR==2) {print
> $3; exit}}'`
> + if test "${LAST_COMMITER}" = "gccadmin"; then
> + echo "The last commiter is gccadmin, bump DATASTAMP skipped."
> + continue
> + fi
> +
> for i in $datestamp_FILES; do
> ${SVN} -q co -N ${SVNROOT2}/`dirname $i` `basename $i`
> done
>
> On Mon, Jan 31, 2011 at 06:23, Gerald Pfeifer wrote:
>>
>> On Sat, 29 Jan 2011, Dongsheng Song wrote:
>> > Just for curiousness, why we bump the DATESTAMP when the last commit
>> > is DATESTAMP changes on the branch ?
>>
>> As far as I am concerned, that's a bug (or a missing feature). The
>> script in question is maintainer-scripts/update_version_svn in the GCC
>> source repository. I already made some simplifications today and am
>> planning to do a bit more tonight. Are you interested in improving
>> the script to address this issue?
>>
>> Gerald
>
>
Re: sizeof((..))
Ralf Corsepius writes: > However, the rationale why autoconf is doing so, so far escapes me. Read the comments. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: defining add in a new port
On 01/28/2011 09:45 PM, Ian Lance Taylor wrote:
> Jean-Marc Saffroy writes:
>
>> On 01/28/2011 06:44 PM, Ian Lance Taylor wrote:
>>> Jean-Marc Saffroy writes:
>>>
error: insn does not satisfy its constraints:
(insn 1424 1423 141 (set (reg:DI 2 r2)
(plus:DI (reg:DI 2 r2)
(const_int 40 [0x28])))
/home/jmsaffroy/cygnus/src/newlib/libc/time/strptime.c:165 24 {adddi3}
(expr_list:REG_EQUIV (plus:DI (reg/f:DI 70 a6)
(const_int 40 [0x28]))
(nil)))
>>>
>>> You should find out what is creating this insn. Is it being created by
>>> reload, or is it being created by some pass that runs after reload?
>>
>> With gcc -da, I see that it appears in dump .195r.ira, so that's reload,
>> right?
>
> Right.
>
>
>>> It is likely that you need to make adddi3 a define_expand which tests
>>> reload_in_progress and reload_completed. If those are the case, you
>>> will need to explicitly convert
>>> (set (reg:DI DREG1) (plus:DI (reg:DI DREG2) (const_int N)))
>>> into
>>> (set (reg:DI DREG1) (const_int N))
>>> (set (reg:DI DREG1) (plus:DI (reg:DI DREG1) (REG:DI DREG2)))
>>>
>>
>> Ah, but here it happens that DREG1 and DREG2 (r2 and a6 above) are
>> different types of registers, and I can't add them directly.
>
> The insn you showed is adding a constant to a DREG. There is no
> addition of a DREG and an AREG, and I would not expect reload to
> generate any such addition either. Are you looking at a different insn?
> Don't get confused by the REG_EQUIV note, it's irrelevant here.
Actually, looking at the full dumps, I see that this incorrect insn
shown in the ICE above is emitted when eliminating the arg pointer: a6
is the frame pointer (a6+40 probably points to the args on stack).
Running cc1 under gdb, I see that gen_reload is tasked with reloading
(plus AREG N) into (DREG): the first attempts fail (the generated insns
are rejected by emit_insn_if_valid_for_reload), and so gen_reload
recurses (reload.c:8550), generates a 2-insn sequence that does:
(set DREG AREG)
(set DREG (plus DREG N))
But this N is not a valid immediate for an add to a DREG, according to
the predicates I defined for adddi3, which are not checked at this
point, but only later on in final_scan_insn.
So it seems I will have to have adddi3 be a define_expand that splits
the increment by N into smaller increments when called with
(reload_in_progress||reload_completed). Does that sound reasonable?
It's worth noting that I'm developing with an old svn checkout of the
gcc trunk from last October, I will update ASAP just in case.
Jean-Marc
Re: GCC 4.3.5 Status Report (2010-05-22)
On Mon, Jan 31, 2011 at 7:51 AM, Richard Guenther wrote: > On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song > wrote: >> It's very simple (only for trunk, although it maybe more useful for >> branches): > > Or simply put Last-Changed-Date into DATESTAMP, not the > current date. This has other benefits as well, since it means that the date in the gcc version string becomes the date of the last actual revision, instead of the date that the datestamp change is committed.
Re: defining add in a new port
Jean-Marc Saffroy writes: > So it seems I will have to have adddi3 be a define_expand that splits > the increment by N into smaller increments when called with > (reload_in_progress||reload_completed). Does that sound reasonable? Yes. Ian
Re: Confusion in setting default options for non-C/C++ languages
On Sun, 30 Jan 2011, Ian Lance Taylor wrote: > I think that the call to lang_hooks.init_option_struct must be moved > after the call to default_options_optimization, one way or another. No, that is wrong; by design this structure initialization should happen before the options from the command line (including -On) have their effects. Rather, I think -fno-fast-math - whether explicit or implicit - should not be overriding such language-dependent defaults for particular options; if a language defaults to -fno-math-errno, explicit -fmath-errno should be required to override that (essentially, the set of options implied by -ffast-math / -fno-fast-math should depend on the language). -- Joseph S. Myers jos...@codesourcery.com
Re: GCC 4.3.5 Status Report (2010-05-22)
On Mon, 31 Jan 2011, NightStrike wrote: > On Mon, Jan 31, 2011 at 7:51 AM, Richard Guenther > wrote: > > On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song > > wrote: > >> It's very simple (only for trunk, although it maybe more useful for > >> branches): > > > > Or simply put Last-Changed-Date into DATESTAMP, not the > > current date. > > This has other benefits as well, since it means that the date in the > gcc version string becomes the date of the last actual revision, > instead of the date that the datestamp change is committed. Not in the case where you have no datestamp changes for a month, say, then some other change is committed, but a new datestamp change hasn't yet been committed after that other change; then you have, for a limited period, a compiler with a datestamp value long before the last commit. (That's the main case I can think of for not making snapshots if only DATESTAMP has changed, rather than the simpler approach of omitting some DATESTAMP updates and not making snapshots if nothing at all has changed.) -- Joseph S. Myers jos...@codesourcery.com
Re: Confusion in setting default options for non-C/C++ languages
On Mon, Jan 31, 2011 at 9:52 AM, Joseph S. Myers wrote: > On Sun, 30 Jan 2011, Ian Lance Taylor wrote: > >> I think that the call to lang_hooks.init_option_struct must be moved >> after the call to default_options_optimization, one way or another. > > No, that is wrong; by design this structure initialization should happen > before the options from the command line (including -On) have their > effects. Rather, I think -fno-fast-math - whether explicit or implicit - > should not be overriding such language-dependent defaults for particular > options; if a language defaults to -fno-math-errno, explicit -fmath-errno > should be required to override that (essentially, the set of options > implied by -ffast-math / -fno-fast-math should depend on the language). Should the optimization-dependent-defaluts also be split into a language dependent and independent parts? David > > -- > Joseph S. Myers > jos...@codesourcery.com >
Re: Confusion in setting default options for non-C/C++ languages
On Mon, 31 Jan 2011, Xinliang David Li wrote: > On Mon, Jan 31, 2011 at 9:52 AM, Joseph S. Myers > wrote: > > On Sun, 30 Jan 2011, Ian Lance Taylor wrote: > > > >> I think that the call to lang_hooks.init_option_struct must be moved > >> after the call to default_options_optimization, one way or another. > > > > No, that is wrong; by design this structure initialization should happen > > before the options from the command line (including -On) have their > > effects. Rather, I think -fno-fast-math - whether explicit or implicit - > > should not be overriding such language-dependent defaults for particular > > options; if a language defaults to -fno-math-errno, explicit -fmath-errno > > should be required to override that (essentially, the set of options > > implied by -ffast-math / -fno-fast-math should depend on the language). > > Should the optimization-dependent-defaluts also be split into a > language dependent and independent parts? I hope that can be avoided, but if needed there is always the post_options hook that can do arbitrary processing as needed. -- Joseph S. Myers jos...@codesourcery.com
Re: Bugzilla permissions
Tony Poppleton writes: > Thanks, however I am still unable to make the changes in bugzilla, > specifically; > - modify "known to fail"/"known to work" fields > - transition a bug status from UNCONFIRMED to NEW > - change "Target Milestone" > - potentially change priority/severity > > Could someone with the powers please modify my permissions to the above? I will do that if a gcc maintainer vouches for you. No offense, but I don't want to give gcc bugzilla permissions to everybody on the net. > (as an aside, shouldn't modifying the "known to fail/work" fields be > enabled by default for all?) Some compiler bugs are subtle, and our experience is that people unfamiliar with gcc are not always reliable in determining whether a bug exists or not. That said, I'm not really opposed to such a change if others are in favor of it. Ian
C++ Template instantiations efficiency (COMDAT, LINKONCE, ...) status in gcc 4.X series
Hi and thanks to the contributors of g++ (and the whole gcc suite) ... what a tremendous value! If I have to pinpoint my question, I would refer to gcc internals documentation section 11.10.4 "Functions for C++", macro name DECL_LINKONCE_P which is said to be "Not yet implemented". Then the question is "Can we expect further (compile-and-link time) efficiencies when this internal DECL_LINKONCE_P is implemented in a later release in the 4.X series? I assume the answer is no, as long as COMDAT support is provided in the linker. If such is the case, the suggestion is to add e.g. "The usefulness of DECL_LINKONCE_P appears questionable because COMDAT support by the link process is needed anyway for avoiding object code duplication and DECL_LINKONCE_P has no influence on this matter." Generally, the optimization of template instantiations remains a bit obscure for the g++ user. The performance improvement announced with gcc 4.5 seems unrelated to the COMDAT optimization of executable size. Is this correct? On one project, I used -fno-implicit-templates since I felt that a static library build process would benefit from it (every anticipated template specializations is included in the library). On another project, I felt a need to use -frepo (I don't recall exactly why). While trying to merge the two projects, I found that the g++ compiler (with GNU ld) was working just fine with the default setting for template specializations. Seems great! (Thinking while I write now, maybe DECL_LINKONCE_P might be relevant to distinguish compilation runs with -frepo in contexts where the link process does not support COMDAT.) If you follow my thinking (I'm not sure I always do when applying advanced C++ abstraction in actual code development), I wish to have an understanding of compile-time efficiencies when the C++ template mechanism is heavily used. More specifically, I am afraid that compile-time would become un-manageable as a project grows from a code base just too heavily dependent on the STL. But the STL concepts are so attractive! Once upon a time there was the Borland model ... I guess g++ makes this a thing of the past. Is this a fair assessment? Best regards. -- - Thierry Moreau CONNOTECH Experts-conseils inc.
Re: Target deprecations for 4.6
On Sun, 30 Jan 2011, Joseph S. Myers wrote: > My inclination would be to move the > > *-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*) > # This is the place-holder for the generic a.out configuration > # of FreeBSD. No actual configuration resides here since > # there was only ever a bare-bones ix86 configuration for > # a.out and it exists solely in the machine-specific section. > # This place-holder must exist to avoid dropping into > # the generic ELF configuration of FreeBSD (i.e. it must be > # ordered before that section). > ;; > > case up to You mean like this? Not sure who would approve something like this, technically. Shall I got ahead and commit this? Gerald 2011-02-01 Gerald Pfeifer * config.gcc (*-*-freebsd[12], *-*-freebsd[12].*, *-*-freebsd*aout*): Move to the unsupported targets list. Index: config.gcc === --- config.gcc (revision 169463) +++ config.gcc (working copy) @@ -246,6 +246,8 @@ | pdp11-*-bsd \ | sparc-hal-solaris2* \ | thumb-*-* \ + | *-*-freebsd[12] | *-*-freebsd[12].* \ + | *-*-freebsd*aout* \ | *-*-linux*aout* \ | *-*-linux*coff* \ | *-*-linux*libc1*\ @@ -480,15 +482,6 @@ "" | yes | posix) thread_file='posix' ;; esac ;; -*-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*) - # This is the place-holder for the generic a.out configuration - # of FreeBSD. No actual configuration resides here since - # there was only ever a bare-bones ix86 configuration for - # a.out and it exists solely in the machine-specific section. - # This place-holder must exist to avoid dropping into - # the generic ELF configuration of FreeBSD (i.e. it must be - # ordered before that section). - ;; *-*-freebsd*) # This is the generic ELF configuration of FreeBSD. Later # machine-specific sections may refine and add to this
Re: Target deprecations for 4.6
On Tue, 1 Feb 2011, Gerald Pfeifer wrote: > On Sun, 30 Jan 2011, Joseph S. Myers wrote: > > My inclination would be to move the > > > > *-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*) > > # This is the place-holder for the generic a.out configuration > > # of FreeBSD. No actual configuration resides here since > > # there was only ever a bare-bones ix86 configuration for > > # a.out and it exists solely in the machine-specific section. > > # This place-holder must exist to avoid dropping into > > # the generic ELF configuration of FreeBSD (i.e. it must be > > # ordered before that section). > > ;; > > > > case up to > > You mean like this? Not sure who would approve something like this, Yes, like that. -- Joseph S. Myers jos...@codesourcery.com
LTO on newlib targets w/o Gold
Hi, There are ~100 failures on each *-rtems* target in the latest test runs when various lto related flags are on. The symbols in questions are in the RTEMS libraries which are picked up via the -B... argument. Other symbols from the same library are resolved. Should LTO work with a target not using gold? The errors are like this: Executing on host: /users/joel/test-gcc/b-gcc1-m32r/gcc/xgcc -B/users/joel/test-gcc/b-gcc1-m32r/gcc/ /users/joel/test-gcc/gcc-svn/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.c /users/joel/test-gcc/gcc-svn/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf-lib.c /users/joel/test-gcc/gcc-svn/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c gcc_tg.o -w -O2 -flto -flto-partition=none -DSTACK_SIZE=2048 -isystem /users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/m32r-rtems4.11/m32rsim/lib/ -specs bsp_specs -qrtems -B/users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib/ -L/users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib /users/joel/test-gcc/b-gcc1-m32r/rtems_gcc_main.o -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o /users/joel/test-gcc/b-gcc1-m32r/gcc/testsuite/gcc/fprintf.x6 (timeout = 300) /users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib/libc.a(lib_a-fvwrite.o): In function `__sfvwrite_r':^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdio/fvwrite.c:158: undefined reference to `_realloc_r'^M /users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib/libc.a(lib_a-makebuf.o): In function `__smakebuf_r':^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdio/makebuf.c:59: undefined reference to `_fstat_r'^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdio/makebuf.c:110: undefined reference to `_isatty_r'^M /users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib/libc.a(lib_a-mprec.o): In function `_Balloc':^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdlib/mprec.c:106: undefined reference to `_calloc_r'^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdlib/mprec.c:123: undefined reference to `_calloc_r'^M collect2: ld returned 1 exit status^M compiler exited with status 1 output is: /users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib/libc.a(lib_a-fvwrite.o): In function `__sfvwrite_r':^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdio/fvwrite.c:158: undefined reference to `_realloc_r'^M /users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib/libc.a(lib_a-makebuf.o): In function `__smakebuf_r':^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdio/makebuf.c:59: undefined reference to `_fstat_r'^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdio/makebuf.c:110: undefined reference to `_isatty_r'^M /users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib/libc.a(lib_a-mprec.o): In function `_Balloc':^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdlib/mprec.c:106: undefined reference to `_calloc_r'^M /users/joel/test-gcc/gcc-svn/newlib/libc/stdlib/mprec.c:123: undefined reference to `_calloc_r'^M collect2: ld returned 1 exit status^M FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation, -O2 -flto -flto-partition=none Explanations and advice are appreciated. Thanks. --joel
