Adding all SVN branches to git tree

[Andi Kleen]

Hi,

I wanted to experiment with some of the google branch features
(like AutoFDO). But the google branches are not in the standard
git tree, only in SVN. My workflow is all git based, so it was difficult
to fit a SVN checkout in. I tried to git svn clone myself, but it takes
a very long time and was not really successfull.

So questions:
- Is there an uptodate git tree somewhere with these branches?
- Any chance to add all branches from SVN to the standard git mirror?

Thanks,

-Andi

Re: Adding all SVN branches to git tree

[Andreas Schwab]

Andi Kleen  writes:

> - Any chance to add all branches from SVN to the standard git mirror?

Actually they are already there, in refs/remotes/google, though they are
awkwardly lumped together in a single tree.

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: Adding all SVN branches to git tree

[Thomas Schwinge]

Hi!

On Wed, 23 Oct 2013 10:59:57 +0200, Andreas Schwab  wrote:
> Andi Kleen  writes:
> 
> > - Any chance to add all branches from SVN to the standard git mirror?
> 
> Actually they are already there, in refs/remotes/google, though they are
> awkwardly lumped together in a single tree.

.


Grüße,
 Thomas


pgp51iNd9tLVr.pgp
Description: PGP signature

Re: Adding all SVN branches to git tree

[Andi Kleen]

On Wed, Oct 23, 2013 at 11:06:39AM +0200, Thomas Schwinge wrote:
> Hi!
> 
> On Wed, 23 Oct 2013 10:59:57 +0200, Andreas Schwab  wrote:
> > Andi Kleen  writes:
> > 
> > > - Any chance to add all branches from SVN to the standard git mirror?
> > 
> > Actually they are already there, in refs/remotes/google, though they are
> > awkwardly lumped together in a single tree.
> 
> .

Thanks.

But that's all really awkward, and the obvious option messes up the 
checkout dir totally.

It would be still far easier if all these branches became normal
git branches. Is there any reason this is not done?

-andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: Adding all SVN branches to git tree

[Andreas Schwab]

Andi Kleen  writes:

> It would be still far easier if all these branches became normal
> git branches. Is there any reason this is not done?

You would have to set it up manually, for each and every branch.

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: Include file visibility scopes? (Was: Re: [RFC] Include file structuring.)

[Diego Novillo]

On Tue, Oct 22, 2013 at 11:09 PM, Joern Rennecke
 wrote:

> I wonder what it'd take to have a cpp extension to include a file in
> such a manner as to
> emit a diagnostic if the items declared / #defined inside are used
> directly by a file
> that includes the file that does the thus guarded include.
> We already have some tracking of where source comes from now for the purposes
> of printing include backtraces...
> Woud probably want to re-set the usable scope if there is a later include of 
> the
> same file, mutliple-include-guards notwithstanding...

You are describing something very similar to the IWYU tool:
https://code.google.com/p/include-what-you-use/

It's harder than it looks. I spent some time working on it when we
were developing it as a GCC plugin. It's now a proper clang client,
but it's not foolproof.  I have not looked into it in years, so I
don't know what the current state is.


Diego.

Ann.: MELT 1.0 [rc2] plugin (release candidate 2) for GCC 4.7 or better

[Basile Starynkevitch]

Dear All,


It is my pleasure to announce the MELT 1.0 release candidate 2 
plugin for GCC 4.7 or newer.

MELT is a high-level domain specific language (with a Lispy look) 
- see http://gcc-melt.org/ for more - designed to extend the GCC compiler.

MELT 1.0 is a major release (today a release candidate 2). 
You can download the release candidate 2 from
   http://gcc-melt.org/melt-1.0-rc2-plugin-for-gcc-4.7-or-4.8.tar.bz2
it is a bzip2-ed source tarball of 3866954 bytes (3.7Mbytes) of md5sum 
e013c220b73062b23efc3904bace64a4; it is extracted from MELT branch 
svn 203972 on october 22nd 2013.

MELT 1.0 rc2 brings a lot of improvements and enhancements w.r.t. to previous 
MELT releases. From its README-MELT-PLUGIN file:


NEWS for 1.0 MELT plugin for GCC 4.7 & 4.8 [and future 4.9?]
[[end of october, 2013]]

This is a major release (with perhaps some small incompatibilities
with previous MELT plugin releases). A lot of new features are
appearing. Much more ability to mix arbitrary C/C++ & MELT code in any
way, and lots of new features both inside the MELT language and the
MELT plugin, even for newbies. Some modes are now available and could
be useful even without understanding much of the MELT domain specific
language.

MELT 1.0 is usable with GCC 4.7 and 4.8 but not usable with GCC 4.6 or
earlier, because it requires a GCC compiler written in C++ and because
it is generating C++ code.

   End-user improvements
   =

  
 * Several MELT modes are usable without real knowledge of the MELT
   domain specific language, notably -fplugin-arg-melt-mode=findgimple
   (to find all gimples matching some given gimple pattern in all
   functions whose declaration matches a given tree pattern) and
   -fplugin-arg-melt-mode=justcountipa (to count gimples and basic
   blocks at the Inter-Procedural Analysis stage).

  Some examples of findgimple modes:


  + Find all calls to malloc with a constant size greater than 100:

  gcc -fplugin=melt -fplugin-arg-melt-mode=findgimple \
-fplugin-arg-melt-arg='  
?(gimple_call_1 ?_
  ?(tree_function_decl_of_name "malloc" ?_ ?_)  
  ?(tree_integer_cst ?(some_integer_greater_than 100))
)' -O2 -c yourcode.c
  
  The above command is generating some C++ code and slowly compiling
  it then dlopen-ing it, every time you run that command. To make it
  faster, you may want to generate a MELT module findmallocgt100 once,
  and use that module to search mallocs on many files:

  gcc -fplugin=melt -fplugin-arg-melt-mode=findgimple \
  -fplugin-arg-melt-arg='
  ?(gimple_call_1 ?_
?(tree_function_decl_of_name "malloc" ?_ ?_)
?(tree_integer_cst ?(some_integer_greater_than 100))
  )' -fplugin-arg-melt-output=findmallocgt100 -c empty-file.c

  You'll get a bunch of files with name starting with findmallocgt100.

  Then you can quickly search that pattern using

  gcc -fplugin=melt -fplugin-arg-melt-extra=findmallocgt100 \
  -fplugin-arg-melt-mode=gofindgimple -O2 yourfile.cc

  and this should run much faster, because no C++ code needs to be
  generated and compiled.

 
 ***
 * When verbose, all the successful modes are displayed.

   Language improvements
   =

 ***
 * It is possible to define macros with defmacro (taking four
  arguments: the s-expression to be macro-expanded, the environment,
  the macro-expander function, the module context). Such macros can be
  used in the same MELT module defining them, but should expand to a 
  source AST which you would be able to read...

 ***
 * It is possible to define locally bound macros with the :macro annotation
 in let bindings.

 *** 
 * at_macro_expansion macro can be used to define functions (and
  instances, etc...) used only at macro-expansion time of further
  defmacro-defined macros.

 ***
 * Macros defined by defmacro and definition given inside at_macro_expansion 
 are evaluated in a separate environment so don't see the ordinary bindings 
 currently defined in the MELT source.

 ***
 * The comma operator, only usefine inside anti-quotations (thru
  backquote) is expanded to a sequence of sub-expressions if the
  anti-quotation gives a sequence, i.e. a tuple or a list. So no
  comma-at operator is needed.

 ***
 * quotes, anti-quotes (with backquote), and comma operators are
 possible even on arbitrary s-expressions. But quotations and
 antiquotations of s-exprs have their location slightly less precise
 (only file name and line number, but not column number, are
 preserved)

   Runtime improvements
   

  *** 
  * The debug macro accepts debug manipulator which alters the way
   the next argument is debug-printed, e.g. 
   (DEBUG "here smaller debug of x=" DEBUG_LESS x)

  ***
  * The variadic ERROR_AT WARNING_AT and INFORM_AT functions are available
  for diagnostics. T

RE: Cilk Library

[Iyer, Balaji V]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 23, 2013 1:15 AM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (al...@redhat.com); r...@redhat.com; Jason Merrill
> (ja...@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/16/13 13:30, Iyer, Balaji V wrote:
> >> First, the all issues Joseph mentioned need to be addressed.  So
> >> first, you need to ensure it's only being built on x86/x86_64 given
> >> the asms and bring together some documentation as to what's needed to
> port the
> >> runtime system to other architectures.   Closely related, I think you
> >> initially need to ensure it only builds on x86-linux platforms --
> >> unless you've already verified it works properly on one or more of
> >> the bsd platforms, solaris, windows, etc.
> >>
> >
> > We are in the process of addressing all these. I will send out an email 
> > with the
> fixed runtime as soon as I can.
> Excellent.  THanks.
> 
> 
> >> I would strongly echo Joseph's recommendation to ensure that only
> >> those symbols specifically intended to be part of the public
> >> interface are exported from the shared library. How stable has the exported
> API/ABI
> >> for Cilk+ been?Related: how clean is the RTS from a compile-time
> >> namespace pollution standpoint.  For C++ is everything in a
> >> namespace, for C is everything prefixed appropriately?
> >>
> >
> > We are currently verifying those and making sure only the required symbols
> are exported.
> IMHO, the best way to do this is with linker scripts and it's an excellent 
> time ot
> drop in versioning information.  I'd think this would be useful for ICC as 
> well.
> This is probably the biggest issue.  I'll note Richi chimed in on this as 
> well.
> 
Yup we have implemented versioning. Also, we have just completed all the things 
that Joseph Myers mentioned and are in the process of testing it. I will send 
out a revised patch this week itself.

> Look at libatomic/libatomic.map and how that gets used.  It gives you full
> control over the exports.
> 
> jeff

Re: Git mirror: asan branch

[Tom de Vries]

On 04/07/13 14:59, Thomas Schwinge wrote:
> Hi!
> 
> On Wed, 3 Jul 2013 09:54:58 -0700, Jason Merrill  wrote:
>> On 07/03/2013 02:47 AM, Thomas Schwinge wrote:
>>> OK, that of course works, but from the wiki page I got the idea that it
>>> explicitly was meant to merge these together.  So assuming this used to
>>> work in the past, I wonder what so that it no longer does; such as Git
>>> allowing such duplicates merging in the past, and/or was the intersection
>>> of refs/remotes/* and refs/heads/* meant to be the empty set (then I
>>> assume the merging would work, too), but no longer is?
>>
>> Hmm, it looks like I wrote that up without actually doing it myself, 
>> oops.  I'll correct the wiki.
> 
> Hmm, seems the change you've done:
> 
> fetch = refs/heads/*:refs/remotes/origin/*
> fetch = refs/remotes/*:refs/remotes/origin/remotes/*
> 
> ..., is not ideal either: using »git fetch --verbose --prune« I now see
> all the refs being downloaded -- and then immediatelly pruned again.  :-/
> 
> Would the following be an appropriate variant?  Seems to work fine, but
> "disturbs" the regular Git refs namespace a bit?
> 
> fetch = refs/heads/*:refs/remotes/upstream/*
> fetch = refs/remotes/*:refs/remotes/upstream-remotes/*
> 

Jason,

AFAIU you addressed this issue in the gcc wiki r108 (
http://gcc.gnu.org/wiki/GitMirror?action=diff&rev1=107&rev2=108 ) on 2013-07-11.

However, I ran into the same problem with 'The various release branches':
...
$ for f in 4_8 ; do git config --add remote.origin.fetch
refs/remotes/gcc-$f-branch:refs/remotes/origin/gcc-$f-branch; done
$ git remote update
Fetching origin
fatal: refs/remotes/origin/gcc-4_8-branch tracks both refs/heads/gcc-4_8-branch
and refs/remotes/gcc-4_8-branch
error: Could not fetch origin
...

Following the changes you made in 'Fetching all branches', the command becomes:
...
git config --add remote.origin.fetch
refs/remotes/gcc-$f-branch:refs/remotes/svn/gcc-$f-branch
...

I could try that out, but apparently something more is needed:
...
Unfortunately, this doesn't work well with the git-svn configuration set up
above, because it expects the branches to be in remotes/origin. One way to deal
with this is to switch git-svn to use remotes/svn instead and adjust your local
branches to use remotes/svn for their upstream.
...
Can you translate the last sentence into shell/git command(s)?

Thanks
- Tom

RE: Cilk Library

[Iyer, Balaji V]

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.

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 23, 2013 1:15 AM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (al...@redhat.com); r...@redhat.com; Jason Merrill
> (ja...@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/16/13 13:30, Iyer, Balaji V wrote:
> >> First, the all issues Joseph mentioned need to be addressed.  So
> >> first, you need to ensure it's only being built on x86/x86_64 given
> >> the asms and bring together some documentation as to what's needed to
> port the
> >> runtime system to other architectures.   Closely related, I think you
> >> initially need to ensure it only builds on x86-linux platforms --
> >> unless you've already verified it works properly on one or more of
> >> the bsd platforms, solaris, windows, etc.
> >>
> >
> > We are in the process of addressing all these. I will send out an email 
> > with the
> fixed runtime as soon as I can.
> Excellent.  THanks.
> 
> 
> >> I would strongly echo Joseph's recommendation to ensure that only
> >> those symbols specifically intended to be part of the public
> >> interface are exported from the shared library. How stable has the exported
> API/ABI
> >> for Cilk+ been?Related: how clean is the RTS from a compile-time
> >> namespace pollution standpoint.  For C++ is everything in a
> >> namespace, for C is everything prefixed appropriately?
> >>
> >
> > We are currently verifying those and making sure only the required symbols
> are exported.
> IMHO, the best way to do this is with linker scripts and it's an excellent 
> time ot
> drop in versioning information.  I'd think this would be useful for ICC as 
> well.
> This is probably the biggest issue.  I'll note Richi chimed in on this as 
> well.
> 
> Look at libatomic/libatomic.map and how that gets used.  It gives you full
> control over the exports.
> 
> jeff

RE: Cilk Library

[Joseph S. Myers]

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=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.

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.

(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.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Cilk Library

[Jeff Law]

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=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.


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: Git mirror: asan branch

[Andi Kleen]

Tom de Vries  writes:
> ...
> Can you translate the last sentence into shell/git command(s)?

It would be far better to just centrally mirror all branches in SVN as 
standard git branches. Then all these problems wouldn't occur.

As far as I can tell all the workarounds proposed so far 
have some nasty drawbacks.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Re: unrecognized command line option '-mlong-double-80' '-fbuilding-libgcc'

[Dmitry Mikushin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/lib/
- -isystem
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/include
- -isystem
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/sys-include
   -m32 -gtoggle  -static-libstdc++ -static-libgcc  conftest.c  >&5
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/bin/kernelgen-ld:
error:
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/crtbegin.o:
incompatible target
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/bin/kernelgen-ld:
error:
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/crtend.o:
incompatible target
collect2: error: ld returned 1 exit status

So, crtbegin.o/crtend.o are still ELF64.

On 10/24/2013 07:07 AM, Ian Lance Taylor wrote:
> On Wed, Oct 23, 2013 at 9:59 PM, Dmitry Mikushin
>  wrote:
>> Still all sorts of problems:
>> 
>> with BOOT_CFLAGS="-m32" and CFLAGS_FOR_TARGET="-m32" I get a
>> number of compilation errors e.g. "error: unknown type name
>> 'UTItype'" with BOOT_CFLAGS="-m32" only I get "configure: error:
>> Link tests are not allowed after GCC_NO_EXECUTABLES."
> 
> 
> Should have said this last time: please reply to the mailing list,
> not just to me.  Thanks.
> 
> I would not expect to see the "Link tests" error unless you are
> still using the --build/--host/--target configure arguments.  I
> was suggesting that you omit those.
> 
> Ian
> 
>> 2013/10/24 Ian Lance Taylor 
>>> 
>>> 
>>> On Oct 23, 2013 8:27 PM, "Dmitry Mikushin"
>>>  wrote:
 
 Dear Ian,
 
 I started exactly with adding -m32 options as you mentioned,
 but in this case the resulting toolchain executables are
 ELF64.
>>> 
>>> You'll probably also have to set BOOT_CFLAGS or something like
>>> that--see the install instructions.
>>> 
>>> Ian
>>> 
 2013/10/21 Ian Lance Taylor 
> 
> On Sun, Oct 20, 2013 at 10:04 PM, Dmitry Mikushin 
>  wrote:
>> 
>> I'm trying to build a GCC toolchain (4.8-20130912
>> snapshot) targeting x86-64 multiarch on i686 host, using
>> x86-64 builder:
>> 
>> + cd
>> 
>> /home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912
>>
>> 
+ mkdir build
>> + cd build/ + CC=gcc -m32  CXX=g++ -m32  FC=gfortran -m32
>> F77=gfortran -m32 ../configure --enable-build-with-cxx -
>

question about register pairs

[DJ Delorie]

The docs say to use HARD_REGNO_MODE_OK to enforce register pairs.

But reload (find_valid_class_1) rejects classes that include such
registers:

  for (regno = 0; regno < FIRST_PSEUDO_REGISTER && !bad; regno++)
{
  if (in_hard_reg_set_p (reg_class_contents[rclass], mode, regno)
  && !HARD_REGNO_MODE_OK (regno, mode))
{
  bad = 1;

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?