Re: WPA stream_out form & memory consumption
On 04/07/2014 07:10 PM, Jan Hubicka wrote:
I added new graph for 'xloc.column = 0' hack, just applied this
single patch to trunk.
Link:
https://drive.google.com/file/d/0B0pisUJ80pO1MW11WHdjMk9KQnc/edit?usp=sharing
Good, does these two patches combine together well? (they are rater orthogonal,
but perhaps with columns disabled linemaps are no longer big enough to matter).
Third graph is just trunk with single line patch applied: 'xloc.column = 0'.
Martin
Honza
Martin
Martin
Honza
Index: lto-streamer-in.c
===
--- lto-streamer-in.c (revision 209047)
+++ lto-streamer-in.c (working copy)
@@ -145,21 +145,49 @@ canon_file_name (const char *string)
}
+/* location_cache is used at LTO read in to avoid too many duplicates
in
+ the linemap tables. */
+
+#define LOCATION_CACHE_SIZE 524287
+struct location_cache_entry
+{
+ const char *file;
+ int line;
+ int col;
+ location_t location;
+};
+static struct location_cache_entry *location_cache;
+
+/* Return hash of FILE/LINE/COL. */
+
+int
+location_cache_hash (const char *file, int line, int col)
+{
+ return iterative_hash_hashval_t ((size_t)file,
+ iterative_hash_hashval_t (line, col))
% LOCATION_CACHE_SIZE;
+}
+
+
/* Read a location bitpack from input block IB. */
location_t
lto_input_location (struct bitpack_d *bp, struct data_in *data_in)
{
- static const char *current_file;
- static int current_line;
+ static const char *current_file, *last_file;
+ static int current_line, last_line;
static int current_col;
bool file_change, line_change, column_change;
unsigned len;
- bool prev_file = current_file != NULL;
+ bool prev_file = last_file != NULL;
+ int hash;
+ const char *cfile;
if (bp_unpack_value (bp, 1))
return UNKNOWN_LOCATION;
+ if (!location_cache)
+location_cache = XCNEWVEC (struct location_cache_entry,
LOCATION_CACHE_SIZE);
+
file_change = bp_unpack_value (bp, 1);
line_change = bp_unpack_value (bp, 1);
column_change = bp_unpack_value (bp, 1);
@@ -175,18 +203,32 @@ lto_input_location (struct bitpack_d *bp
if (column_change)
current_col = bp_unpack_var_len_unsigned (bp);
+ cfile = current_file;
+ hash = location_cache_hash (cfile, current_line, current_col);
- if (file_change)
+ if (location_cache[hash].file == cfile
+ && location_cache[hash].line == current_line
+ && location_cache[hash].col == current_col + 1)
+return location_cache[hash].location;
+ location_cache[hash].file = cfile;
+ location_cache[hash].line = current_line;
+ location_cache[hash].col = current_col + 1;
+
+ if (current_file != last_file)
{
if (prev_file)
linemap_add (line_table, LC_LEAVE, false, NULL, 0);
linemap_add (line_table, LC_ENTER, false, current_file,
current_line);
}
- else if (line_change)
+ else if (current_line != last_line)
linemap_line_start (line_table, current_line, current_col);
- return linemap_position_for_column (line_table, current_col);
+ location_cache[hash].location
+= linemap_position_for_column (line_table, current_col);
+ last_file = current_file;
+ last_line = current_line;
+ return location_cache[hash].location;
}
@@ -981,6 +1023,27 @@ input_function (tree fn_decl, struct dat
}
bsi = gsi_start_bb (bb);
while (!gsi_end_p (bsi))
+ {
+ gimple stmt = gsi_stmt (bsi);
+ /* If we're recompiling LTO objects with debug stmts but
+we're not supposed to have debug stmts, remove them now.
+We can't remove them earlier because this would cause uid
+mismatches in fixups, but we can do it at this point, as
+long as debug stmts don't require fixups. */
+ if (!MAY_HAVE_DEBUG_STMTS && is_gimple_debug (stmt))
+ {
+ gimple_stmt_iterator gsi = bsi;
+ gsi_next (&bsi);
+ gsi_remove (&gsi, true);
+ }
+ else
+ {
+ gsi_next (&bsi);
+ stmts[gimple_uid (stmt)] = stmt;
+ }
+ }
+ bsi = gsi_start_bb (bb);
+ while (!gsi_end_p (bsi))
{
gimple stmt = gsi_stmt (bsi);
/* If we're recompiling LTO objects with debug stmts but
Re: WPA stream_out form & memory consumption
On Mon, Apr 7, 2014 at 8:20 PM, Jan Hubicka wrote: >> AFAIK we settled on a simpler one dropping columns at stream-out time >> that also helped. >> >> As for the correct way to do the optimization we agreed(?) that streaming >> the locations elsewhere and using references to them is more appropriate. >> At stream-in (or before stream-out) we can then read the location pairs >> and sort them before assigning linemap entries. > > Yep, however what makes difference is the sharing in between compilation units > (so sameheaders gets assigned same locations) rather than sharing within the > unit > (by my experiments). The separate streaming+sorting will only help sharing > within the unit. > > Perhaps something rather simplelike keeping previous stream and merging them > will > work, too, not sure if better than the simple cache hash though. > Or perhaps we can somehow track per-source-file location spaces. Don't know. But then linemap itself should provide the ability to lookup existing entries rather than you adding another table ontop of it ... Note that you mess up the include stack when you re-use linemap entries across files (we at least care to setup the source TU information so you get 'included from foo.c' correctly - if you re-use linemaps you get that screwed up and ultimately end up with bogus inline stacks for example). Richard. > Honza
Unexpected presence of __eprintf in libgcc.a when using newlib
Hi everybody,
When playing with a toolchain built with --with-newlib switch, I recently
noticed that libgcc.a includes __eprintf among its objects. However,
gcc/doc/install.texi states that --with-newlib switches "causes
@code{__eprintf} to be omitted from @file{libgcc.a} on the assumption that it
will be provided by @samp{newlib}. And indeed, newlib provides __eprintf. Was
the logic to omit __eprintf when newlib is used removed at some point for some
reason or is it a bug?
Best regards,
Thomas
gcc build second pass : C compiler cannot create executables
Try to make a gcc cross compiler , 0 perpare vars in env export HOST=x86_64-pc-linux-gnu export BUILD=$HOST export TARGET=x86_64-none-linux-gnu export CROSS_TOOL=/vita/cross-tool export CROSS_GCC_TMP=/vita/cross-gcc-tmp export SYSROOT=/vita/sysroot PATH=$CROSS_TOOL/bin:$CROSS_GCC_TMP/bin:/sbin:/usr/sbin:$PATH 1 build binutilss ../binutils-2.23.1/configure --prefix=$CROSS_TOOL \ --target=$TARGET --with-sysroot=$SYSROOT build success then add this lines to .bashrc And this want build glibc next use the tools I just build export AR="$TARGET-ar" export AS="$TARGET-as" export RANLIB="$TARGET-ranlib" export LD="$TARGET-ld" export STRIP="$TARGET-strip" 2 build freestanding compiler first perpare gmp source cd gcc-4.7.2/ tar -xvf ../../source/mpfr-3.1.1.tar.bz2 tar -xvf ../../source/mpc-1.0.1.tar.gz tar -xvf ../../source/gmp-5.0.5.tar.bz2 mv gmp-5.0.5/ gmp mv mpfr-3.1.1/ mpfr mv mpc-1.0.1/ mpc then cd to gcc-build1 ../gcc-4.7.2/configure --prefix=$CROSS_GCC_TMP --target=$TARGET \ --with-sysroot=$SYSROOT --with-newlib --enable-languages=c \ --with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src \ --with-mpfr-lib=/vita/build/gcc-build1/mpfr/src/.libs \ --disable-shared --disable-threads --disable-decimal-float \ --disable-libquadmath --disable-libmudflap --disable-libgomp \ --disable-nls --disable-libssp --disable-multilib succss . So add this line the ~/.bashrc (this will use this build gcc to build a second gcc ) export CC="$TARGET-gcc" 3 build glibc ../glibc-2.15/configure --prefix=/usr --host=$TARGET \ --enable-kernel=3.7.4 --enable-add-ons \ --with-headers=$SYSROOT/usr/include\ libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes \ libc_cv_ctors_header=yes and make and install make install_root=$SYSROOT install after install : vita@engine-virtual-machine:/vita$ ls sysroot/usr/lib64/*.o sysroot/usr/lib64/crt1.o sysroot/usr/lib64/crtn.o sysroot/usr/lib64/Mcrt1.o sysroot/usr/lib64/crti.o sysroot/usr/lib64/gcrt1.o sysroot/usr/lib64/Scrt1.o 4 build second pass gcc , cd to gcc-build2 ../gcc-4.7.2/configure --prefix=$CROSS_TOOL --target=$TARGET \ --with-sysroot=$SYSROOT \ --with-newlib --enable-languages=c,c++ \ --with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src \ --with-mpfr-lib=/vita/build/gcc-build2/mpfr/src/.libs \ --disable-multilib --enable-threads=posix Here will be error checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-none-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... gawk checking for libitm support... yes checking for gcc... x86_64-none-linux-gnu-gcc checking for C compiler default output file name... configure: error: in `/vita/build/gcc-build2': configure: error: C compiler cannot create executables Then I cd /vita/cross-gcc-tmp/bin The first pass install dir : vita@engine-virtual-machine:/vita/cross-gcc-tmp/bin$ ./x86_64-none-linux-gnu-gcc test.c /vita/cross-tool/bin/x86_64-none-linux-gnu-ld: cannot find crt1.o: No such file or directory /vita/cross-tool/bin/x86_64-none-linux-gnu-ld: cannot find crti.o: No such file or directory collect2: error: ld returned 1 exit status (I install bintuils in /vita/cross-tool and install tmp gcc in /vita/cross-gcc-tmp ) Here is question : Seem /vita/cross-tool/bin/x86_64-none-linux-gnu-ld can't find crti.o and it don't know the $sysroot/usr/lib64 I already success build So I am wondering the --with-sysroot=$SYSROOT mean to search libs in $SYSROOT, why it can't known ? Any suggestion ?
Re: gcc build second pass : C compiler cannot create executables
Can you check whether crt1.o and crt1.o exist? And the path where they do live. Also it would be interesting to know the exact commandline (check config.log). 2014-04-08 14:13 GMT+02:00 Mo Jia : > Try to make a gcc cross compiler , > > 0 perpare vars in env > > export HOST=x86_64-pc-linux-gnu > export BUILD=$HOST > export TARGET=x86_64-none-linux-gnu > export CROSS_TOOL=/vita/cross-tool > export CROSS_GCC_TMP=/vita/cross-gcc-tmp > export SYSROOT=/vita/sysroot > PATH=$CROSS_TOOL/bin:$CROSS_GCC_TMP/bin:/sbin:/usr/sbin:$PATH > > 1 build binutilss > > ../binutils-2.23.1/configure --prefix=$CROSS_TOOL \ > --target=$TARGET --with-sysroot=$SYSROOT > > build success > then add this lines to .bashrc And this want build glibc next use the > tools I just build > > export AR="$TARGET-ar" > export AS="$TARGET-as" > export RANLIB="$TARGET-ranlib" > export LD="$TARGET-ld" > export STRIP="$TARGET-strip" > > 2 build freestanding compiler first perpare gmp source > > cd gcc-4.7.2/ > tar -xvf ../../source/mpfr-3.1.1.tar.bz2 > tar -xvf ../../source/mpc-1.0.1.tar.gz > tar -xvf ../../source/gmp-5.0.5.tar.bz2 > mv gmp-5.0.5/ gmp > mv mpfr-3.1.1/ mpfr > mv mpc-1.0.1/ mpc > > then cd to gcc-build1 > > ../gcc-4.7.2/configure --prefix=$CROSS_GCC_TMP --target=$TARGET \ > --with-sysroot=$SYSROOT --with-newlib --enable-languages=c \ > --with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src \ > --with-mpfr-lib=/vita/build/gcc-build1/mpfr/src/.libs \ > --disable-shared --disable-threads --disable-decimal-float \ > --disable-libquadmath --disable-libmudflap --disable-libgomp \ > --disable-nls --disable-libssp --disable-multilib > > succss . So add this line the ~/.bashrc (this will use this build > gcc to build a second gcc ) > > > export CC="$TARGET-gcc" > > 3 build glibc > > ../glibc-2.15/configure --prefix=/usr --host=$TARGET \ > --enable-kernel=3.7.4 --enable-add-ons \ > --with-headers=$SYSROOT/usr/include\ > libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes \ > libc_cv_ctors_header=yes > > and make and install > > make install_root=$SYSROOT install > > after install : > > vita@engine-virtual-machine:/vita$ ls sysroot/usr/lib64/*.o > sysroot/usr/lib64/crt1.o sysroot/usr/lib64/crtn.o > sysroot/usr/lib64/Mcrt1.o > sysroot/usr/lib64/crti.o sysroot/usr/lib64/gcrt1.o > sysroot/usr/lib64/Scrt1.o > > 4 build second pass gcc , cd to gcc-build2 > > ../gcc-4.7.2/configure --prefix=$CROSS_TOOL --target=$TARGET \ > --with-sysroot=$SYSROOT \ > --with-newlib --enable-languages=c,c++ \ > --with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src \ > --with-mpfr-lib=/vita/build/gcc-build2/mpfr/src/.libs \ > --disable-multilib --enable-threads=posix > > Here will be error > > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking target system type... x86_64-none-linux-gnu > checking for a BSD-compatible install... /usr/bin/install -c > checking whether ln works... yes > checking whether ln -s works... yes > checking for a sed that does not truncate output... /bin/sed > checking for gawk... gawk > checking for libitm support... yes > checking for gcc... x86_64-none-linux-gnu-gcc > checking for C compiler default output file name... > configure: error: in `/vita/build/gcc-build2': > configure: error: C compiler cannot create executables > > Then I cd /vita/cross-gcc-tmp/bin The first pass install dir : > > vita@engine-virtual-machine:/vita/cross-gcc-tmp/bin$ > ./x86_64-none-linux-gnu-gcc test.c > /vita/cross-tool/bin/x86_64-none-linux-gnu-ld: cannot find crt1.o: > No such file or directory > /vita/cross-tool/bin/x86_64-none-linux-gnu-ld: cannot find crti.o: > No such file or directory > collect2: error: ld returned 1 exit status > > (I install bintuils in /vita/cross-tool and install tmp gcc in > /vita/cross-gcc-tmp ) > > Here is question : > Seem /vita/cross-tool/bin/x86_64-none-linux-gnu-ld can't find crti.o > and it don't know the $sysroot/usr/lib64 I already success build > So I am wondering the --with-sysroot=$SYSROOT mean to search libs in > $SYSROOT, why it can't known ? > > Any suggestion ?
Re: Unexpected presence of __eprintf in libgcc.a when using newlib
On Tue, Apr 8, 2014 at 1:42 AM, Thomas Preud'homme
wrote:
>
> When playing with a toolchain built with --with-newlib switch, I recently
> noticed that libgcc.a includes __eprintf among its objects. However,
> gcc/doc/install.texi states that --with-newlib switches "causes
> @code{__eprintf} to be omitted from @file{libgcc.a} on the assumption that it
> will be provided by @samp{newlib}. And indeed, newlib provides __eprintf. Was
> the logic to omit __eprintf when newlib is used removed at some point for
> some reason or is it a bug?
I don't think anything uses __eprintf any more. The function has been
left behind for very very very old systems. Actually we could
probably remove it now. Probably the old support for not building
__eprintf when --with-newlib was specified has bitrotted.
Ian
Re: gcc build second pass : C compiler cannot create executables
2014-04-08 20:22 GMT+08:00 David Guillen : > Can you check whether crt1.o and crt1.o exist? And the path where they do > live. > Also it would be interesting to know the exact commandline (check config.log). Do you mean the commanline I build , here is : The total command list 0 perpare var in env modify .bashrc export HOST=x86_64-pc-linux-gnu export BUILD=$HOST export TARGET=x86_64-none-linux-gnu export CROSS_TOOL=/vita/cross-tool export CROSS_GCC_TMP=/vita/cross-gcc-tmp export SYSROOT=/vita/sysroot PATH=$CROSS_TOOL/bin:$CROSS_GCC_TMP/bin:/sbin:/usr/sbin:$PATH 1 build binutilss cd /vita/ mkdir source build cross-tool cross-gcc-tmp sysroot cd source/ cp -rf /mnt/hgfs/D/linux/source/* . cd .. cd build/ mkdir binutils-build cd binutils-build/ ../binutils-2.23.1/configure --prefix=$CROSS_TOOL --target=$TARGET --with-sysroot=$SYSROOT make -j2 make install Now have ld and so on modify .basrch and source ~/.bashrc export AR="$TARGET-ar" export AS="$TARGET-as" export RANLIB="$TARGET-ranlib" export LD="$TARGET-ld" export STRIP="$TARGET-strip" 2 build freestanding compiler first perpare gmp source cd /vita/ cd build/ tar -xvf ../source/gcc-4.7.2.tar.bz2 cd gcc-4.7.2/ tar -xvf ../../source/mpfr-3.1.1.tar.bz2 tar -xvf ../../source/mpc-1.0.1.tar.gz tar -xvf ../../source/gmp-5.0.5.tar.bz2 mv gmp-5.0.5/ gmp mv mpfr-3.1.1/ mpfr mv mpc-1.0.1/ mpc cd .. mkdir gcc-build1 cd gcc-build1/ ../gcc-4.7.2/configure --prefix=$CROSS_GCC_TMP --target=$TARGET --with-sysroot=$SYSROOT --with-newlib --enable-languages=c --with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src --with-mpfr-lib=/vita/build/gcc-build1/mpfr/.libs --disable-shared --disable-threads --disable-decimal-float --disable-libquadmath --disable-libmudflap --disable-libgomp --disable-nls --disable-libssp --disable-multilib make -j2 make install cd /vita/cross-gcc-tmp/ ln -s libgcc.a lib/gcc/x86_64-none-linux-gnu/4.7.2/libgcc_eh.a now have a cc modify .bashrc export CC="$TARGET-gcc" 3 build glibc cd .. cd build/ tar -xvf ../source/linux-3.7.4.tar.xz cd linux-3.7.4/ make mrproper make ARCH=x86_64 headers_check make ARCH=x86_64 INSTALL_HDR_PATH=$SYSROOT/usr/ headers_install cd .. tar -xvf ../source/glibc-2.15.tar.xz glibc-2.15/ cd glibc-2.15/ ../glibc-2.15/configure --prefix=/usr --host=$TARGET --enable-kernel=3.7.4 --enable-add-ons --with-headers=$SYSROOT/usr/include libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes libc_cv_ctors_header=yes patch -pl < ../../source/glibc-2.15-cpuid.patch patch -p1 < ../../source/glibc-2.15-s_frexp.patch make -j2 make install_root=$SYSROOT install now have glibc crt1.o in $sysroot/usr/lib64/ vita@engine-virtual-machine:/vita$ ls sysroot/usr/lib64/*.o sysroot/usr/lib64/crt1.o sysroot/usr/lib64/crtn.o sysroot/usr/lib64/Mcrt1.o sysroot/usr/lib64/crti.o sysroot/usr/lib64/gcrt1.o sysroot/usr/lib64/Scrt1.o 4 build second pass gcc cd .. mkdir gcc-build2 cd gcc-build2/ ../gcc-4.7.2/configure --prefix=$CROSS_TOOL --target=$TARGET --with-sysroot=$SYSROOT --with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src --with-mpfr-lib=/vita/build/gcc-build2/mpfr/src/.libs --enable-languages=c,c++ --enable-threads=posix attach the config.log > > 2014-04-08 14:13 GMT+02:00 Mo Jia : >> Try to make a gcc cross compiler , >> >> 0 perpare vars in env >> >> export HOST=x86_64-pc-linux-gnu >> export BUILD=$HOST >> export TARGET=x86_64-none-linux-gnu >> export CROSS_TOOL=/vita/cross-tool >> export CROSS_GCC_TMP=/vita/cross-gcc-tmp >> export SYSROOT=/vita/sysroot >> PATH=$CROSS_TOOL/bin:$CROSS_GCC_TMP/bin:/sbin:/usr/sbin:$PATH >> >> 1 build binutilss >> >> ../binutils-2.23.1/configure --prefix=$CROSS_TOOL \ >> --target=$TARGET --with-sysroot=$SYSROOT >> >> build success >> then add this lines to .bashrc And this want build glibc next use the >> tools I just build >> >> export AR="$TARGET-ar" >> export AS="$TARGET-as" >> export RANLIB="$TARGET-ranlib" >> export LD="$TARGET-ld" >> export STRIP="$TARGET-strip" >> >> 2 build freestanding compiler first perpare gmp source >> >> cd gcc-4.7.2/ >> tar -xvf ../../source/mpfr-3.1.1.tar.bz2 >> tar -xvf ../../source/mpc-1.0.1.tar.gz >> tar -xvf ../../source/gmp-5.0.5.tar.bz2 >> mv gmp-5.0.5/ gmp >> mv mpfr-3.1.1/ mpfr >> mv mpc-1.0.1/ mpc >> >> then cd to gcc-build1 >> >> ../gcc-4.7.2/configure --prefix=$CROSS_GCC_TMP --target=$TARGET \ >> --with-sysroot=$SYSROOT --with-newlib --enable-languages=c \ >> --with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src \ >> --with-mpfr-lib=/vita/build/gcc-build1/mpfr/src/.libs \ >> --disable-shared --disable-threads --disable-decimal-float \ >> --disable-libquadmath --disable-libmudflap --disable-libgomp \ >> --disable-nls --disable-libssp --disable-multilib >> >> succss . So add this line the ~/.bashrc (this will use this build >> gcc to bu
add_branch_dependences in sched-rgn.c
Hi all, I'm looking at some curious pre-reload scheduling behaviour and I noticed this: At the add_branch_dependences function sched-rgn.c there is a comment that says "branches, calls, uses, clobbers, cc0 setters, and instructions that can throw exceptions" should be scheduled at the end of the basic block. However right below it the code that detects this kind of insns seems to only look for these insns that are directly adjacent to the end of the block (implemented with a while loop that ends as soon as the current insn is not one of the aforementioned). Shouldn't the code look through the whole basic block, gather all of the branches, clobbers etc. and schedule them at the end? Any ideas? Thanks, Kyrill
Unable to match instruction pattern
I'm porting gcc to a 16 bit processor. Occasionally compiling
source such as
short v1;
long global;
global = (long)v1;
results in ...
(insn 11 10 12 2 (set (subreg:HI (mem/c:SI (symbol_ref:HI
("global") ) [2 global+0 S4 A16]) 2)
(const_int 0 [0])) t.c:15 -1
(nil))
(insn 12 11 13 2 (set (subreg:HI (mem/c:SI (symbol_ref:HI
("global") ) [2 global+0 S4 A16]) 0)
(reg:HI 24 [ D.1348 ])) t.c:15 -1
(nil))
The second of these instructions successfully matches a movhi
pattern which is found via the define_expand below
;the INTEGER iterator includes [QI HI SI]
(define_expand "mov"
[(set (match_operand:INTEGER 0 "nonimmediate_operand" "")
(match_operand:INTEGER 1 "general_operand" ""))]
""
{
if( can_create_pseudo_p() )
{
if( !register_operand( operands[0], mode )
&& !register_operand( operands[1], mode ))
{
/* one of the operands must be in a register. */
operands[1] = copy_to_mode_reg (mode,
operands[1]);
}
}
However the first instruction fails to match and be expanded so
that the const_int is forced into a register. I defined an
instruction which is an exact match
(define_insn "*storesic"
[
(set (subreg:HI (mem:SI (match_operand:HI 0
"symbol_ref_operand" "")) 2)
(match_operand:HI 1 "const_int_operand"))
]
This matches, however I need a scratch register (R? below) to
transform this into
loadR?, const_int_operand
store R?, address
and as soon as I add the match_scratch
(clobber(match_scratch:HI 2 "=r"))
the pattern no longer matches because expand calls recog() with
pnum_clobbers = 0 (NULL)
I a similar vein to the way CC setting instructions are handled I
tried defining a second instruction containing the required
match_scratch prior to the define_insn "*storesic" (see above) in
the hope that it may match subsequent to the expand pass, however
it is never seen.
Can anyone offer any insight to what I'm doing wrong and how I
might proceed ?
Thanks, Paul.
RE: Unexpected presence of __eprintf in libgcc.a when using newlib
> From: Ian Lance Taylor [mailto:i...@google.com] > > I don't think anything uses __eprintf any more. The function has been > left behind for very very very old systems. Actually we could > probably remove it now. Probably the old support for not building > __eprintf when --with-newlib was specified has bitrotted. Removing it would be great. I'm working on a patch to automatically pull support for floating point in printf/scanf and having eprintf in libgcc lead to such support to be always pulled in since it calls printf and the format used is not a string litteral. Should I propose a patch to remove it? Best regards, Thomas
Re: Unexpected presence of __eprintf in libgcc.a when using newlib
On Tue, Apr 8, 2014 at 8:14 PM, Thomas Preud'homme wrote: >> From: Ian Lance Taylor [mailto:i...@google.com] >> >> I don't think anything uses __eprintf any more. The function has been >> left behind for very very very old systems. Actually we could >> probably remove it now. Probably the old support for not building >> __eprintf when --with-newlib was specified has bitrotted. > > Removing it would be great. I'm working on a patch to automatically pull > support > for floating point in printf/scanf and having eprintf in libgcc lead to such > support > to be always pulled in since it calls printf and the format used is not a > string litteral. I think your patch is broken since the object file (_eprintf.o) should not be pulled in unless it is used and it is part of an archive and for archives cause the linker to only bring in object files which have things referenced to them. Thanks, Andrew Pinski > > Should I propose a patch to remove it? > > Best regards, > > Thomas > > >
Re: Unexpected presence of __eprintf in libgcc.a when using newlib
On Tue, Apr 8, 2014 at 8:19 PM, Andrew Pinski wrote: > On Tue, Apr 8, 2014 at 8:14 PM, Thomas Preud'homme > wrote: >>> From: Ian Lance Taylor [mailto:i...@google.com] >>> >>> I don't think anything uses __eprintf any more. The function has been >>> left behind for very very very old systems. Actually we could >>> probably remove it now. Probably the old support for not building >>> __eprintf when --with-newlib was specified has bitrotted. >> >> Removing it would be great. I'm working on a patch to automatically pull >> support >> for floating point in printf/scanf and having eprintf in libgcc lead to such >> support >> to be always pulled in since it calls printf and the format used is not a >> string litteral. > > I think your patch is broken since the object file (_eprintf.o) should > not be pulled in unless it is used and it is part of an archive and > for archives cause the linker to only bring in object files which have > things referenced to them. Also the comment in libgcc2.c is very clear of why it is still around: /* __eprintf used to be used by GCC's private version of . We no longer provide that header, but this routine remains in libgcc.a for binary backward compatibility. Note that it is not included in the shared version of libgcc. */ Thanks, Andrew Pinski > > Thanks, > Andrew Pinski > >> >> Should I propose a patch to remove it? >> >> Best regards, >> >> Thomas >> >> >>
RE: Unexpected presence of __eprintf in libgcc.a when using newlib
> From: Andrew Pinski [mailto:pins...@gmail.com] > > I think your patch is broken since the object file (_eprintf.o) should > not be pulled in unless it is used and it is part of an archive and > for archives cause the linker to only bring in object files which have > things referenced to them. Indeed, and after spending more time on it it is clear that the culprit is a function in another library (and that function is needed unfortunately). So no problem with eprintf in libgcc.a after all, sorry for the noise. Best regards, Thomas
