[Bug driver/66657] Feature request - assembly output from lto compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66657 --- Comment #3 from Kenneth Almquist kalmquist1 at hotmail dot com --- (In reply to Andrew Pinski from comment #2) What are you trying to do with the assembly after the fact? In this particular case, I wanted to look at it for two reasons: 1) To determine which functions were being inlined. 2) To identify errant calls to printf and puts. When compiled to run in background mode, my program should send all messages to the log rather than stdout/stderr, so calls to printf/puts that the compiler doesn't discard as unreachable represent program bugs. Gcc has had the -S option for essentially forever, and I've probably used it more times and for more reasons than I can remember at this point.
[Bug driver/66657] New: Feature request - assembly output from lto compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66657 Bug ID: 66657 Summary: Feature request - assembly output from lto compiler Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: kalmquist1 at hotmail dot com Target Milestone: --- There should be a gcc command line option to generate the assembly language output of the lto compiler. The -S option doesn't do this because it prevents the lto compilation phase from running at all. Currently, the only way to accomplish this is to run the lto compiler directly, as in the following example: ld -r -plugin /usr/lib/gcc/x86_64-linux-gnu/4.8/liblto_plugin.so \ -plugin-opt=/bin/true -plugin-opt=-fresolution=out.res in1.o in2.o /usr/lib/gcc/x86_64-linux-gnu/4.8/lto1 -quiet \ -fresolution=out.res -o out.s -O2 in1.o in2.o This is ugly and undocumented.
[Bug c++/4131] The C++ compiler doesn't place a const class object to .rodata section with non trivial constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131 --- Comment #29 from Kenneth Almquist kalmquist1 at hotmail dot com --- (In reply to Jorg Brown from comment #20) Now, the order of construction is well-defined, and that is why the program produces: podStr = '*' nonpodStr = '' That is, the nonPOD is still zero-filled when the constructor for nonpodStr runs, so nonpodStr ends up empty. Actually, looking at paragraph 2 of section 3.6.2 of the 1997 draft standard, it appears that the order of construction is not entirely well defined. Consider: extern int x, y, z; int z = y + 1; int y = x + 1; int x = 10; As I understand it, x must use static initialization for x, but has the option of using either static or dynamic initialization for y and z. Normally, variables are initialized in program order, so that z would be initialized before y. However, if the compiler choses dynamic initialization for z and static initialization for y, then z will be initialized after y. Similarly, in your example, nonpodStr could be either '' or '*'. There is one special rule in evaluating the initial value of variables when static initialization is used: If the expression contains a variable and the compiler is allowed to use dynamic initialiation for that variable and that variable is initialized later in the program then zero is used as the value of the variable. In the above example, if static initialization is used for z, the initial value will be 1, because zero will be used as the value of y when computing y + 1. On the other hand, if static initialization is used for y, the initial value of y will be 11, because the compiler is require to use static initialization for x and the rule given above doesn't apply. In short, computing the values of initializers at compile time for C++ involves a special rule which, as far as I know, doesn't apply to any other language. For that reason, it might make sense to do this calculation in the C++ front end. I think that the front end already does a bit of this, but only for expressions that are formally constant expressions.
[Bug c++/66355] defining a constructor inhibits optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66355 kalmquist1 at hotmail dot com kalmquist1 at hotmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from kalmquist1 at hotmail dot com kalmquist1 at hotmail dot com --- Thanks to the pointer provided by Marc Glisse, I found that this issue was reported back in 2001, in PR 4131. *** This bug has been marked as a duplicate of bug 4131 ***
[Bug c++/4131] The C++ compiler doesn't place a const class object to .rodata section with non trivial constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131 kalmquist1 at hotmail dot com kalmquist1 at hotmail dot com changed: What|Removed |Added CC||kalmquist1 at hotmail dot com --- Comment #28 from kalmquist1 at hotmail dot com kalmquist1 at hotmail dot com --- *** Bug 66355 has been marked as a duplicate of this bug. ***
[Bug c++/66355] New: defining a constructor inhibits optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66355 Bug ID: 66355 Summary: defining a constructor inhibits optimization Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kalmquist1 at hotmail dot com Target Milestone: --- Created attachment 35659 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35659action=edit Archive contains wrap-int-[012].cxx and makefile Ideally, replacing the type int with a wrapper class that contains a single int value as a member should not impose any performance penalty. Unfortunately, that is not the case if the wrapper class has a non-default constructor, which it almost certainly will. The attached archive contains three programs, which can be compiled to assembly language using the included makefile. wrap-int-0.cxx contains a very simple integer computation. wrap-int-1.cxx does the same thing, but the int type has been replaced by a wrapper class. The generated assembly instructions are same, so there is no performance penalty for using the wrapper class. wrap-int-2.cxx is the same as wrap-int-1.cxx except that a constructor has been added to the wrapper class. One would expect a good optimizer to generate the same code for this program as for the other two programs, but in fact the generated code is a good deal larger. I'm guessing that what is happening is that if a type has a non-default constructor, the C++ front end treats constants of that type as variables rather than as contstants, so that even simple optimizations like constant folding are no longer performed by that back end.
