Re: unrecognized command line option '-mlong-double-80' '-fbuilding-libgcc'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, it's getting better with --enable-multilib, BOOT_CFLAGS="-m32" and XGCC_FLAGS_FOR_TARGET="-m32". But the internal xg++ still tries to pick up 64-bit libraries (see below). The question is how to make him switch to the */32/* multilib libraries path. $ /home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/xg++ - -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/ - -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/bin/ - -nostdinc++ - -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs - -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs - -I/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu - -I/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include - -I/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/libstdc++-v3/libsupc++ - -L/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs - -L/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -m32 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti - -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings - -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long - -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H - -static-libstdc++ -static-libgcc -o gfortran gcc.o ggc-none.o gfortranspec.o driver-i386.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ../../gcc/vec.h:1303: error: undefined reference to 'operator new(unsigned int)' collect2: error: ld returned 1 exit status On 10/24/2013 07:51 AM, Dmitry Mikushin wrote: > Ian, > > I'm NOT using --build/--host/--target: > > + CC=gcc -m32 CXX=g++ -m32 FC=gfortran -m32 F77=gfortran -m32 > ../configure --enable-build-with-cxx - > --prefix=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/ > > - --program-prefix=kernelgen- --enable-languages=fortran,c++ > - > --with-mpfr-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/ > > - - > --with-mpfr-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib > > - - > --with-gmp-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/ > > - - > --with-gmp-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib > > - - > --with-mpc-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/ > > - - > --with-mpc-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib > > - --enable-plugin --enable-gold=default --disable-ld > - > --with-ld=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/bin/kernelgen-ld > > - --disable-multilib > - > --libdir=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/lib > > But I get: > > checking dynamic linker characteristics... configure: error: Link > tests are not allowed after GCC_NO_EXECUTABLES. > > Or actually even earlier than that there is > > configure:2934: checking for C compiler default output file name > configure:2956: > /home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/xgcc > > - - > -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/ > > - - > -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/bin/ > > - - > -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/bin/ > > - - > -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-lin
GCC 4.9.0 Status Report (2013-10-24), Stage 1 ends Nov 21
Status == The trunk is scheduled to transition from Stage 1 to Stage 3 at the end of Thursday, Nov. 21 (use your timezone to your advantage). We have been in Stage 1 for more than 7 months now with almost a full month still to go. Still now is a good time to look into bugzilla and pick one or two regressions in your area of expertise and fix them (you may want to prioritize regressions against both 4.8 and 4.9). Somewhat misleading quality data below (so I omit deltas), P3 bugs have not been re-prioritized for quite some time now. We promise to do this before entering Stage 3. Quality Data Priority # Change from Last Report --- --- P11 P2 72 P3 142 --- --- Total 215 Previous Report === http://gcc.gnu.org/ml/gcc/2013-03/msg00125.html The next report will be sent by me when entering Stage 3.
gcc/configure handling $host == $target but different $build
Hi,
I saw incorrect gcc/configure results when building a native compiler
with a cross compiler. I think I understand what is going wrong there
but looking for your opinion on my thoughts:
Let's get through the thing with an example.
Assume:
$build == i686-pc-linux-gnu
$host == $target == arm-linux-gnu
Let's further assume my build system has sys/sdt.h, while my target does not.
In this scenario gcc/configure incorrectly concludes that my target
has sys/sdt.h.
This seems to happen like this:
Since $host == $target and there is no $TARGET_SYSTEM_ROOT set (The
compiler I am building that way will operate as a native compiler.)
configure concludes target_header_dir=${native_system_header_dir}
This conclusion seems wrong in case $build != $target and because of
that all tests for target headers are done on the build system instead
of the sys-root for the target.
Did I miss something that I should have set for this specific scenario
or do you agree that I should patch the configure to consider in case
of $host == $target the special case of $build != $target, in which
case I should figure out the location of the build system compiler's
sys-root and set target_header_dir to that one?
That means something like:
if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
[... some other code not of interest here ...]
elif test x$build != x$target; then
target_header_dir=${sysroot_of_build_cc_header_dir}
else
target_header_dir=${native_system_header_dir}
fi
assuming that I can figure out sysroot_of_build_cc_header_dir in some way.
Robert
Re: gcc/configure handling $host == $target but different $build
Robert Schiele writes: > Let's further assume my build system has sys/sdt.h, while my target does not. I think the check for sys/sdt.h should be moved to libgcc where it is actually used (it predates the complete migration of libgcc out of gcc). Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
RE: Cilk Library
Hi Joseph and Jeff, The issue you mentioned below is fixed. I added a configure.tgt file in libcilkrts and modified configure.ac (both libcilkrts and the toplevel gcc one) accordingly. Here is a link for the patch (https://drive.google.com/file/d/0BzEpbbnrYKsSZFR6cktQQWtXQms/edit?usp=sharing). Thanks, Balaji V. Iyer. > -Original Message- > From: Jeff Law [mailto:l...@redhat.com] > Sent: Wednesday, October 23, 2013 4:33 PM > To: Joseph S. Myers; Iyer, Balaji V > Cc: gcc@gcc.gnu.org; Aldy Hernandez (al...@redhat.com); r...@redhat.com; > Jason Merrill (ja...@redhat.com) > Subject: Re: Cilk Library > > On 10/23/13 14:22, Joseph S. Myers wrote: > > On Wed, 23 Oct 2013, Iyer, Balaji V wrote: > > > >> Hi Jeff et al., > >>Here is a link to the updated patch > >> > (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=s > haring). > >> We have fixed all the issues that Joseph pointed out in > >> http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added > >> symbol versioning and have double-checked (using nm) that all symbols > >> are hidden unless we have explicitly allowed them to be public. > > > > As I said in my previous comments, please follow libatomic, libitm, > > libsanitizer or libvtv in using a configure.tgt file in the library's > > subdirectory to describe what systems are supported. This is > > especially important now that all toplevel patches need applying to > > three rather than two repositories (GCC SVN, src CVS, binutils-gdb > > git) - anything logically specific to one of those three should go in > > an appropriate subdirectory whenever possible, to reduce the number of > > changes needing syncing to multiple places. > It also just makes sense from a modularity point of view. Whether or not > cilkrts > is supported is a property of cilkrts and thus code to detect that and "do the > right thing" should live within the cilkrts directory. > > > > (Yes, there's lots of configuration specific to newlib/libgloss, > > binutils, gdb or individual GCC libraries that's still hardcoded in > > the toplevel configure.ac and should move to such configure.tgt or > > similar files in subdirectories. Patches moving it to such files are > > certainly > welcome. > > But at least we shouldn't add new directories with details at toplevel > > of what targets they support.) > Agreed. There's a lot of cruft up there that needs to move down into the > subdirectories. Unfortunately there's not many people actively working to > address these maintenance issues. > > > I didn't see anything else grossly wrong. I think once the > configure.tgt stuff is addressed, this patch is good to go. As > previously discussed, don't actually check it in until the final approval is > in place > for the keywords. > > jeff
Re: Cilk Library
On 10/23/2013 12:30 PM, Iyer, Balaji V wrote:
> Hi Jeff et al.,
> Here is a link to the updated patch
> (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=sharing).
> We have fixed all the issues that Joseph pointed out in
> http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added symbol
> versioning and have double-checked (using nm) that all symbols are hidden
> unless we have explicitly allowed them to be public.
>
In file included from ../../../git-master/libcilkrts/runtime/cilk-abi.c:52:0:
../../../git-master/libcilkrts/include/cilk/cilk_api.h:59:9: warning: #warning
Cilk API is being used with non-Cilk compiler (or Cilk is disabled) [-Wcpp]
# warning Cilk API is being used with non-Cilk compiler (or Cilk is
disabled)
and similar for
../../../git-master/libcilkrts/runtime/global_state.cpp:44
../../../git-master/libcilkrts/runtime/reducer_impl.cpp:59
../../../git-master/libcilkrts/runtime/scheduler.c:74:0:
> CILKABI1
> {
> global:
> __cilkrts_bind_thread_1;
> __cilkrts_bump_loop_rank;
> __cilkrts_bump_loop_rank_internal;
> __cilkrts_bump_worker_rank;
> __cilkrts_bump_worker_rank_internal;
> __cilkrts_enter_frame_1;
> __cilkrts_enter_frame_fast_1;
> __cilkrts_get_pedigree_info;
> __cilkrts_get_pedigree_internal;
> __cilkrts_get_sf;
> __cilkrts_get_stack_size;
> __cilkrts_get_worker_rank;
> __cilkrts_save_fp_ctrl_state;
> __cilkrts_stack_alloc;
> __cilkrts_stack_free;
> __cilkrts_watch_stack;
> };
You probably want CILKABI1 to inherit from CILKABI0. E.g.
} CLKABI0;
Is there any relation between these and CILKLIB1.02?
r~
Re: question about register pairs
On 24 October 2013 07:59, DJ Delorie wrote: > In the past, if I use a register class that excludes the second half > of register pairs, it can't do anything because it requires both parts > of the register pair to be in the class (example: in_hard_reg_set_p > checks this). > > Which way is the "right" way? IMHO, the documented way. We don't want an explosion of mode-dependent register classes. find_valid_class_1 is used only from a single place, where a SYMBOL_REF is reloaded, and the mode that the register is required to be valid in is the mode of the SYMBOL_REF. So the problem will only show up for targets where a SYMBOL_REF takes more than one hard register. I think the way to fix this is to change the inner loop of find_valid_class_1 to increment regno by HARD_REGNO_NREGS [regno, mode] .
RE: Cilk Library
Hi Richard,
Here is the link to the fixed patch
(https://drive.google.com/file/d/0BzEpbbnrYKsSNmpmM3NlRThfcWc/edit?usp=sharing).
Answers to your questions are given below.
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Thursday, October 24, 2013 12:15 PM
> To: Iyer, Balaji V; Jeff Law; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (al...@redhat.com); Jason Merrill (ja...@redhat.com);
> Joseph S. Myers
> Subject: Re: Cilk Library
>
> On 10/23/2013 12:30 PM, Iyer, Balaji V wrote:
> > Hi Jeff et al.,
> > Here is a link to the updated patch
> (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=s
> haring). We have fixed all the issues that Joseph pointed out in
> http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added
> symbol versioning and have double-checked (using nm) that all symbols are
> hidden unless we have explicitly allowed them to be public.
> >
>
>
> In file included from ../../../git-master/libcilkrts/runtime/cilk-abi.c:52:0:
> ../../../git-master/libcilkrts/include/cilk/cilk_api.h:59:9: warning:
> #warning Cilk
> API is being used with non-Cilk compiler (or Cilk is disabled) [-Wcpp]
> # warning Cilk API is being used with non-Cilk compiler (or Cilk is
> disabled)
>
> and similar for
>
> ../../../git-master/libcilkrts/runtime/global_state.cpp:44
> ../../../git-master/libcilkrts/runtime/reducer_impl.cpp:59
> ../../../git-master/libcilkrts/runtime/scheduler.c:74:0:
To compile Cilk Library (libcilkrts), the compiler must have _Cilk_spawn and
_Cilk_sync support. For this patch, I have defined (please see Makefile.am
under GENERAL_FLAGS) the cilk-keywords to NULL to make this patch compile. When
I commit this patch, I will commit the patches in the following order (after
everything is approved that is):
1. Commit the _Cilk_spawn and _Cilk_sync for C and C++
2. Remove the -D_Cilk_spawn="" and -D_Cilk_sync="" and -D_Cilk_for=for from the
Makefile.am
3. Commit the Cilk library patch
If we do it in the above order, you won't see those warnings.
>
> > CILKABI1
> > {
> > global:
> > __cilkrts_bind_thread_1;
> > __cilkrts_bump_loop_rank;
> > __cilkrts_bump_loop_rank_internal;
> > __cilkrts_bump_worker_rank;
> > __cilkrts_bump_worker_rank_internal;
> > __cilkrts_enter_frame_1;
> > __cilkrts_enter_frame_fast_1;
> > __cilkrts_get_pedigree_info;
> > __cilkrts_get_pedigree_internal;
> > __cilkrts_get_sf;
> > __cilkrts_get_stack_size;
> > __cilkrts_get_worker_rank;
> > __cilkrts_save_fp_ctrl_state;
> > __cilkrts_stack_alloc;
> > __cilkrts_stack_free;
> > __cilkrts_watch_stack;
> > };
>
> You probably want CILKABI1 to inherit from CILKABI0. E.g.
The inheritance is added.
>
> } CLKABI0;
>
> Is there any relation between these and CILKLIB1.02?
>
There is no relation. They simply are exported by the same shared object.
>
> r~
Re: Cilk Library
On 10/24/2013 01:43 PM, Iyer, Balaji V wrote: >> In file included from ../../../git-master/libcilkrts/runtime/cilk-abi.c:52:0: >> ../../../git-master/libcilkrts/include/cilk/cilk_api.h:59:9: warning: >> #warning Cilk >> API is being used with non-Cilk compiler (or Cilk is disabled) [-Wcpp] >> # warning Cilk API is being used with non-Cilk compiler (or Cilk is >> disabled) >> >> and similar for >> >> ../../../git-master/libcilkrts/runtime/global_state.cpp:44 >> ../../../git-master/libcilkrts/runtime/reducer_impl.cpp:59 >> ../../../git-master/libcilkrts/runtime/scheduler.c:74:0: > > To compile Cilk Library (libcilkrts), the compiler must have _Cilk_spawn and > _Cilk_sync support. For this patch, I have defined (please see Makefile.am > under GENERAL_FLAGS) the cilk-keywords to NULL to make this patch compile. > When I commit this patch, I will commit the patches in the following order > (after everything is approved that is): > > 1. Commit the _Cilk_spawn and _Cilk_sync for C and C++ > 2. Remove the -D_Cilk_spawn="" and -D_Cilk_sync="" and -D_Cilk_for=for from > the Makefile.am > 3. Commit the Cilk library patch > > If we do it in the above order, you won't see those warnings. Fair enough. I just didn't know what the warnings meant. r~
