lto-plugin: mismatch between ld's architecture and GCC's configure --host

[Thomas Schwinge]

Hi!

This is a bit of a weird scenario -- but it is supposed to work fine in
my opinion (but doesn't).

I have a GNU toolchain as 32-bit x86 GNU/Linux executables, configured to
to generate code for 32-bit x86 by default, and using -m64 for x86_64.

This toolchain I'm using on a x86_64 system (which can execute 32-bit
executables) to build a *native* GCC, that is I'm using the 32-bit
toolchain to build a x86_64 GCC (configuring with CC='gcc -m64' CXX='g++
-m64').  I intend to continue using the 32-bit toolchain's linker, which
also is a 32-bit executable (GNU ld).  That one also defaults to x86
code, but can handle the x86_64 case fine if passed -m elf_x86_64, which
GCC does.

That the linker is a 32-bit executable is an implementation detail that
is not important generally: it's a separate process living in its own
address space.  However it becomes relevant in the case of linker
plugins: the native x86_64 GCC that I'm building also builds a x86_64
lto-plugin, which the 32-bit ld cannot load:

$ gcc/xgcc -B[...] [...]/gcc.c-torture/execute/ieee/2320-1.c [...] 
-flto [...]
[...]/ld: [...]/gcc/liblto_plugin.so: error loading plugin: 
[...]/gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
collect2: error: ld returned 1 exit status

So, aside from building a 64-bit ld (which is the "lame" alternative), I
now need to teach GCC's build system that the lto-plugin may need special
configuration: CC='gcc -m32' -- and possibly its own build of libiberty,
too, which it may depend on (but doesn't in my case, so I might cut this
short, and just error out).  Instead of auto-detecting the linker's
architecture (and then, what to do with that information?), I intend to
make this a manual process (so, some new top-level configure
argument(s)).  Adding yet another set of {...,CC,...}_FOR_[something] is
probably overkill -- I'll try to find something simpler.

Any comments on this scenario?


Grüße,
 Thomas


pgp1uslEYFIix.pgp
Description: PGP signature

Regex support

[Gurvinder Singh]

Does gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) has the support
for regex library ?
Because I am getting the core dumped error every time I try to run an
example program for it. If somehow i remove the error , the output is
not as required.

-- 
Gurvinder Singh
www.puresingh.wordpress.com

Re: Regex support

[Paolo Carlini]

Hi

Gurvinder Singh  ha scritto:
>Does gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) has the support
>for regex library ?

Nope, it doesn't. The implementation status page should be pretty clear about 
that. 4.9.0 will, however, you are welcome to build snapshots/svn check outs 
and give it a try!

Thanks,
Paolo

Error message source line display

[Fredrik Tolf]

Dear list,

I just recently got GCC 4.8 since Debian updated their Testing repository 
with it, and noted the error message source line display which was added. 
I then also noted it in the release notes, and while it seems to have been 
a commonly requested feature, I thought I'd offer some critique against 
it.


I find that the vast majority of error causes are obvious when one goes to 
the indicated line number (which one has to do anyway to fix it) and 
simply looks at the line, so I find the source line and caret display to 
be superfluous (and the column number is included in the main error line 
anyway). On the other hand, they make every error message take up three 
lines of screen-space instead of just one, where more error messages could 
be display instead. Summa summarum, I find that they merely make the error 
and warning output needlessly verbose, while adding nothing that I find of 
value.


I did find that there is the `-fno-diagnostics-show-caret` to turn them 
off, but it's quite bothersome to have to specify that every single time I 
compile something, and passing it through Makefiles' CFLAGS options 
shadows other flags that are turned on by default. It's also rather long 
and as such obscures the main command. As far as I know, there's no way to 
set these options "by default" for GCC, either via environment variables 
nor via some configuration file. Though, if I'm wrong on this, please 
correct me.


It would make me happy if something were done to address this. It seems it 
wouldn't be appreciated to have them disabled by default, but it would at 
least be quite nice to have some way to turn them off "globally" via some 
kind of configuration. I cannot pretend to know what method the GCC 
community would prefer, however.


Thanks for reading!

--
Fredrik Tolf