headers
Ian Lance Taylor | 1 May 2012 01:14
Picon
Favicon
Gravatar

Re: Inconsistency between -Xassembler and -Wa option

Mohamed Shafi <shafitvm <at> gmail.com> writes:

> I have a question about the -Xassembler option. I was testing and ran
> across some inconsistency between the -Xassembler option and the -Wa
> option. I was wondering if I am using an option incorrectly or if
> there is indeed something wrong.
>
> I call gcc on a .s file and I pass -v option to get the version of the
> assembler...
>
> 1st time, call gcc -Xassembler -v file ....expect assembler version
> 2nd time, call gcc -Wa,-v file ....expect assembler version
> 3rd time, call gcc -v file ....expect compiler commands and version
>
> The results show that 1st and 3rd results are nearly the same, while
> 2nd result gives me just the assembler version. It seems like
> -Xassembler is not just restricted to assembler options.
>
> Is this expected ?

I think this is a bug that was fixed in the GCC 4.6 release.

Ian
Permalink | Reply | 0 comments |
headers
Mihai Badea | 1 May 2012 13:19
Picon
Gravatar

Fwd: binutils>=2.16 is required to build GCC 4.7.0 for i686-pc-linux-gnu

Hello, I thought I would share this in case anyone else gets this
error trying to compile GCC 4.7.0 on Linux:

On a RedHat 8 system we have installed the distribution defaults:
 - binutils 2.13.90.0.18
 - gcc 3.2

Trying to compile GCC 4.7.0 will eventually result in an error:

genrecog.s: Assembler messages:
genrecog.s:17481: Error: bignum invalid
genrecog.s:17491: Error: bignum invalid
genrecog.s:17497: Error: bignum invalid

Configuration was done with the default target: i686-pc-linux-gnu

The assembler code generated from genrecog.c looks like this:
17481         .sleb128 -9223372036854775808

This is actually a valid big number but there is a bug in the
assembler that produces this error.
I also got the same error trying to compile with GCC-3.4.6

Look at: /usr/bin/as --version
I downloaded and built a more recent version binutils. binutils-2.16.1
is the first version that works. bintutils-2.15 still has the bug.

GNU binutils as prerequisites point to host/target specific. Perhaps
will be useful to mention binutils>=2.16 at:
http://gcc.gnu.org/install/specific.html#x-x-linux-gnu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ray Holme | 1 May 2012 15:25
Picon
Favicon

Re: trying to build a DLL on Windows 7 gcc using 3rd party libraries


>> NO, using dll's does not work - see below. Using lib files comes closest but the two routines that I am
seeking to link to are not being found (I know they are there, one in each .lib).
>> ,,,

>isc_decode_date seems to be using stdcall.

  tried both stdcall and cdecl - both fail.

>I wonder if ib_util_malloc is really ib_util_malloc or mangled _ib_util_malloc

  that is possible and I could try that

>Have you looked at the exports of those libraries?
>You could use pexports or dumpbin by Microsoft.

  thanks, I will try those a little later today

>Are those libraries available somewhere so that we can test with them?

The libraries and include files defining the failing routines are part of the FREE Firebird 2.5 distribution.

I have built a minimal version of my code which calls the two routines needed in the libraries, included a
builddll.bat file which is how I TRY to build this; included the two firebird include files AND the two
firebird libaries they point at. They are all attached for your viewing.

I will continue trying the two microsoft programs you suggested (if I have them, or try to download).

If you have these tools and can easily see some trivial changes to the "EXPORT" pre-compiler macro that I
use, I would be eternally grateful.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Olsson | 1 May 2012 17:13
Picon

Concrete difference between -g and -ggdb

gcc docs say that -g gives "system's native format" and -ggdb gives 
dbg info "for use by GDB":
http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

...what does this mean in more concrete terms? What command or 
functionality in gdb, that I normally cannot use, am I able to use 
after building with -ggdb ?

		Martin
Permalink | Reply | 1 comment |
headers
Ian Lance Taylor | 1 May 2012 19:07
Picon
Favicon
Gravatar

Re: Concrete difference between -g and -ggdb

Martin Olsson <mnemo <at> minimum.se> writes:

> gcc docs say that -g gives "system's native format" and -ggdb gives
> dbg info "for use by GDB":
> http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
>
> ...what does this mean in more concrete terms? What command or
> functionality in gdb, that I normally cannot use, am I able to use
> after building with -ggdb ?

Unfortunately the docs in this area should be updated.  Currently the
default for most systems is DWARF, and when using DWARF -ggdb doesn't
make any difference.  At least not as far as I can tell.

The -ggdb option makes a difference when using STABS debug info.  There
it makes a range of improvements, should as recording const/volatile
qualifiers, the directory where a source file is found rather than just
the file name, supporting non-standard integer type sizes, supporting
boolean types, etc.

Also it's worth noting that -g defaults to -ggdb anyhow on most systems,
including all GNU/Linux systems.

Ian
Permalink | Reply | 0 comments |
headers
F. Heitkamp | 2 May 2012 13:02
Picon

Re: g++ libstdc++ linker question.

On 04/30/12 13:28, Jonathan Wakely wrote:
> On 30 April 2012 13:39, F. Heitkamp wrote:
>> People will tell me to ask on matplotlib list but I believe this a more
>> generic GNU C++ question.
>> I have been trying to run matplotlib that I built from source on my linux
>> from scratch like box.
>>
>> When I try to run an example I get:
>>
>> bash-4.2$ python2.6 matplotlib-ex1.py
>> Traceback (most recent call last):
>>   File "matplotlib-ex1.py", line 13, in<module>
>>     import matplotlib.pyplot as plt
>>   File "/usr/lib/python2.6/site-packages/matplotlib/pyplot.py", line 23, in
>> <module>
>>     from matplotlib.figure import Figure, figaspect
>>   File "/usr/lib/python2.6/site-packages/matplotlib/figure.py", line 16, in
>> <module>
>>     import artist
>>   File "/usr/lib/python2.6/site-packages/matplotlib/artist.py", line 6, in
>> <module>
>>     from transforms import Bbox, IdentityTransform, TransformedBbox,
>> TransformedPath
>>   File "/usr/lib/python2.6/site-packages/matplotlib/transforms.py", line 34,
>> in<module>
>>     from matplotlib._path import affine_transform
>> ImportError: /usr/lib/python2.6/site-packages/matplotlib/_path.so: undefined
>> symbol:
>> _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
F. Heitkamp | 2 May 2012 13:14
Picon

Re: g++ libstdc++ linker question.

On 04/30/12 13:47, Jonathan Wakely wrote:
> On 30 April 2012 18:28, Jonathan Wakely<jwakely.gcc <at> gmail.com>  wrote:
>> On 30 April 2012 13:39, F. Heitkamp wrote:
>>
> The matplotlib I use is built with:
>
> python setupegg.py build_ext \
>    --rpath=/opt/gcc-4.4.3/lib64
> python setupegg.py build
> python setupegg.py install --user
>
> The --rpath option ensures the right libstdc++.so is found at runtime
> (we have several installed).  That build works here, and is linked to
> libstdc++.so.  Unfortunately it builds matplotlib as a python egg,
> which is a very annoying package format.  I'd rather not install it
> via egg, but have no experience doing so and can't suggest why your
> build was not linked to libstdc++.
>

This last suggestion did not work for me.  I got the same undefined 
symbol error.  My linux setup is a 64 bits kernel running on sort of a 
hybrid 32/64 bits system.  By that I mean I have some 64 bits userland 
along with the 32bits.  When I configure python programs using the usual 
commands it comes back with arch x86_64.  Anyway I guess this is getting 
off topic for this list now, but suggestions are welcome nonetheless.

Fred
Permalink | Reply | 1 comment |
headers
Andrew Haley | 2 May 2012 13:36
Picon
Favicon

Re: g++ libstdc++ linker question.

On 05/02/2012 12:14 PM, F. Heitkamp wrote:
> On 04/30/12 13:47, Jonathan Wakely wrote:
>> On 30 April 2012 18:28, Jonathan Wakely<jwakely.gcc <at> gmail.com>  wrote:
>>> On 30 April 2012 13:39, F. Heitkamp wrote:
>>>
>> The matplotlib I use is built with:
>>
>> python setupegg.py build_ext \
>>    --rpath=/opt/gcc-4.4.3/lib64
>> python setupegg.py build
>> python setupegg.py install --user
>>
>> The --rpath option ensures the right libstdc++.so is found at runtime
>> (we have several installed).  That build works here, and is linked to
>> libstdc++.so.  Unfortunately it builds matplotlib as a python egg,
>> which is a very annoying package format.  I'd rather not install it
>> via egg, but have no experience doing so and can't suggest why your
>> build was not linked to libstdc++.
> 
> This last suggestion did not work for me.  I got the same undefined 
> symbol error.  My linux setup is a 64 bits kernel running on sort of a 
> hybrid 32/64 bits system.  By that I mean I have some 64 bits userland 
> along with the 32bits.  When I configure python programs using the usual 
> commands it comes back with arch x86_64.  Anyway I guess this is getting 
> off topic for this list now, but suggestions are welcome nonetheless.

We really need you to answer this question:

> Is _path.so a 32-bit or 64-bit library?  From the missing symbol I'm
> assuming 32-bit.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gunther Piez | 2 May 2012 15:44

Avoid generating vzeroupper instruction

Hello,

is there a way to tell gcc to not emit the `vzeroupper` instruction
while using -march=corei7avx? I do realize that this instruction is
neccessary if legacy 128 bit SSE instructions are intermixed with AVX
128/256 bit code, like calling a libc function which makes use of SSE in
a non-AVX glibc or the other way around.

But in a pure AVX code environment I noticed it actually does hurt
performance. So how can I tell gcc to not emit vzeroupper while
generating AVX instructions?

- Gunther
Permalink | Reply | 1 comment |
headers
cramer | 2 May 2012 16:27
Picon
Favicon

Spital nou de pediatrie


http://www.youtube.com/watch?feature=player_embedded&v=phjGxHn3uKU
 To unsubscribe please send email to unsubscribe <at> cc.psd-prahova.ro
Permalink | Reply | 0 comments |

Gmane