[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 --- Comment #4 from Ivan Godard igodard at pacbell dot net 2012-04-22 06:08:28 UTC --- Looking a little further at this, I don't think we can use init_array at all, even if it ran in reverse order. Consider TUs in a .a library, where some of the TUs have an order dependency with other TUs in the same library. If I understand the way init_array works (doubtful), the init_array will be populated with TUs in command line order; the assumption is that libraries at the end of the list are more primitive, and so will need to be initialized first. Or maybe the order is reversed; either way, it is determined by the command line. However, if several TUs are picked up from a single library then they will be ordered w/r/t files from a different library, but will be in random order w/r/t files from the same library. This breaks the asserted intra-library dependency. As far as I can tell from the discussion there is no way to control the init_array populating process other than priority, which as previously mentioned is unusable in a large environment with third-party binaries. Hence we need some way to force gcc to continue to use ctors instead of init_array. I find no documented option to do that - have I overlooked it, or does it not exist? Or have I misunderstood init_array (all to likely)?
[Bug c/53069] New: expected warnings are not given
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53069 Bug #: 53069 Summary: expected warnings are not given Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: santoshg...@gmail.com hi, I am a windows user. Currently, i am using MinGW tools for c language. I found following two conditions very suspicious about gcc compiler. I am using cmd.exe (i.e. command prompt of windows) to compile my program. 1.Suppose we declared as int main(void), then we must return a value at end to operating system. But evenif we didn't do that, gcc doesn't give a warning like 'Function should return a value'. 2.Consider this if statement: if(flag = 0). Error is that instead of '=', there should be '=='.But the compiler doesn't give a single warning. The behaviour of executable file is not as per our logic(rather destructable). Reply me about these two situations as soon as possible. If these two are corrected in later versions, please inform me how to update my gcc compiler. And please don't advise me to use any editor like Eclipse or CodeBlocks.
[Bug c/53069] expected warnings are not given
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53069 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-22 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-22 07:15:36 UTC --- Please read the FAQ. Try adding -Wall -Wextra as mentioned in the bug reporting page.
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-22 07:19:29 UTC --- Really you should not be dependent on the order since that has even been defined. Yes you would think it would be defined but it was never a guarantee.
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 --- Comment #6 from Ivan Godard igodard at pacbell dot net 2012-04-22 07:46:20 UTC --- Yes, but. Order is not defined, but order dependencies are inescapable in C++ which has a tendency to invoke constructors where you least expect them - when you #include a file for example. The naive sometimes advocate lazy init, doing dynamic initialization in each accessor; they have never had to deal with thread convoying behind the lock in the accessor. Others advocate having an init phase where explicit calls spread out from main() and allocate (and initialize) whatever each module needs; they have never dealt with objects that must be static because new() is unavailable for hardware reasons. I'm not asking for the behavior to be defined; you are right that the language does not demand that. But we mere users need to control the undefined behavior, and so we need hooks to use for that control. Apparently a usable set of hooks just gratuitously went away. That sucks.
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #7 from Pawel Sikora pluto at agmk dot net 2012-04-22 07:54:34 UTC --- (In reply to comment #3) Wow - this will break a lot of big users - we are far from the only ones who find priorities unusable. BTAIM, it appears that our choice is to use an option (there is one? what?) to force 4.7 to continue to use ctors, or to use some other option (there is one? what?) to force 4.7 to process init_array in reverse order from what it does by default. Of these two, which do you recommend as a workaround? Are there any other choices? you can use gold linker. it have nice options: $ ld.gold --help|grep ctors --ctors-in-init-array Use DT_INIT_ARRAY for all constructors (default) --no-ctors-in-init-arrayHandle constructors as directed by compiler
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Ivan Godard igodard at pacbell dot net changed: What|Removed |Added CC||igodard at pacbell dot net --- Comment #96 from Ivan Godard igodard at pacbell dot net 2012-04-22 08:01:55 UTC --- I'm a user that the switch to init_array just broke. Details are in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068, but to summarize: Large production environment Must use other compilers too Third party binaries as well as our code. Each project represented as a .a library. Static initialization dependencies between TUs in a project (and hence within .o's in a library). Static initialization dependencies among projects. Executables link some explicit .o's with libraries from other projects, and must provide semantically correct ordering. Hence: Can't use priorities (not supported on other compilers; can't add pragmas to 3rd party code; maintaining a global absolute order over hundreds of files that change dependencies each release is a headache) Can't use init_array (no way to control ordering among files extracted from a single library) So for a decade we have manually maintained a dependency graph (relative, not absolute like priorities) and used that to put explicit commands to position .ctor sections into a linker script. That broke in 4.7. Yes, the language leaves inter-TU order unspecified. But we the users have to control that particular unspecified to get our job done. There used to be a way to exercise that control, through hooks in the linker script. You have now gratuitously taken away that control *and left nothing else to use instead*. At this point our choices appear to be to stay at 4.6 forever (or at least until the roar of complaint makes you do something), or to do our own collect2. Pretty poor.
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.7.1 |4.8.0 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22 08:04:33 UTC --- Fixed.
[Bug libstdc++/52702] [C++11] std::is_trivially_destructible is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52702 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22 08:05:18 UTC --- Done.
[Bug c++/53067] c++0x GCC 4.7.0 Regression std::ref with unordered sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22 08:08:05 UTC --- Already fixed for 4.7.1. *** This bug has been marked as a duplicate of bug 52942 ***
[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52942 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22 08:08:05 UTC --- *** Bug 53067 has been marked as a duplicate of this bug. ***
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 --- Comment #6 from Evgeny Ratnikov ratnikov.ev at ya dot ru 2012-04-22 08:47:07 UTC --- (In reply to comment #2) Why do you think this is a bug? The C++ 2011 standard requires that std::list::size() is O(1) so a new member variable is needed to store the container's size. To be clear. It is not a real problem that the size of std::list was changed. The real problem is that after such change my application (-std=98) linked with libraries (-std=0x) causes corrupted stack. May be I was too precise naming a bug. It would be nice to hear your opinion about my situation.
[Bug tree-optimization/53070] New: ICE: in execute_cse_reciprocals, at tree-ssa-math-opts.c:513 with -O -ffast-math -ftree-loop-if-convert -fno-tree-loop-im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53070 Bug #: 53070 Summary: ICE: in execute_cse_reciprocals, at tree-ssa-math-opts.c:513 with -O -ffast-math -ftree-loop-if-convert -fno-tree-loop-im Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 27215 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27215 reduced testcase Compiler output: $ gcc -O -ffast-math -ftree-loop-if-convert -fno-tree-loop-im testcase.c testcase.c: In function 'foo': testcase.c:2:1: internal compiler error: in execute_cse_reciprocals, at tree-ssa-math-opts.c:513 foo (int c) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x12f1450 /mnt/svn/gcc-trunk/gcc/tree-ssa-math-opts.c, line=513, function=0x12f1710 execute_cse_reciprocals) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:1006 #1 0x00b07d3e in execute_cse_reciprocals () at /mnt/svn/gcc-trunk/gcc/tree-ssa-math-opts.c:513 #2 0x00913627 in execute_one_pass (pass=0x180ba60) at /mnt/svn/gcc-trunk/gcc/passes.c:2176 #3 0x009139e5 in execute_pass_list (pass=0x180ba60) at /mnt/svn/gcc-trunk/gcc/passes.c:2231 #4 0x009139f7 in execute_pass_list (pass=0x1808e40) at /mnt/svn/gcc-trunk/gcc/passes.c:2232 #5 0x006c00be in tree_rest_of_compilation (node=Unhandled dwarf expression opcode 0xfa ) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1860 #6 0x006c3302 in cgraph_expand_function (node=0x75a85780) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1930 #7 0x006c5529 in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1995 #8 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2685 #9 0x006c5b1a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2769 #10 0x0059f770 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:10053 #11 0x009fef4c in compile_file () at /mnt/svn/gcc-trunk/gcc/toplev.c:572 #12 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1938 #13 toplev_main (argc=16, argv=0x7fffd708) at /mnt/svn/gcc-trunk/gcc/toplev.c:2014 #14 0x761ba2ad in __libc_start_main () from /lib64/libc.so.6 #15 0x00582d01 in _start () Tested revisions: r186657 - crash
[Bug c/53071] New: Wrong instruction replacement when compiling for xop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53071 Bug #: 53071 Summary: Wrong instruction replacement when compiling for xop Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ag...@agner.org Created attachment 27216 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27216 source code and asm output An intrinsic vector multiply function is replaced by xop instructions when the attached file is compiled with -mxop. Perhaps the compiler is trying to combine a shift instruction and a multiply instruction into a single xop instruction, but it ends up with something wrong. This is perhaps related to bugs # 52908 and 52910.
[Bug target/53071] Wrong instruction replacement when compiling for xop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53071 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target Severity|critical|normal
[Bug c++/51033] generic vector subscript and shuffle support was not added to C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 --- Comment #19 from Marc Glisse marc.glisse at normalesup dot org 2012-04-22 10:31:33 UTC --- Created attachment 27217 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27217 shuffle With this patch, g++ passes the few __builtin_shuffle tests I tried, and generates generic code for non-constant indexes and special code for constant indexes. I don't really know what to do about the testsuite. The tests exercise the backend a lot, and it probably doesn't make sense to run everything with both gcc and g++. But we still want to test that g++ accepts the syntax, and maybe even that it handles constants well. Content of the patch: - move c_build_vec_perm_expr to c-common and condition the maybe_const stuff to the dialect - adapt the C RID_BUILTIN_SHUFFLE parser code to the C++ FE (the 2 are different enough that it isn't easy to share) - remove the C_ONLY tag from __builtin_shuffle As usual, my limited knowledge of the compiler means I may have missed fundamental things.
[Bug tree-optimization/46886] [4.5/4.6 Regression] wrong code with -ftree-parallelize-loops -fno-tree-ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886 --- Comment #14 from razya at gcc dot gnu.org 2012-04-22 10:36:18 UTC --- Author: razya Date: Sun Apr 22 10:36:13 2012 New Revision: 186667 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186667 Log: 2012-04-20 Razya Ladelsky ra...@il.ibm.com Correcting transform_to_exit_first_loop + fix to PR tree-optimization/46886 * tree-parloops.c (transform_to_exit_first_loop): * Remove setting of number of iterations according to * the loop pattern. Duplicate from entry to exit-src instead of loop-latch. (pallelize_loops): Remove the condition preventing do-while loops. * tree-cfg.c (bool bb_in_region_p): New. (gimple_duplicate_sese_tail): Adjust duplication of the the subloops. Adjust redirection of the duplicated iteration. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-parloops.c
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-22 11:38:36 UTC --- (In reply to comment #6) problem is that after such change my application (-std=98) linked with libraries (-std=0x) causes corrupted stack. You can't do that. It won't work.
[Bug middle-end/28685] Multiple comparisons are not simplified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #20 from Uros Bizjak ubizjak at gmail dot com 2012-04-22 12:42:07
UTC ---
(In reply to comment #19)
int test (int a, int b)
{
int lt = a + b 0;
int eq = a + b == 0;
if (lt)
return 1;
return eq;
}
Actually, here ce1 pass steps on cse2 pass. ce1 pass flattens jump-over with a
conditional set. cse2 pass doesn't CSE jumpless blocks (see
cse_condition_code_reg), claiming that:
/* Look for blocks which end with a conditional jump based on a
condition code register. Then look for the instruction which
sets the condition code register. Then look through the
successor blocks for instructions which set the condition
code register to the same value. There are other possible
uses of the condition code register, but these are by far the
most common and the ones which we are most likely to be able
to optimize. */
Changing the source to:
int test (int a, int b)
{
int lt = a + b 0;
int eq = a + b == 0;
if (lt)
return 15;
return eq;
}
yields one compare (the one in add insn):
test:
addl%esi, %edi
movl$15, %eax
js .L2
sete%al
movzbl %al, %eax
.L2:
rep
ret
[Bug middle-end/28685] Multiple comparisons are not simplified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685 --- Comment #21 from Uros Bizjak ubizjak at gmail dot com 2012-04-22 12:45:17 UTC --- (In reply to comment #17) The only one which is not fixed is comment #4 This testcase is fixed with patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00295.html
[Bug middle-end/28685] Multiple comparisons are not simplified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #22 from Uros Bizjak ubizjak at gmail dot com 2012-04-22 12:48:21 UTC --- (In reply to comment #18) Following patch that enables post-reload compare elimination: ... This shows that the pass is effective for x86_64, but will be enabled for 4.8. Not worth for x86. All interesting cases were fixed by other patches. So, fixed.
[Bug c/53058] Another ice in remove_range_assertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53058 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-04-22 13:01:24 UTC --- Started with rev.184927.
[Bug c++/51033] generic vector subscript and shuffle support was not added to C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #20 from Marc Glisse marc.glisse at normalesup dot org 2012-04-22
13:21:14 UTC ---
(In reply to comment #19)
Created attachment 27217 [details]
shuffle
Doesn't work with -std=c++11, which requires:
--- semantics.c(revision 186667)
+++ semantics.c(working copy)
@@ -5603,11 +5603,12 @@ float_const_decimal64_p (void)
bool
literal_type_p (tree t)
{
if (SCALAR_TYPE_P (t)
- || TREE_CODE (t) == REFERENCE_TYPE)
+ || TREE_CODE (t) == REFERENCE_TYPE
+ || TREE_CODE (t) == VECTOR_TYPE)
return true;
if (CLASS_TYPE_P (t))
{
t = complete_type (t);
gcc_assert (COMPLETE_TYPE_P (t) || errorcount);
@@ -8487,10 +8488,11 @@ potential_constant_expression_1 (tree t,
want_rval, flags))
return false;
return true;
case FMA_EXPR:
+case VEC_PERM_EXPR:
for (i = 0; i 3; ++i)
if (!potential_constant_expression_1 (TREE_OPERAND (t, i),
true, flags))
return false;
return true;
And then I still need to write a cxx_eval_vec_perm function so the result of
__builtin_shuffle can be constexpr. I haven't seen how the C front-end handles
shuffles of constants. Maybe a sorry would do for now.
[Bug c++/53067] c++0x GCC 4.7.0 Regression std::ref with unordered sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2012-04-22
Resolution|DUPLICATE |
Ever Confirmed|0 |1
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-22
13:36:19 UTC ---
It's not a dup, although it doesn't help that the testcase is bogus (should use
unordered_set not unordered_map)
#include functional
#include unordered_set
int main(int, char**){
std::unordered_setint Foo;
ref(Foo);
}
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot ||com --- Comment #8 from Paul Pluzhnikov ppluzhnikov at google dot com 2012-04-22 14:09:23 UTC --- (In reply to comment #7) you can use gold linker. it have nice options: $ ld.gold --help|grep ctors --ctors-in-init-array Use DT_INIT_ARRAY for all constructors (default) --no-ctors-in-init-arrayHandle constructors as directed by compiler Just for the record: Until we are able to remove inter-CU order dependencies in our code, we are sticking with: # prevent GCC from generating init_array: gcc-4.7/configure --disable-initfini-array ... # make gold use .ctors (we configure gcc to use gold) gcc-4.7 main.o ... -Wl,--no-ctors-in-init-array I believe this fully restores the legacy (gcc-4.6) ordering.
[Bug libstdc++/53027] pointer_traits::rebind is private
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53027 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-22 14:14:21 UTC --- Author: redi Date: Sun Apr 22 14:14:15 2012 New Revision: 186671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186671 Log: PR libstdc++/53027 * include/bits/ptr_traits.h (pointer_traits::rebind): Make public. * testsuite/20_util/pointer_traits/requirements/typedefs.cc: Check rebind works. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/ptr_traits.h branches/gcc-4_7-branch/libstdc++-v3/testsuite/20_util/pointer_traits/requirements/typedefs.cc
[Bug libstdc++/53027] pointer_traits::rebind is private
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53027 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-22 14:16:36 UTC --- fixed for 4.7.1 and 4.8.0
[Bug target/52910] xop-mul-1:f13 miscompiled on bulldozer (-mxop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52910 Agner Fog agner at agner dot org changed: What|Removed |Added CC||agner at agner dot org --- Comment #1 from Agner Fog agner at agner dot org 2012-04-22 14:35:35 UTC --- Confirm: I have seen a similar bug (gcc 4.7.0)
[Bug c++/51033] generic vector subscript and shuffle support was not added to C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-22 14:56:28 UTC --- (In reply to comment #19) With this patch, g++ passes the few __builtin_shuffle tests I tried, and generates generic code for non-constant indexes and special code for constant indexes. I don't really know what to do about the testsuite. The tests exercise the backend a lot, and it probably doesn't make sense to run everything with both gcc and g++. But we still want to test that g++ accepts the syntax, and maybe even that it handles constants well. What does it mean exercise the backend a lot? Do you mean it takes a lot of time? I haven't looked at the tests, but I think it is not a problem to run compile-only tests with both gcc and g++. As usual, my limited knowledge of the compiler means I may have missed fundamental things. It looks pretty good to me.
[Bug c++/51033] generic vector subscript and shuffle support was not added to C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 --- Comment #22 from Marc Glisse marc.glisse at normalesup dot org 2012-04-22 15:09:23 UTC --- (In reply to comment #20) And then I still need to write a cxx_eval_vec_perm function so the result of __builtin_shuffle can be constexpr. I haven't seen how the C front-end handles shuffles of constants. Maybe a sorry would do for now. Making vectors literals is too much for now, the following seems sufficient as long as they are not. --- cp/semantics.c(revision 186667) +++ cp/semantics.c(working copy) @@ -8262,10 +8262,11 @@ potential_constant_expression_1 (tree t, case TRANSACTION_EXPR: case IF_STMT: case DO_STMT: case FOR_STMT: case WHILE_STMT: +case VEC_PERM_EXPR: if (flags tf_error) error (expression %qE is not a constant-expression, t); return false; case TYPEID_EXPR:
[Bug regression/52383] [4.6 Regression] miscompiles Perl on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2012-04-22 15:41:44 UTC --- Upgrading didn’t help, but in the meantime, I got it built. I blame ARAnyM, as it succeeds on a box I put Petr’s .deb on… so no wonder Andreas couldn’t reproduce it.
[Bug c++/53067] c++0x GCC 4.7.0 Regression std::ref with unordered sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22 16:10:38 UTC --- I'm right now rebuilding both mainline and branch, because yesterday both worked and I don't think we changed anything in this area. What the heck it is?
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #51 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-22 16:35:34 UTC --- BTW, if you have more examples where printing the caret seems unnecessary, please open PRs and add me to the CC. I will try to deal with them and hopefully the caret will stay enabled by default for GCC 4.8.
[Bug c/53072] New: automatically set Init() only if option was not set in some other way
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53072 Bug #: 53072 Summary: automatically set Init() only if option was not set in some other way Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org Currently, it is possible to specify an initial value in the .opt file with Init(). However, this value is set at the beginning, so it is (impossible?) to know whether the value is the default or was set explicitly in some other way. This is why many options are initialized to -1 instead. The infrastructure to detect whether options have been set explicitly seems to be there, but it is not clear how to use it to fix the above problem.
[Bug c++/53067] c++0x GCC 4.7.0 Regression std::ref with unordered sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22 16:57:19 UTC --- Ok, for 4_7-branch just stop this insanity and make all the implementation details public. In mainline - barring other changes - we'll be anyway able to do better thanks to access control part of SFINAE.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #97 from Ian Lance Taylor ian at airs dot com 2012-04-22 17:03:24 UTC --- One option you have is to configure gcc with --disable-initfini-array.
[Bug middle-end/53073] New: [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 Bug #: 53073 Summary: [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: areg.melikadam...@gmail.com, rgue...@gcc.gnu.org On Linux/x86-64, revision 186592: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00543.html compiles 464.h264ref in SPEC CPU 2006 into infinite loop.
[Bug libfortran/53051] I/O: Support reading floating-point numbers which use Q for the exponent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53051 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-22 17:28:39 UTC --- Author: burnus Date: Sun Apr 22 17:28:34 2012 New Revision: 186675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186675 Log: 2012-04-22 Tobias Burnus bur...@net-b.de PR fortran/53051 * io/list_read.c (parse_real): Support q for the exponential. * io/read.c (read_f): Ditto. 2012-04-22 Tobias Burnus bur...@net-b.de PR fortran/53051 * gfortran.dg/read_float_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/read_float_4.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c
[Bug libfortran/53051] I/O: Support reading floating-point numbers which use Q for the exponent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53051 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-22 17:30:02 UTC --- FIXED on the 4.8 trunk.
[Bug c++/53067] c++0x GCC 4.7.0 Regression std::ref with unordered sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-04-22 17:38:07 UTC --- Author: paolo Date: Sun Apr 22 17:37:57 2012 New Revision: 186676 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186676 Log: 2012-04-22 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/53067 * include/bits/hashtable_policy.h: Change inheritances to public. * testsuite/23_containers/unordered_map/requirements/53067.cc: New. * testsuite/23_containers/unordered_set/requirements/53067.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/53067.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/requirements/53067.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable_policy.h
[Bug c++/53067] c++0x GCC 4.7.0 Regression std::ref with unordered sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-04-22 17:38:18 UTC --- Author: paolo Date: Sun Apr 22 17:38:11 2012 New Revision: 186677 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186677 Log: 2012-04-22 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/53067 * include/bits/hashtable_policy.h: Change inheritances to public. * testsuite/23_containers/unordered_map/requirements/53067.cc: New. * testsuite/23_containers/unordered_set/requirements/53067.cc: Likewise. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/53067.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_set/requirements/53067.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/hashtable_policy.h
[Bug c++/53067] c++0x GCC 4.7.0 Regression std::ref with unordered sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.1 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22 17:40:06 UTC --- Fixed mainline and 4.7.1.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #98 from Ivan Godard igodard at pacbell dot net 2012-04-22 17:44:24 UTC --- It's OK if you reverse the default order - make it sideways if it gets a faster Firefox. We can cope. It's OK is you dump ctors for init_array if it simplifies your maintenance. We don't want you to be stuck with maintaining both systems. But give us some (documented!) way to control how the init_array gets populated, for when there's something you didn't think of in your planning. Like using command line order breaks when there are intra-library order dependencies. Please. OK to re-open this ticket?
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #99 from Jan Hubicka hubicka at ucw dot cz 2012-04-22 18:33:44 UTC --- OK to re-open this ticket? If ctor order was/is controllable via linker script, it seems that you need similar feature for init arrays. In that case it is binutils feature, not GCC, and for that please fill in http://sourceware.org/bugzilla/ I am sorry for the trouble. As Iant pointed out, disabling initarray support may be viable solution for you in meantime. Honza
[Bug middle-end/53074] New: insn-recog.c:recog calls predicates known to be false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53074 Bug #: 53074 Summary: insn-recog.c:recog calls predicates known to be false Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org Target: cris-axis-elf The following was observed for gcc-4_7-branch r185763 as well as for trunk r186667. The decision-tree in insn-recog.c, when generated from candidate patterns where one candidate (the first in file) pattern has a bare (label_ref ...) (without specified mode) and others (after the first in the file) has (match_operand:SI operand_known_to_not_match_label_ref ...) where operand_known_to_not_match_label_ref is for example, nonimmediate_operand or register_operand, inspects the mode of the operand of the insn being matched and calls the predicates despite it knowing they will fail. After the calls, it will correctly match the insn to the first pattern. This will not happen if the predicate is not known to fail or when no mode is specified for the second pattern (then there's the expected test for LABEL_REF). It should instead always first check the operand to be LABEL_REF, matching the first pattern. I'm labelling this as missed optimization; I can't make a strong case that the predicate call should be considered wrong-code, though the argument would be that it could assert, as there's no point calling it for a label_ref as the first pattern will always match. It could be that this is a special-case and that inspecting mode and calling predicates is seen as cheaper than inspecting the actual operand code and matching any mode, but at face value it doesn't make sense, in particular as the rules are that the first pattern has to match. See http://gcc.gnu.org/ml/gcc/2012-04/msg00771.html for actual generated code and further discussion.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #100 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22 18:43:18 UTC --- As as side, Sunday-type, observation, we don't normally use the work 'ticket' here (if only because no money is involved, at least, not in the open ;)
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 --- Comment #8 from Evgeny Ratnikov ratnikov.ev at ya dot ru 2012-04-22 19:11:22 UTC --- (In reply to comment #7) (In reply to comment #6) problem is that after such change my application (-std=98) linked with libraries (-std=0x) causes corrupted stack. You can't do that. It won't work. And what about the reverse situation? Old libraries, compiled with -std=98 and new code compiled with -std=0x. It is clear that there would be run-time problems. By the way there is nothing about it in 4.7.0-changes.
[Bug c/44774] -Werror=edantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774 --- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-22 19:17:51 UTC --- Author: manu Date: Sun Apr 22 19:17:47 2012 New Revision: 186681 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186681 Log: 2012-04-22 Manuel López-Ibáñez m...@gcc.gnu.org PR c/44774 gcc/ * doc/invoke.texi (pedantic): Rename to Wpedantic. * common.opt (Wpedantic): New. (pedantic): Alias Wpedantic. * diagnostic.c (warning_at): Likewise. * c-decl.c (diagnose_mismatched_decls): Likewise. (build_array_declarator): Likewise. (mark_forward_parm_decls): (check_bitfield_type_and_width): Likewise. (grokdeclarator): Likewise. (grokfield): Likewise. (finish_struct): Likewise. (build_enumerator): Likewise. (store_parm_decls_oldstyle): Likewise. (declspecs_add_qual): Likewise. (declspecs_add_type): Likewise. (finish_declspecs): Likewise. * c-typeck.c (composite_type): Likewise. (comp_target_types): Likewise. (build_array_ref): Likewise. (pointer_diff): Likewise. (build_unary_op): Likewise. (build_conditional_expr): Likewise. (build_c_cast): Likewise. (convert_for_assignment): Likewise. (maybe_warn_string_init): Likewise. (digest_init): Likewise. (pop_init_level): Likewise. (set_init_index): Likewise. (c_finish_goto_label): Likewise. (c_finish_return): Likewise. (do_case): Likewise. (build_binary_op): Likewise. * c-parser.c (static): Likewise. (c_parser_external_declaration): Likewise. (c_parser_declaration_or_fndef): Likewise. (c_parser_static_assert_declaration_no_se): Likewise. (c_parser_enum_specifier): Likewise. (c_parser_struct_or_union_specifier): Likewise. (c_parser_struct_declaration): Likewise. (c_parser_alignas_specifier): Likewise. (c_parser_braced_init): Likewise. (c_parser_initelt): Likewise. (c_parser_compound_statement_nostart): Likewise. (c_parser_conditional_expression): Likewise. (c_parser_alignof_expression): Likewise. (c_parser_postfix_expression): Likewise. (c_parser_postfix_expression_after_paren_): Likewise. (c_parser_objc_class_instance_variables): Likewise. (c_parser_objc_method_definition): Likewise. (c_parser_objc_methodprotolist): Likewise. c-family/ * c.opt (Wpedantic): New. (pedantic): Alias Wpedantic. * c-opts.c (c_common_handle_option): Replace -pedantic with -Wpedantic. (c_common_post_options): Likewise. (sanitize_cpp_opts): Likewise. * c-lex.c (interpret_float): Likewise. * c-format.c (check_format_types): Likewise. * c-common.c (pointer_int_sum): Likewise. (c_sizeof_or_alignof_type): Likewise. (c_add_case_label): Likewise. (c_do_switch_warnings): Likewise. * c-pragma.c (handle_pragma_float_const_decimal64): Likewise. cp/ * typeck.c (composite_pointer_type): Likewise. (cxx_sizeof_or_alignof_type): Likewise. (cp_build_array_ref): Likewise. (cp_build_function_call_vec): Likewise. (cp_build_addr_expr_1): Likewise. (convert_member_func_to_ptr): Likewise. * decl.c (check_tag_decl): Likewise. (check_static_variable_definition): Likewise. (compute_array_index_type): Likewise. (create_array_type_for_decl): Likewise. (grokdeclarator): Likewise. (grok_op_properties): Likewise. * error.c (maybe_warn_cpp0x): Likewise. * pt.c (maybe_process_partial_specialization): Likewise. (convert_template_argument): Likewise. (do_decl_instantiation): Likewise. (do_type_instantiation): Likewise. * parser.c (cp_parser_primary_expression): Likewise. (cp_parser_postfix_expression): Likewise. (cp_parser_unary_expression): Likewise. (cp_parser_question_colon_clause): Likewise. (cp_parser_lambda_introducer): Likewise. (cp_parser_lambda_declarator_opt): Likewise. (cp_parser_compound_statement): Likewise. (cp_parser_jump_statement): Likewise. (cp_parser_declaration_seq_opt): Likewise. (cp_parser_enum_specifier): Likewise. (cp_parser_enumerator_list): Likewise. (cp_parser_initializer_list): Likewise. (cp_parser_member_declaration): Likewise. * call.c (build_conditional_expr_1): Likewise. * friend.c (make_friend_class): Likewise. * name-lookup.c (pushdecl_maybe_friend_1): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-format.c trunk/gcc/c-family/c-lex.c trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c-pragma.c trunk/gcc/c-family/c.opt trunk/gcc/c-parser.c trunk/gcc/c-typeck.c trunk/gcc/common.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl.c trunk/gcc/cp/error.c trunk/gcc/cp/friend.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/typeck.c trunk/gcc/diagnostic.c
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22 19:18:13 UTC --- That last situation is really totally unsupported and never was. By the way, I don't know if you noticed already, but it doesn't work for many, many, reasons outside sizes of containers. It's totally broken everywhere. The linker should also warn about that, I think we have a PR, it's a much more general issue, warn when linking together stuff built passing ABI-incompatible switches.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #101 from Ivan Godard igodard at pacbell dot net 2012-04-22 19:35:08 UTC --- Well, it's easy to say that it's the other guy's problem, but it isn't. You are assuming that the linker is always gnu ld; for big shops with multi-platform targets that's not necessarily true. We can't expect vendors of other linkers to deal with gcc decisions. Instead, may I suggest that the problem is in collect2, which is where gcc generates an init_array; the linker just includes the table in the load module, unchanged from what collect2 gives it. I there's another bug list separately for collect2 then please give me the URL and I'll go away and bother them instead. You used to produce a section for each init; the linker knows about sections, so we can use the linker to enforce order. You are no longer producing a section for each init, but are instead jamming them together into an anonymous opaque object that a linker cannot change (hacks in your own linker notwithstanding). So long as you are going to do the jamming yourself, we mere users need some scripting mechanism to control it. Yes, there are options to preserve the legacy behavior. Until you get tired of supporting two mechanisms, or bitrot creeps into the legacy. I have enough trouble preserving C++ as a language of choice here in this shop, without gratuitous breakage of things that in truth are not part of the standard but nevertheless are needed for a working tool.
[Bug c/53075] New: -Werror=pedantic should be equivalent to -pedantic-errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53075 Bug #: 53075 Summary: -Werror=pedantic should be equivalent to -pedantic-errors Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org Some background discussion in PR 44774 and http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01324.html A currently visible effect is that $ cc1 ~/trunk/src/gcc/testsuite/gcc.dg/c90-init-1.c -pedantic-errors prints -Wpedantic while $ cc1 ~/trunk/src/gcc/testsuite/gcc.dg/c90-init-1.c -Werror=pedantic prints -Werror=pedantic (as it should).
[Bug c/44774] -Werror=edantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-22 19:57:47 UTC --- So the testcase here works, and -Werror=pedantic is accepted and printed correctly. However, -pedantic-errors still prints just -Wpedantic when it should print -Werror=pedantic. This is tracked in PR53075.
[Bug c/37187] please provide a way to treat -pedantic as warning when using -Werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37187 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Target|x86_64-linux-gnu| Host|x86_64-linux-gnu| Build|x86_64-linux-gnu| --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-22 20:03:11 UTC --- In GCC 4.8, you can use -Wno-error=pedantic for any warning that prints -Wpedantic. However, the testcase here does not because of a bug. I will try to fix the bug, but this part of the C FE is quite complex (and it looks ancient...) -pedantic changes something in a global variable and later the pedwarn is conditional on this global variable, so depending on the testcase, the pedwarn may be conditional or not on -pedantic (without passing the correct OPT_ value). Not fun.
[Bug regression/53076] New: [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c, gcc.dg/torture/builtin-power-1.c at -O0 soft-float newlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076 Bug #: 53076 Summary: [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c, gcc.dg/torture/builtin-power-1.c at -O0 soft-float newlib Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: wschm...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf These tests previously passed, now they fail. A patch in the revision range (last_known_working:first_known_failing) 186623:186630 exposed or caused these regressions. Since then they fail as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/dg-torture.exp ... FAIL: gcc.dg/torture/builtin-explog-1.c -O0 (test for excess errors) FAIL: gcc.dg/torture/builtin-power-1.c -O0 (test for excess errors) The messages in gcc.log are similar: Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c -fno-diagnostics-show-caret -O0 -ffast-math -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3 -lm -o builtin-explog-1.exe(timeout = 300) /tmp/cc0ahpu0.o: In function `test': builtin-explog-1.c:(.text+0x156): undefined reference to `link_failure_cbrt_exp' builtin-explog-1.c:(.text+0x28a): undefined reference to `link_failure_cbrt_exp2' builtin-explog-1.c:(.text+0x372): undefined reference to `exp10l' builtin-explog-1.c:(.text+0x39e): undefined reference to `exp10l' builtin-explog-1.c:(.text+0x3be): undefined reference to `link_failure_cbrt_exp10' builtin-explog-1.c:(.text+0x4a6): undefined reference to `pow10l' builtin-explog-1.c:(.text+0x4d2): undefined reference to `pow10l' builtin-explog-1.c:(.text+0x4f2): undefined reference to `link_failure_cbrt_pow10' and for the other test: builtin-power-1.c:(.text+0x178): undefined reference to `link_failure_pow_sqrt' builtin-power-1.c:(.text+0x32a): undefined reference to `link_failure_pow_cbrt' builtin-power-1.c:(.text+0x4e8): undefined reference to `link_failure_sqrt_pow' builtin-power-1.c:(.text+0x6ae): undefined reference to `link_failure_cbrt_pow' cris-elf is a soft-float newlib target and I guess the new code and/or test-cases are making invalid assumptions on what math functions are available; one or both need to be gated on their availability. Author of suspect patch in revision range CC:ed.
[Bug fortran/53077] New: suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
Bug #: 53077
Summary: suggestion to add the .f extension to the list of file
extensions that trigger enabling of the preprocessor
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sla...@staszic.waw.pl
Hello,
$ cat test.f
#define print(x) print*, x
program test
print('aqq')
end
$ gfortran -ffree-form test.f
Warning: test.f:1: Illegal preprocessor directive
test.f:3.8:
print('aqq')
1
Error: Missing leading left parenthesis in format string at (1)
$ mv test.f test.F
$ gfortran-mp-4.6 -ffree-form test.F echo OK
OK
This behavior is consistent with the docs but it's quite misleading, especially
as the warning message might be understood as if there was something wrong
within the macro definition, and not with the fact that the macro is there at
all.
Why not turning on the preprocessor with .f extensions as well?
(currently only the .F extension turns it on by default)
HTH,
Sylwester
[Bug fortran/53077] suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 --- Comment #1 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-22 20:35:49 UTC --- The gfortran-mp-4.6 vs. gfortran difference in the code above is not relevant to the issue.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #102 from Ian Lance Taylor ian at airs dot com 2012-04-22 21:16:14 UTC --- To be clear, nothing has changed in collect2. The only thing that has changed is that data that was being emitted in the .ctors section is now being emitted in the .init_array section (and similarly for .dtors and .fini_array). The reason this makes a difference is that the dynamic linker executes the entries in .init_array, whereas gcc-provided startup code executes the entries in .ctors. And they happen to execute the entries in different orders. The whole point of the change is in fact to execute the entries in a different order, though I continue to think that this would be better handled in a different way. In other words, it is not the case that gcc is producing an anoymous opaque object that the linker can not change.
[Bug fortran/53077] suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 --- Comment #2 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-22 21:36:33 UTC --- Hmm... apparently the PGI compiler uses the same rule for enabling preprocessor with .f and .F extensions. Then, if there's some important reason behind it (?) perhaps at least the warning message could be improved by indicating that the preprocessor is off.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #103 from Ivan Godard igodard at pacbell dot net 2012-04-22 21:52:40 UTC --- I may be just displaying my ignorance, but my understanding is that order under init_array is governed by order of pointers within the array itself, and where the pointed-to sections are in the file is irrelevant. After all, a reason for the switch was so Firefox could get the inits with fewer disk reads. So even if I can rearrange the init_array. sections nothing will change, because the order is set by the pointers and you have left me with no control over that. Not so?
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #104 from Ian Lance Taylor ian at airs dot com 2012-04-22 22:26:50 UTC --- I'm not sure what you mean. Each object file will have a .init_array section. The linker will assemble those sections in the usual manner. The order of global constructors in a single translation unit is fixed by the language standard. The thing that is not fixed is the order between translation units. So each object file will have a .init_array section that will typically contain only a single pointer. The order in which those input .init_array sections are combined into an output .init_array section will determine the order in which the constructors are run.
[Bug c++/53078] New: [C++11] Wrong diagnostic no return statement in function returning non-void on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078
Bug #: 53078
Summary: [C++11] Wrong diagnostic no return statement in
function returning non-void on
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m8r-gt1...@mailinator.com
GCC erroneously warns about a missing return in lambdas where the return type
is to be deduced as void.
Example:
$ cat a.c++
int main() { auto x = []{}; }
$ g++-4.8 -std=c++11 -Wall -Wextra -Werror -pedantic a.c++
a.c++: In lambda function:
a.c++:1:30: error: no return statement in function returning non-void
[-Werror=return-type]
cc1plus: all warnings being treated as errors
$
Neither of the following alternatives produces this diagnostic:
int main() { auto x = []{ return; }; }
int main() { auto x = []() - void {}; }
[Bug other/53065] ICE replace_reg_with_saved_mem, at caller-save.c:1125
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53065 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-22 CC||gjl at gcc dot gnu.org Component|c++ |other Ever Confirmed|0 |1 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-04-22 23:35:49 UTC --- Confirmed with mingw32 canadian cross for 4.7.0 and 4.7.1 (prerelease) from 2012-03-22. The following line triggers the ICE: $ avr-g++ -mmcu=atmega328p -gdwarf-2 -Os -c ahrs.cpp whereas removing -gdwarf-2 works fine. Is this a duplicate of PR52662?
[Bug c/53079] New: Unwanted optimization occurs on function with the same name as a math.h function without including math.h nor linking with libm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53079
Bug #: 53079
Summary: Unwanted optimization occurs on function with the same
name as a math.h function without including math.h nor
linking with libm
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kwariz@gmail.com
Created attachment 27218
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27218
test.i output but with #include stdio.h commented in test.c
A math function optimization is triggered when a function has the same name as
a math function, even if no link against libm is asked for.
This error occurs only when using the gcc front end, g++ produces a correct
code.
test.c
#include stdio.h
double floor(double x)
{
return 3.14;
}
int main()
{
double x;
x=1.1;
printf(floor(%lf)=%lf\n, 1.1, floor(1.1));
printf(floor(%lf)=%lf\n, x, floor(x));
return 0;
}
compile and run
gcc -Wall -Wextra -v -save-temps -o test test.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.6/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.6
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.6
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.6.2 (SUSE Linux)
COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-v' '-save-temps' '-o' 'test'
'-mtune=generic' '-march=x86-64'
/usr/lib64/gcc/x86_64-suse-linux/4.6/cc1 -E -quiet -v test.c -mtune=generic
-march=x86-64 -Wall -Wextra -fpch-preprocess -o test.i
#include ... search starts here:
#include ... search starts here:
/usr/lib64/gcc/x86_64-suse-linux/4.6/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/4.6/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-v' '-save-temps' '-o' 'test'
'-mtune=generic' '-march=x86-64'
/usr/lib64/gcc/x86_64-suse-linux/4.6/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -Wall -Wextra
-version -o test.s
GNU C (SUSE Linux) version 4.6.2 (x86_64-suse-linux)
compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 3.0.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (SUSE Linux) version 4.6.2 (x86_64-suse-linux)
compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 3.0.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: eb9bdda5160103bdfd1958724e664f28
test.c: In function ‘floor’:
test.c:3:21: warning: unused parameter ‘x’ [-Wunused-parameter]
COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-v' '-save-temps' '-o' 'test'
'-mtune=generic' '-march=x86-64'
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/as --64
-o test.o test.s
COMPILER_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.6/:/usr/lib64/gcc/x86_64-suse-linux/4.6/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.6/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/
LIBRARY_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.6/:/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-v' '-save-temps' '-o' 'test'
'-mtune=generic' '-march=x86-64'
/usr/lib64/gcc/x86_64-suse-linux/4.6/collect2 --build-id --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/crt1.o
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-suse-linux/4.6/crtbegin.o
-L/usr/lib64/gcc/x86_64-suse-linux/4.6
-L/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/4.6/../../.. test.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
[Bug c++/53078] [C++11] Wrong diagnostic no return statement in function returning non-void on lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-23
00:21:43 UTC ---
Are you *really* sure you are using current 4.8? I get:
paolo@poldo4:~/Work g++ -std=c++11 -Wall -Wextra -Werror -pedantic 53078.C
53078.C: In function ‘int main()’:
53078.C:1:19: error: variable ‘x’ set but not used
[-Werror=unused-but-set-variable]
int main() { auto x = []{}; }
^
[Bug fortran/53077] suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23 01:17:16 UTC --- Why can't you just pass the -cpp option to gfortran if you want to enable the preprocessor?
[Bug c/53079] Unwanted optimization occurs on function with the same name as a math.h function without including math.h nor linking with libm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53079 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23 01:19:48 UTC --- This is expected. If you don't want floor to be considered a builtin, then use -fno-builtin-floor . The C standard even says the name is in the reversed namespace really.
[Bug regression/53076] [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c, gcc.dg/torture/builtin-power-1.c at -O0 soft-float newlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23 01:26:41 UTC --- I saw this failure on non soft-float x86 too.
[Bug libstdc++/53080] New: std::array - std::get() and std::tuple_element is nothing bounds check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53080
Bug #: 53080
Summary: std::array - std::get() and std::tuple_element is
nothing bounds check
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: faithandbr...@gmail.com
23.3.2.9 Tuple interface to class template array in N3337(C++ Specification
Draft)
tuple_elementI, arrayT, N ::type
Requires: I N. The program is ill-formed if I is out of bounds.
template size_t I, class T, size_t N T get(arrayT, N a) noexcept;
Requires: I N. The program is ill-formed if I is out of bounds.
GCC 4.7.0 libstdc++ array header is no check bounds.
I think need static_assert to tuple_element and get().
Issue code is follow:
templatestd::size_t _Int, typename _Tp, std::size_t _Nm
struct tuple_element_Int, array_Tp, _Nm
{ typedef _Tp type; };
templatestd::size_t _Int, typename _Tp, std::size_t _Nm
constexpr _Tp
get(array_Tp, _Nm __arr) noexcept
{ return __arr._M_instance[_Int]; }
templatestd::size_t _Int, typename _Tp, std::size_t _Nm
constexpr _Tp
get(array_Tp, _Nm __arr) noexcept
{ return std::move(get_Int(__arr)); }
templatestd::size_t _Int, typename _Tp, std::size_t _Nm
constexpr const _Tp
get(const array_Tp, _Nm __arr) noexcept
{ return __arr._M_instance[_Int]; }
[Bug regression/53076] [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c, gcc.dg/torture/builtin-power-1.c at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8 Regression]: |[4.8 Regression]: |gcc.dg/torture/builtin-expl |gcc.dg/torture/builtin-expl |og-1.c, |og-1.c, |gcc.dg/torture/builtin-powe |gcc.dg/torture/builtin-powe |r-1.c at -O0 soft-float |r-1.c at -O0 |newlib | --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-04-23 02:19:14 UTC --- (In reply to comment #1) I saw this failure on non soft-float x86 too. Yep, it seems to be pretty universal; see e.g. i686-linux: http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02243.html, x86_64-linux: http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02237.html, sh-unknown-elf: http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02227.html and powerpc-aix: http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02239.html. PR title adjusted.
[Bug c++/53059] sizeof(std::list)=12 was 8 in previous releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059 --- Comment #10 from Evgeny Ratnikov ratnikov.ev at ya dot ru 2012-04-23 02:47:37 UTC --- Now it's clear. Thanks for replies. .
[Bug c++/53078] [C++11] Wrong diagnostic no return statement in function returning non-void on lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078 --- Comment #2 from M8R-gt1qwe at mailinator dot com 2012-04-23 03:58:52 UTC --- Ooops. That will teach me to make sure I update before filing a bug :S I was running 20120401. You can close this. It doesn't manifest on 20120422.
[Bug middle-end/53081] New: memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
Bug #: 53081
Summary: memcpy/memset loop recognition
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com
Both LLVM and icc recognize initialization and copy loop and synthesize calls
to memcpy and memset. memmove call can also be synthesized when src/target may
overlap.
Option needs to provided to disable such optimization in signal handlers.
I consider this as optimization for benchmarking ;) For instance, the prime
number finder program sieve.c is one of the benchmarks in LLVM. Both LLVM and
icc beats gcc in this one because of the missing optimization.
#ifndef T
#define T int
#endif
T arr[1000];
void foo(int n)
{
int i;
for (i = 0; i n; i++)
{
arr[i] = 0;
}
}
void foo2(int n, T* p)
{
int i;
for (i = 0; i n; i++)
{
*p++ = 0;
}
}
#ifndef T
#define T int
#endif
T arr[1000];
T arr2[1000];
void foo(int n)
{
int i;
for (i = 0; i n; i++)
{
arr[i] = arr2[i];
}
}
// sieve.c
/* -*- mode: c -*-
* $Id: sieve.c 36673 2007-05-03 16:55:46Z laurov $
* http://www.bagley.org/~doug/shootout/
*/
#include stdio.h
#include stdlib.h
int
main(int argc, char *argv[]) {
#ifdef SMALL_PROBLEM_SIZE
#define LENGTH 17000
#else
#define LENGTH 17
#endif
int NUM = ((argc == 2) ? atoi(argv[1]) : LENGTH);
static char flags[8192 + 1];
long i, k;
int count = 0;
while (NUM--) {
count = 0;
for (i=2; i = 8192; i++) {
flags[i] = 1;
}
for (i=2; i = 8192; i++) {
if (flags[i]) {
/* remove all multiples of prime: i */
for (k=i+i; k = 8192; k+=i) {
flags[k] = 0;
}
count++;
}
}
}
printf(Count: %d\n, count);
return(0);
}
[Bug middle-end/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23 05:03:28 UTC --- I thought there is already one part of graphite.
[Bug middle-end/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23 05:07:30 UTC --- I should mention I made one patch before based on the vectorizer code which did detection of at least memset; it was while I was an intern at Apple. I posted it and there was some review. And a few years back there was a paper at the GCC summit about it and expanding it to memcpy. I don't know what happened to that code though.
[Bug middle-end/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #3 from davidxl xinliangli at gmail dot com 2012-04-23 05:34:24 UTC --- (In reply to comment #2) I should mention I made one patch before based on the vectorizer code which did detection of at least memset; it was while I was an intern at Apple. I posted it and there was some review. And a few years back there was a paper at the GCC summit about it and expanding it to memcpy. I don't know what happened to that code though. Some simple analysis using scev to identify loads and stores with linear address should be good enough. LLVM's version also tries to merge smaller memsets into a larger one.
[Bug middle-end/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #4 from davidxl xinliangli at gmail dot com 2012-04-23 05:34:55 UTC --- (In reply to comment #2) I should mention I made one patch before based on the vectorizer code which did detection of at least memset; it was while I was an intern at Apple. I posted it and there was some review. And a few years back there was a paper at the GCC summit about it and expanding it to memcpy. I don't know what happened to that code though. Some simple analysis using scev to identify loads and stores with linear address should be good enough. LLVM's version also tries to merge smaller memsets into a larger one.
[Bug middle-end/53082] New: local malloc/free optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53082
Bug #: 53082
Summary: local malloc/free optimization
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com
Malloc/free pairs sometimes are used in a way that behaves like a stack memory.
The optimizer should recognize the pattern and take advantage of it. For
instance if the memory is not escaped, dead stores to the memory can be
removed. In extreme case, the malloc/free pair can be completely removed.
For instance:
for (i = 0; i 100; i++)
{
int *s = (int*) malloc (sizeof(int));
*s = 10;
free (s);
}
This code can be completely removed (which LLVM does).
The above can be considered as a benchmarking optimization -- see the one
appended (objinst.c in LLVM's benchmark suite).
The following more advanced optimization (which as far as I know only HP
compiler does) can also be done: coalescing multiple malloc calls into one
alloca call, and eliminating the free calls. The memory can be escaped.
for (...)
{
int *s1 = malloc (...);
int *s2 = malloc (...);
int *s3 = malloc (...);
...
free(s1); free(s2); free(s3);
}
==
for (...)
{
int s = alloca (...);
s1 = s;
s2 = s+ ..
s3 = s+ ..
...
}
// objinst.c
/* -*- mode: c -*-
* $Id: objinst.c 36673 2007-05-03 16:55:46Z laurov $
* http://www.bagley.org/~doug/shootout/
*/
#include stdio.h
#include stdlib.h
enum {false, true};
#define TOGGLE \
char state; \
char (*value)(struct Toggle *); \
struct Toggle *(*activate)(struct Toggle *)
#define DESTROY free
typedef struct Toggle {
TOGGLE;
} Toggle;
char toggle_value(Toggle *this) {
return(this-state);
}
Toggle *toggle_activate(Toggle *this) {
this-state = !this-state;
return(this);
}
Toggle *init_Toggle(Toggle *this, char start_state) {
this-state = start_state;
this-value = toggle_value;
this-activate = toggle_activate;
return(this);
}
Toggle *new_Toggle(char start_state) {
Toggle *this = (Toggle *)malloc(sizeof(Toggle));
return(init_Toggle(this, start_state));
}
typedef struct NthToggle {
Toggle base;
int count_max;
int counter;
} NthToggle;
NthToggle *nth_toggle_activate(NthToggle *this) {
if (++this-counter = this-count_max) {
this-base.state = !this-base.state;
this-counter = 0;
}
return(this);
}
NthToggle *init_NthToggle(NthToggle *this, int max_count) {
this-count_max = max_count;
this-counter = 0;
this-base.activate = (Toggle *(*)(Toggle *))nth_toggle_activate;
return(this);
}
NthToggle *new_NthToggle(char start_state, int max_count) {
NthToggle *this = (NthToggle *)malloc(sizeof(NthToggle));
this = (NthToggle *)init_Toggle((Toggle *)this, start_state);
return(init_NthToggle(this, max_count));
}
int main(int argc, char *argv[]) {
#ifdef SMALL_PROBLEM_SIZE
#define LENGTH 700
#else
#define LENGTH 7000
#endif
int i, n = ((argc == 2) ? atoi(argv[1]) : LENGTH);
Toggle *tog;
NthToggle *ntog;
tog = new_Toggle(true);
for (i=0; i5; i++) {
puts((tog-activate(tog)-value(tog)) ? true : false);
}
DESTROY(tog);
for (i=0; in; i++) {
tog = new_Toggle(true);
DESTROY(tog);
}
puts();
ntog = new_NthToggle(true, 3);
for (i=0; i8; i++) {
const char *Msg;
if (ntog-base.activate((Toggle*)ntog)-value((Toggle*)ntog))
Msg = true;
else
Msg = false;
puts(Msg);
}
DESTROY(ntog);
for (i=0; in; i++) {
ntog = new_NthToggle(true, 3);
DESTROY(ntog);
}
return 0;
}
