gmane.comp.gcc.help

Re: Trouble building AR

Ian Lance Taylor — 2013-06-18T23:16:52


Tell us exactly how you ran configure.

It's not clear from the above: did you build the binutils also, or did
you only build GCC?

Ian

Re: if-conversion passes

Ian Lance Taylor — 2013-06-18T20:24:57

On Tue, Jun 18, 2013 at 11:40 AM, Abdul Wahid Memon
<engrwahidmemon< at >gmail.com> wrote:

If you use -fno-if-conversion then the ce1 pass won't do anything, but
it will still be executed.  See rest_of_handle_if_conversion in
ifcvt.c.

Ian

Trouble building AR

Uri Moszkowicz — 2013-06-18T20:07:49

Hi,
I'm having trouble building GCC. I've decompressed GCC 4.7.2 source
into a directory and binutils 2.21.1 into a directory in parallel with
symbolic links to all subdirectories. I ran the contrib script to get
all other dependencies and then ran GCC's configure in a parallel
directory, following all installation instructions. It builds just
fine but when I install it AR seems to be missing. Any idea what
happened to it and how to get it?

Looks like it's supposed to be built with binutils and I'm getting
other tools from it like LD just not that one. There is a program
called gcc-ar that seems to exist but not sure if it's the same tool?
It may appear if I build binutils by itself but I'm trying to build
them together so that I can get -flto optimization to work, as
apparently GCC balks at using the linker plugin if they weren't built
together.

Thanks!

Re: Authoritative answer wanted: "-g -O1" vs. "-O1"

Andrew Haley — 2013-06-18T18:55:29

Oh yes.  This goes back to early GCC days, where it was one of the ways
in which GCC was superior to proprietary C compilers.  It is of *huge*
importance that if you have a bug and you turn on debugging the code
does not change, because that might make your bug change.

Andrew.

Re: Authoritative answer wanted: "-g -O1" vs. "-O1"

David Brown — 2013-06-18T18:48:22

Thanks for that information.  I think it is a useful feature that
enabling debugging does not affect the generated code, but I didn't
realise gcc was strict about it.

David

Re: if-conversion passes

Abdul Wahid Memon — 2013-06-18T18:40:57

I searched in gcc source and found that there are three passes related
to if-conversion optimization in ifcvt.c i.e. ce1, ce2, and ce3.

My question is that if I compile any program with if-conversion
disabled then why ce1 is being executed?

$ -O3 -fno-if-conversion *.c

Regards

Abdul++

On Tue, Jun 18, 2013 at 5:30 PM, Abdul Wahid Memon
<engrwahidmemon< at >gmail.com> wrote:

Re: -Wold-style-casts and system headers

Anthony Foiani — 2013-06-18T17:02:19


Or just resurrect this one:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12258

Exactly this issue, from 2004.

(Although the last comment was from 2010, looks out of place?)

Anyway.  Let me know if you think I should use that PR or start a new
one.

Thanks!

Best regards,
Anthony Foiani

Re: -Wold-style-casts and system headers

Anthony Foiani — 2013-06-18T16:57:05

Jonathan --

Thanks for the quick reply.

Jonathan Wakely <jwakely.gcc< at >gmail.com> writes:


If that's the expected behavior, then the manual probably needs
rephrasing:

  "Macros defined in a system header are immune to a few warnings
  wherever they are expanded."

I certainly expected "wherever" to include user code, and it seems
that's an important place for it to apply.  An even shorter example:

  #include <sys/select.h>

  int main()
  {
      fd_set fds;
      FD_CLR( 0, &fds );
      return 0;
  }

Generates:

  $ g++ -Wold-style-cast -o g++-cast-warning g++-cast-warning.cpp
  g++-cast-warning.cpp: In function ‘int main()’:
  g++-cast-warning.cpp:47:5: warning: use of old-style cast [-Wold-style-cast]
  g++-cast-warning.cpp:47:5: warning: use of old-style cast [-Wold-style-cast]
  g++-cast-warning.cpp:47:5: warning: use of old-style cast [-Wold-style-cast]


From a quick read, it seems that the infrastructure to fix this
problem is in 4.8, but this particular problem isn't fixed?

Should I file

Re: trouble using glob and wordexp

ballsystemlord — 2013-06-18T16:47:33

Thanks!



--
View this message in context: http://gcc.1065356.n5.nabble.com/trouble-using-glob-and-wordexp-tp945091p947173.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: -Wold-style-casts and system headers

Jonathan Wakely — 2013-06-18T16:42:15

It's because the expansion of the macro is in your code, not in a system header.

There are some open bug reports on similar subjects
e.g.http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263#c8

Re: Authoritative answer wanted: "-g -O1" vs. "-O1"

Ian Lance Taylor — 2013-06-18T16:32:24

That turns out not to be the case.  It always been a strict rule with
GCC that -g does not affect code generation.

What the OP is describing is a serious bug.

Ian

Re: -femit-struct-debug-reduced/baseonly debug info

Ian Lance Taylor — 2013-06-18T16:23:01

On Tue, Jun 18, 2013 at 7:53 AM, Evgeny Gavrin
<evgeny.gavrin< at >hotmail.com> wrote:

No.  This only affect the debug info for "struct-like types", meaning,
in C++, classes and structs.  It doesn't affect inlining.  You're
right that it will keep info about static types.  And if you are
compiling foo.cc, it will keep info about class foo.


This is documented with the -femit-struct-debug-detailed option.

Ian

-Wold-style-casts and system headers

Anthony Foiani — 2013-06-18T16:14:48

Greetings.

I'm using -Wold-style-casts on my project, and I've found that I get
warnings in my code when certain macros are expanded.

These macros are defined in headers under /usr/include; my reading of
the manual is that these ought to get some immunity from some
warnings:

  "Macros defined in a system header are immune to a few warnings
  wherever they are expanded. This immunity is granted on an ad-hoc
  basis, when we find that a warning generates lots of false positives
  because of code in macros defined in system headers."
  -- http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html

But it seems there is some degree of judgment ("ad-hoc basis")
involved -- it's not clear whether that's regarding the header files,
individual macros, or individual warnings.

The case I hit today was from zlib.h, which has the following macro
definition:

  #define deflateInit(strm, level) \
          deflateInit_((strm), (level), ZLIB_VERSION, (int)sizeof(z_stream))

When expanded into my sample code:

  // https://

if-conversion passes

Abdul Wahid Memon — 2013-06-18T15:30:46

Hello all

Can someone please specify the pass related to if-conversion optimization?

Best regards

Abdul

RE: -femit-struct-debug-reduced/baseonly debug info

Evgeny Gavrin — 2013-06-18T14:53:11

Quote from the documentations is not clear to me: "Emit debug information for struct-like types only when the base name of the compilation source file matches the base name of file in which the type was defined, unless the struct is a template or defined in a system header. "

As I understood, this'll store info only about static types and I'll loose info about inlining, for example, am I right?

And to extend the question:
I don't understand what means direct or indirect accessed structs? Ordinary or generic ones? Where I can read about it?

/*
With optimism,
Evgeny Gavrin

email : evgeny.gavrin< at >hotmail.com
*/


----------------------------------------

Re: Authoritative answer wanted: "-g -O1" vs. "-O1"

David Brown — 2013-06-18T14:35:50

I did not think that was the case.  As I understood it, "-g" /may/ cause
to the code to improve debugging.  I can't say that I have ever noticed
any code changes, but I've always assumed it is possible especially with
more advanced optimisations.

I certainly don't see anything in the documentation that suggests "-g"
cannot change the code - only that "-g -O" will generate optimised and
debugable code (though possibly with confusing debugging).

Function Parameters vs. Prologue (fastcall + O1 + -fschedule-insns2)

Geyslan Gregório Bem — 2013-06-18T14:24:52

Hi,

I'm curious about what is causing this reordering (prologue with the
function parameters):

# gcc structs.c -o structs -m32 -O1 -fschedule-insns2

(gdb) disas main
Dump of assembler code for function main:
   0x0804868c <+0>: push   %ebp
   0x0804868d <+1>: mov    $0x3,%edx
   0x08048692 <+6>: mov    %esp,%ebp
   0x08048694 <+8>: mov    $0x2,%ecx
   0x08048699 <+13>: and    $0xfffffff0,%esp
   0x0804869c <+16>: call   0x804845c <funcao>


The code:

__attribute__((fastcall)) void funcao(int i, int a) {
...
int main() {

        int i, a;
        i = 2;
        i = 3;

        funcao(i, a);
...


When I remove one of them (fastcall or schedule-insns2), the binary is
generated in logic order:

(gdb) disas main
Dump of assembler code for function main:
   0x08048340 <+0>: push   %ebp
   0x08048341 <+1>: mov    %esp,%ebp
   0x08048343 <+3>: and    $0xfffffff0,%esp
   0x08048346 <+6>: sub    $0x10,%esp
   0x08048349 <+9>: movl   $0x3,0x4(%esp)
   0x08048351 <+17>: movl   $0x2,(%esp)
   0x08048358 <+24>: call

Re: Authoritative answer wanted: "-g -O1" vs. "-O1"

gds — 2013-06-18T14:02:06

Yes, just removing the -g does affect the assembly as seen using -S gcc 
flag. However, it appears to be the same difference I see with objdump 
on the full elf. Here is a small example of the difference when calling 
the same c++ function looking at the -S assembly file output. The 
directives differ as expected but there are definitely some added or 
different assembly lines between the two. These type of small 
differences are throughout all project assembly output files.

w/o -g:

_ZN20MyFunc29guppieSortBoxNumbersEv:
< at > args = 0, pretend = 0, frame = 168
< at > frame_needed = 0, uses_anonymous_args = 0
push{r4, r5, r6, r7, r8, r9, sl, fp, lr}
subsp, sp, #196
strr0, [sp, #24]
ldrhr2, [r0, #6]
ldrr3, .L85
umullr1, r3, r3, r2
lsrr3, r3, #2
strr3, [sp, #28]
cmpr3, #9
bhi.L76
movr3, #0
movr2, r3
:
:

w/ -g:

_ZN20MyFunc29guppieSortBoxNumbersEv:
.LFB42:
.loc 1 1062 0
.cfi_startproc
< at > args = 0, pretend = 0, frame = 176
< at > frame_needed = 0, uses_anonymous_args = 0
.LVL63:
push{r4, r5, r

Re: -femit-struct-debug-reduced/baseonly debug info

Ian Lance Taylor — 2013-06-18T13:43:18

On Tue, Jun 18, 2013 at 4:40 AM, Evgeny Gavrin
<evgeny.gavrin< at >hotmail.com> wrote:

The GCC manual explains how those options work.  I could repeat that
documentation but that seems unhelpful.  Perhaps it would help if you
could explain what you don't understand about the documentation.

Ian

Re: static library unresolved symbols

Ian Lance Taylor — 2013-06-18T13:40:17

On Tue, Jun 18, 2013 at 3:40 AM, Riccardo Manfrin
<riccardomanfrin< at >gmail.com> wrote:

As far as I know there is no way to do that directly.

You can do it indirectly by doing

ld -r -o foo.o --whole-archive foo.a
nm -u foo.o

Ian

-femit-struct-debug-reduced/baseonly debug info

Evgeny Gavrin — 2013-06-18T11:40:00

Hi!

I'm trying to reduce the amount of debug info in my binaries.

What kind of debug info will I loose in case of using -femit-struct-debug-reduced or -femit-struct-debug-baseonly?
And what is still available?

/*
With optimism,
Evgeny Gavrin

email : evgeny.gavrin< at >hotmail.com
*/