Re: Modifying the datatype of a formal parameter
Hi, On Sun, Dec 18, 2011 at 01:57:17PM +1100, Matt Davis wrote: I am using 'ipa_modify_formal_parameters()' to change the type of a function's formal parameter. After my pass completes, I get a 'gimple_expand_cfg()' error. I must be missing some key piece here, as the failure points to a NULL SA.partition_to_pseudo value. I also set_default_ssa_name() on the returned value from ipa_modify_formal_parameter (the adjustment's 'reduction' field). Do I need to re-gimplify the function or run some kind of 'cleanup' or 'update' once I modify this formal parameter? It's difficult to say without knowing what and at what stage of the compilation you are doing. The sad truth is that ipa_modify_formal_parameters is very much crafted for its sole user which is IPA-SRA and is probably quite less general than what the original intention was. Any pass using the function then must modify the body itself to reflect the changes, just like IPA-SRA does. SRA does not re-gimplify the modify functions, it just returns TODO_update_ssa or (TODO_update_ssa | TODO_cleanup_cfg) if any EH cleanup changed the CFG. So I would suggest to have a look at IPA-SRA (grep for the only call to ipa_modify_formal_parameters in tree-sra.c), especially at what you do differently. If you then have any further questions, feel free to ask. Martin
Re: Modifying the datatype of a formal parameter
Hi Martin and thank you very much for your reply. I do have some more resolution to my issue. On Mon, Dec 19, 2011 at 8:42 PM, Martin Jambor mjam...@suse.cz wrote: Hi, On Sun, Dec 18, 2011 at 01:57:17PM +1100, Matt Davis wrote: I am using 'ipa_modify_formal_parameters()' to change the type of a function's formal parameter. After my pass completes, I get a 'gimple_expand_cfg()' error. I must be missing some key piece here, as the failure points to a NULL SA.partition_to_pseudo value. I also set_default_ssa_name() on the returned value from ipa_modify_formal_parameter (the adjustment's 'reduction' field). Do I need to re-gimplify the function or run some kind of 'cleanup' or 'update' once I modify this formal parameter? It's difficult to say without knowing what and at what stage of the compilation you are doing. My pass is getting called as the last IPA pass (PLUGIN_ALL_IPA_PASSES_END). I do use the same function ipa_modify_formal_parameters() to add additional parameters to certain functions. And it works well. The sad truth is that ipa_modify_formal_parameters is very much crafted for its sole user which is IPA-SRA and is probably quite less general than what the original intention was. Any pass using the function then must modify the body itself to reflect the changes, just like IPA-SRA does. SRA does not re-gimplify the modify functions, it just returns TODO_update_ssa or (TODO_update_ssa | TODO_cleanup_cfg) if any EH cleanup changed the CFG. Yep, and I do call update_ssa and cleanup_tree_cfg() after my pass. So I would suggest to have a look at IPA-SRA (grep for the only call to ipa_modify_formal_parameters in tree-sra.c), especially at what you do differently. If you then have any further questions, feel free to ask. Yeah, that was one of the first things I did. Now, as mentioned, I do have some more clarity on my issue. Basically, I am just changing the type of an existing formal parameter. When I look at gimple_expand_cfg() which is called later, I notice that the SA.partition_to_pseudo for that parameter is NULL, to which gimple_expand_cfg() aborts() on. Now, that value is NULL, because in gimple_expand_cfg() the function expand_used_vars() is called. I need expand_one_var() called since that should fix-up the RTX assigned to the parameter I am modifying. Unfortunately, the bitmap, SA.partition_has_default_def is true for the parameter, even if I do not set it explicitly. And since it is always set, the expand_one_var() routine is never called. I need to unset the default def associated to the param to force expand_one_var() to execute. So, for the ssa name assigned to the parameter I am modifying, I use SSA_NAME_IS_DEFAULT_DEF to set the flag to 'false' This sounds like a really gross hack. If I do this, I will need to set a new ssa definition for the modified parameter. -Matt
NYC: Moving and other jobs from 19$ per man on van/truck/hour,discounts for 7th and latest hours of jobtime or fix rate for whole jobs
NYC:Moving and other jobs 19$/hour/man on van/truck with no hidden fees Our team of healthy english and russian speaking guys looking for a group or personal job on own minivans or rented truck We doing deliveries and any type of movies From delivery of a coach to 3 bedroom house relocation **$19/HOUR 1 MAN ON MINIVAN+$19/TRUCK No hidden fees. All other work free Local and long distances WE DO NOT charge for: -stairs -mileage -tools -blankets -etc Call Michael (646) 515-3056 any time 24/7 my Email: ourkons...@yahoo.co.uk SKILLS RYTMIKO and intonation COMMUNICATIVE EXERCISES PREDTEKSTOVYE EXERCISES
Possible wrong-way example in gcc4-4-2 documentation of __builtin_expect
Hello, The online docs at http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Other-Builtins.html has a confusing (to me) example of __builtin_expect. Could someone take a look at this? start quote from above-referenced page Since you are limited to integral expressions for exp, you should use constructions such as if (__builtin_expect (ptr != NULL, 1)) error (); end quote This seems backwards.The return value of __builtin_expect is the first argument, namely (ptr != NULL), which presumably is true in the NON-error case. The following example might be more helpful: if (__builtin_expect (ptr == NULL, 0)) error (); Apologies if I'm not reading this correctly. -Jim
[Bug tree-optimization/51606] [4.7 Regression] FAIL: gcc.dg/vect/pr51015.c (internal compiler error) on ppc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51606 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug fortran/51616] [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/51606] [4.7 Regression] FAIL: gcc.dg/vect/pr51015.c (internal compiler error) on ppc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51606 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 09:23:00 UTC --- Dup (and PR51580 likely too). *** This bug has been marked as a duplicate of bug 51590 ***
[Bug middle-end/51590] [4.7 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51590 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 09:23:00 UTC --- *** Bug 51606 has been marked as a duplicate of this bug. ***
[Bug testsuite/51603] ERROR: g++.dg/cpp0x/rv-cast[34].C: syntax error in target selector target c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51603 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 09:23:20 UTC --- Works for me as well (checked on trunk and the 4.6 branch).
[Bug middle-end/51590] [4.7 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51590 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-19 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 09:25:07 UTC --- Created attachment 26134 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26134 gcc47-pr51590.patch Untested fix.
[Bug c++/51601] ice in verify_live_on_entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51601 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-19 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 09:27:06 UTC --- Confirmed, reducing.
[Bug c++/51600] ice in estimate_local_effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51600 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-19 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 09:29:13 UTC --- Confirmed. Reducing.
[Bug bootstrap/51599] [4.7 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51599 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/51596] [4.7 Regression] ICE: verify_flow_info failed: BB 6 can not throw but has an EH edge with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51596 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-19 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 09:30:51 UTC --- Confirmed.
[Bug c/51597] math libraryb not works
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51597 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 09:31:25 UTC --- linker arguments need to follow sources.
[Bug c/51595] math libraryb not works
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51595 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 09:31:41 UTC --- .
[Bug tree-optimization/51581] Integer division by constant is not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51581 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-19 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 09:34:08 UTC --- Confirmed.
[Bug c++/51620] [c++0x] [4.6/4.7 Regression] ICE with private destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51620 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/51477] [c++0x] ICE with initialization of invalid non-static data member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51477 --- Comment #4 from Dodji Seketeli dodji at gcc dot gnu.org 2011-12-19 09:47:51 UTC --- Author: dodji Date: Mon Dec 19 09:47:46 2011 New Revision: 182474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182474 Log: PR c++/51477 - ICE with invalid NSDMI gcc/cp/ PR c++/51477 * search.c (lookup_member): Get out early on invalid base type. gcc/testsuite/ PR c++/51477 * g++.dg/cpp0x/nsdmi6.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/search.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51477] [c++0x] ICE with initialization of invalid non-static data member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51477 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Dodji Seketeli dodji at gcc dot gnu.org 2011-12-19 09:48:32 UTC --- This should be fixed in trunk (4.7)
[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48881 Pierre Ossman ossman at cendio dot se changed: What|Removed |Added CC||ossman at cendio dot se --- Comment #4 from Pierre Ossman ossman at cendio dot se 2011-12-19 10:11:18 UTC --- Well that was a bit rude. If this bug only appears under certain circumstances, then shouldn't we try to find those circumstances rather than just saying that if gcc works on your machine then that's good enough?
[Bug c++/51532] Invalid Code Generated for cpu32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51532 --- Comment #6 from Andreas Schwab schwab at gcc dot gnu.org 2011-12-19 10:14:17 UTC --- Author: schwab Date: Mon Dec 19 10:14:13 2011 New Revision: 182475 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182475 Log: PR target/51532 * config/m68k/m68k.h (FL_CAS, TARGET_CAS): Define. * config/m68k/m68k.c (FL_FOR_isa_20): Add FL_CAS. * config/m68k/sync.md: Use TARGET_CAS instead of (TARGET_68020 || TARGET_68040). Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.c trunk/gcc/config/m68k/m68k.h trunk/gcc/config/m68k/sync.md
[Bug target/51532] Invalid Code Generated for cpu32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51532 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|NEW |RESOLVED Component|c++ |target Resolution||FIXED --- Comment #7 from Andreas Schwab sch...@linux-m68k.org 2011-12-19 10:15:03 UTC --- Fixed.
[Bug c++/51619] [c++0x] [4.6/4.7 Regression] ICE with array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51619 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-19 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 10:20:37 UTC --- Created attachment 26135 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26135 gcc47-pr51619.patch Untested fix.
[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48881 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org 2011-12-19 10:23:51 UTC --- Well, I wouldn't say that this was rude. The issue here is most likely, that the runtime DLLs by gcc aren't in search-path when you are trying to execute your built application. But this isn't a subject of gcc itself. I see that you have this issue, but user-support questions on how to setup environment for built applications, or what is necessary to provide along-side built-application so that they run, is more something related to gcc's user ML, or even better to ask directly for it on mingw.org's or mingw-w64's public user-mailing lists. On those later lists you can be sure that you will find a solution for your issue.
[Bug libstdc++/51609] [C++11] unique_ptrconst T[]::reset rejects cv-compatible argument pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 10:26:57 UTC --- OK, thanks, Daniel
[Bug libstdc++/51617] [C++0x] async(f) isn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 10:43:22 UTC --- Yes, this was an intentional choice (as I described in message c++std-lib-30840) to ensure the system doesn't get killed by a fork bomb, e.g. writing a parallel sort algorithm using async which launches a new thread for every partition. I tried it, it wasn't pretty :) At some point I will use getloadavg() or equivalent functionality to check the system load and decide whether to launch a new thread or not, until then the safer choice is to require a user to explicitly request it (then it's the user's fault if they fork bomb their machine!)
[Bug libstdc++/51617] [C++0x] async(f) isn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-19 Blocks||49204 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 10:49:41 UTC --- confirming as an enhancement request
[Bug tree-optimization/51596] [4.7 Regression] ICE: verify_flow_info failed: BB 6 can not throw but has an EH edge with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51596 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 10:51:47 UTC --- Created attachment 26136 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26136 gcc47-pr51596.patch Untested fix.
[Bug java/51465] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51465 --- Comment #2 from Kiskunsag gykarsai at all dot hu 2011-12-19 10:54:50 UTC --- Created attachment 26137 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26137 file for Error message by compilation Error message by compilation
[Bug java/51465] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51465 --- Comment #3 from Kiskunsag gykarsai at all dot hu 2011-12-19 10:57:02 UTC --- Created attachment 26138 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26138 Breaked assembler source Breaked by error assembler source of converted JAVA jar
[Bug java/51465] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51465 Kiskunsag gykarsai at all dot hu changed: What|Removed |Added Severity|normal |blocker
[Bug libstdc++/51617] [C++0x] async(f) isn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 --- Comment #4 from Dave Abrahams dave at boostpro dot com 2011-12-19 10:58:46 UTC --- (In reply to comment #2) Yes, this was an intentional choice (as I described in message c++std-lib-30840) to ensure the system doesn't get killed by a fork bomb, e.g. writing a parallel sort algorithm using async which launches a new thread for every partition. I tried it, it wasn't pretty :) Hey, cool; I tried it too. I mean, when I discovered async wasn't async. :-) At some point I will use getloadavg() or equivalent functionality to check the system load and decide whether to launch a new thread or not, until then the safer choice is to require a user to explicitly request it (then it's the user's fault if they fork bomb their machine!) Yeah, but in the meantime you could also just limit async() threads to hardware_concurrency() using the technique shown in my attachment. It wouldn't necessarily guarantee good performance but it would be enough to prevent async from fork bombing while still allowing some semi-intelligent amount of parallelism.
[Bug tree-optimization/51601] [4.7 Regression] ice in verify_live_on_entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51601
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Component|c++ |tree-optimization
Target Milestone|--- |4.7.0
Summary|ice in verify_live_on_entry |[4.7 Regression] ice in
||verify_live_on_entry
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19
11:04:30 UTC ---
int
getDuration(int dot_)
{
int duration = (int) 32;
int dotLength = duration;
for (int i = 0; i dot_; ++i)
dotLength /= 2;
duration += dotLength;
return duration;
}
Caused by the vectorizer.
[Bug libstdc++/51617] [C++0x] async(f) isn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 11:13:25 UTC --- That would require a global integer somewhere to count the threads, which would probably have to be kept forever to maintain ABI compatibility. If I had time to implement a temporary semi-intelligent fix then I'd rather just do it properly instead :)
[Bug middle-end/51590] [4.7 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51590 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 11:16:11 UTC --- *** Bug 51601 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/51601] [4.7 Regression] ice in verify_live_on_entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51601 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 11:16:11 UTC --- Dup. *** This bug has been marked as a duplicate of bug 51590 ***
[Bug c++/51328] [4.4/4.5/4.6/4.7 Regression] ICE on invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51328
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-19
11:22:34 UTC ---
Fixing the ICE seems rather easy (an overeager gcc_assert?), but then we
reject:
templatetypename T struct A
{
void foo(Atypename T::~T);
};
which EDG accepts, apparently. Jason, is this also a rejects-valid?
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-19 11:39:55 UTC --- Created attachment 26139 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26139 Draft patch (for the rejects-valid part, not for the ICE) Draft patch, which allows again ptr = associate-name It also fixes an ICE (class_ok part, (a)) and issues with coarrays and select type. [Coarrays now fail after resolution with an ICE.] Test cases (a) to (d): type t end type t class(t), target :: p1 ! (a) Invalid (was ICEing before) !class(t), allocatable, target :: p1 ! (b) Valid (unchanged by the patch) !class(t), allocatable :: p1 ! (c) Correctly fails (ditto) !class(t), pointer :: p1 ! (d) Valid (now accepted) class(t), pointer :: p2 select type(p1) type is(t) p2 = p1 class is(t) p2 = p1 end select end * * * Having fixed the rejects-valid issue, one again hits: internal compiler error: in gfc_trans_block_construct, at fortran/trans-stmt.c:1215 1209 ns = code-ext.block.ns; 1211 sym = ns-proc_name; 1215 gcc_assert (!sym-tlink); Here, sym-name is eval_int_expr and sym-tlink == sym. The issue is seemingly the following code in an internal procedure: integer_or_logical: select type(symbol_ptr) ... end select integer_or_logical and then another internal procedure: subroutine integer_or_logical( expr_str, flag) ... end subroutine integer_or_logical recursive subroutine eval_int_expr( int_expr, value) The label integer_or_logical of the block some clashes with the same-named subroutine - and thus marks the subroutine which follows somehow as EXPR_BLOCK?!?
[Bug libstdc++/51618] synchronous futures are slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 11:51:52 UTC --- Could you expand on what you mean by no attached synchronization? If a global future visible to all threads stores a deferred function then it still needs synchronization to ensure only one thread can invoke the deferred function and that other threads will wait for it to complete. std::async is not meant to be the fastest or most flexible solution, it's meant to be a simple way to exploit a limited amount of concurrency, without breaking the Kona compromise. Better solutions are suitable for TR2.
[Bug c/51622] New: GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 Bug #: 51622 Summary: GCC generates bad code that generate big executable sizes when using _Decimal* Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: mingo...@gmail.com Created attachment 26140 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26140 Program and a batch file to show how strange is gcc code generation when using _Decimal* The main point here is to demonstrate that gcc is capable to generate good code size when using _Decimal* but for some reason it get lost with some code combinations and generates very big executables unnecessarily making a bad balance between functionality/size. Here is a program that demonstrate that gcc is generating bad code resulting in big executables when using _Decimal*. There is a main.c with several operations on _Decimal64, few on _Decimal128 with some combination of the code (with all operations) the final executable file is 8KB but with a different combination (again with all operations) the executable is 2.206KB or 2.2MB. This last one is very strange because the diference betwen then is calling a printf to print several existing _Decimal64 variable (the biggest 2.2MB) and calling a printf to print only one existing _Decimal64 variable ((double)discount_over_sales the smallest 8KB but if we try to any other existing variables it goes to 2.2MB). gcc -s -O2 -DWITH_TMP main.c -o smallest.exe - 8KB gcc -s -O2 -DWITH_ONE_BIG_PRINTF -DWITH_TMP main.c -o strange-big-size-jump.exe - 2.206KB or 2.2MB gcc -s -O2 main.c -o good1.exe - 8KB gcc -s -O2 -DWITH_DEC128 -DWITH_ISNAN -DWITH_MPRINTF main.c printf.c -o biggest.exe - 2.444KB or 2.4MB gcc -s -O2 -DWITH_MPRINTF main.c printf.c -o optimus.exe - 154KB gcc -s -O2 -DWITH_DEC128 -DWITH_MPRINTF main.c printf.c -o good2.exe - 367KB
[Bug libstdc++/51618] synchronous futures are slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 --- Comment #2 from Dave Abrahams dave at boostpro dot com 2011-12-19 12:11:33 UTC --- on Mon Dec 19 2011, redi at gcc dot gnu.org gcc-bugzilla-AT-gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 11:51:52 UTC --- Could you expand on what you mean by no attached synchronization? There's not much to say. Attached is probably superfluous. If a global future visible to all threads stores a deferred function then it still needs synchronization to ensure only one thread can invoke the deferred function and that other threads will wait for it to complete. I'm confused. IIUC even shared_futures aren't supposed to be accessed concurrently from multiple threads. Why would multiple threads be accessing a single plain future? std::async is not meant to be the fastest or most flexible solution, it's meant to be a simple way to exploit a limited amount of concurrency, without breaking the Kona compromise. Better solutions are suitable for TR2. I know it's not supposed to be the fastest, but it seems as though it can be optimized. If a trivial parallel mergesort using async can run 3x faster than it does now, that's a huge win for users: it means they can put off trying complex and/or dangerous alternatives.
[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #1 from Domingo Alvarez mingodad at gmail dot com 2011-12-19 12:17:28 UTC --- If code generation is solved probably we can have better results with the following: lua 5.1.4 with double - 150KB lua 5.1.4 with _Decimal64 - 2.4MB *with ***bad code generation lua 5.1.4 with _Decimal64 - 160KB *with hopefully ***good code generation sqlite3 with double - 500KB sqlite3 with _Decimal64 - 3MB *with ***bad code generation sqlite3 with _Decimal64 - 530KB *with hopefully ***good code generation The same proportion probably will apply to any other program using _Decimal* wich will make using _Decimal* a very interesting option.
[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48881 Peter Åstrand astrand at cendio dot se changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | --- Comment #6 from Peter Åstrand astrand at cendio dot se 2011-12-19 12:23:59 UTC --- (In reply to comment #5) Well, I wouldn't say that this was rude. The issue here is most likely, that the runtime DLLs by gcc aren't in search-path when you are trying to execute your built application. This is not how Windows works. If the DLLs aren't found, the application isn't started at all. But in this case, the binaries do start, but immediately crashes. Thus, this cannot be an installation problem. It's of course possible that our *build* of GCC is different in some way that triggers this bug. But something is clearly wrong here, and as I mentioned in the original report, 4.4.3 worked fine. We are working a Subversion based build environment, and our build of 4.5.2 is therefore done in exactly the same way as 4.4.3, which worked. We did however upgrade binutils from 2.20 to 2.21 in the same step. We also migrated our thread fixes. I will attach both patches. Can you reproduce the problem if you are using the same settings as we?
[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48881 --- Comment #7 from Peter Åstrand astrand at cendio dot se 2011-12-19 12:24:44 UTC --- Created attachment 26141 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26141 gcc-4.4.3-threads.patch
[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-12-19 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 12:25:16 UTC --- Which architecture are you compiling for?
[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48881 --- Comment #8 from Peter Åstrand astrand at cendio dot se 2011-12-19 12:25:13 UTC --- Created attachment 26142 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26142 gcc-4.5.2-threads.patch
[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 12:33:42 UTC --- There are already some partial explanations in bug 51364
[Bug target/51003] bfin ICE compiling libgcc in gen_const_vector, at emit-rtl.c:5476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51003 Bernd Schmidt bernds at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Bernd Schmidt bernds at gcc dot gnu.org 2011-12-19 12:41:00 UTC --- Fixed.
[Bug fortran/51616] [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616 --- Comment #6 from dave.anglin at bell dot net 2011-12-19 13:05:34 UTC --- On 18-Dec-11, at 9:21 PM, sgk at troutmask dot apl.washington.edu wrote: http://gcc.gnu.org/ml/fortran/2011-11/msg00051.html hpux11 appears to be yet another OS that has sufficient quad support that gfortran detects a REAL(16) type, but the OS lacks the basic libm functions. Yes. -- John David Anglindave.ang...@bell.net
[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388 --- Comment #9 from Andreas Schwab schwab at gcc dot gnu.org 2011-12-19 13:12:31 UTC --- Author: schwab Date: Mon Dec 19 13:12:26 2011 New Revision: 182478 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182478 Log: Check for warning flags without no- prefix config/: PR bootstrap/51388 * warnings.m4 (ACX_PROG_CC_WARNING_OPTS) (ACX_PROG_CC_WARNING_ALMOST_PEDANTIC): Run the test without the no- prefix. fixincludes/: * configure: Regenerate. gcc/: * configure: Regenerate. libcpp/: * configure: Regenerate. libdecnumber/: * configure: Regenerate. libiberty/: * configure: Regenerate. lto-plugin/: * configure: Regenerate. Modified: trunk/config/ChangeLog trunk/config/warnings.m4 trunk/fixincludes/ChangeLog trunk/fixincludes/configure trunk/gcc/ChangeLog trunk/gcc/configure trunk/libcpp/ChangeLog trunk/libcpp/configure trunk/libdecnumber/ChangeLog trunk/libdecnumber/configure trunk/libiberty/ChangeLog trunk/libiberty/configure trunk/lto-plugin/ChangeLog trunk/lto-plugin/configure
[Bug libstdc++/51618] synchronous futures are slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 13:13:32 UTC --- (In reply to comment #2) I'm confused. IIUC even shared_futures aren't supposed to be accessed concurrently from multiple threads. Why would multiple threads be accessing a single plain future? future::wait() and shared_future::get() are const member functions, so must not introduce data races if called from multiple threads (17.6.5.9 [res.on.data.races]). So it doesn't matter _why_ someone might want to do that, they're not forbidden from doing so and therefore we have to provide some level of internal synchronization to prevent data races. I'm not claiming the current implementation is optimal but I don't think we can just turn off all synchronization for deferred functions, and identifying if we can make specific changes for deferred functions is not high on my priority list. I'd rather spend time replacing the mutex-protected std::unique_ptrResult_base with a std::atomicResult_base*, which could benefit all uses of futures rather than just the deferred async case. Although maybe sub-optimal the current mutex-based impl has the advantage of (relative) simplicity because the unique_ptr manages the result's lifetime and the mutex is also used by the condition_variable that signals when the result becomes ready. If you have specific suggestions for improving anything then I'll be happy to hear them, but don't expect me to work on this otherwise, sorry.
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-19 13:17:15 UTC --- Dan: Your program should work (with 4.6.2 - or with 4.7 + my patch) if you either change either the SELECT TYPE label or the subroutine name from integer_or_logical to something else. * * * Reduced test case for the ICE: contains subroutine foo BLOCK_NAME: block end block BLOCK_NAME end subroutine foo subroutine BLOCK_NAME() end subroutine BLOCK_NAME subroutine bar() end subroutine bar end
[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271
--- Comment #15 from vries at gcc dot gnu.org 2011-12-19 13:17:23 UTC ---
given this definition, maybe insn 141 should be marked as frame-related, since
it restores a reg in the epilogue.
It seems to be the other way round: insn 141 is ignored by scan_insn_after,
because:
- it is not frame-related, and
- doesn't contain a REG_ARGS_SIZE note.
The problematic insn is insn 143. That one has the REG_CFA notes attached, and
is causes changes in cfi state.
In scan_trace, we're handling insn 143 as element in the delay slot of an
annulling branch, executed only on taken branch:
...
(gdb) call debug_rtx (elt)
(insn/s/f 143 79 162 (set (reg/f:SI 29 $sp)
(plus:SI (reg/f:SI 29 $sp)
(const_int 16 [0x10]))) 10 {*addsi3}
(expr_list:REG_CFA_DEF_CFA (reg/f:SI 29 $sp)
(expr_list:REG_CFA_RESTORE (reg:DI 28 $28)
(nil
...
The row state at that point is:
...
(gdb) call debug_cfi_row (cur_row)
.cfi_def_cfa 29, 16
.cfi_offset 28, -8
...
we then execute scan_insn_after to setup the trace at the target of the jump:
...
(gdb)
2460 scan_insn_after (elt);
at which point the REG_CFAs have been taken into account:
...
(gdb) call debug_cfi_row (cur_row)
.cfi_def_cfa 29, 0
...
we then try to restore for the fallthru path:
...
2467 cur_trace-end_true_args_size = restore_args_size;
(gdb) n
2468 cur_row-cfa = this_cfa;
(gdb)
...
but the state is not sufficiently restored:
...
(gdb) call debug_cfi_row (cur_row)
.cfi_def_cfa 29, 16
...
The '.cfi_offset 28, -8' is missing.
This tentative patch fixes the problem for the testcase:
...
Index: src/gcc-mainline/gcc/dwarf2cfi.c
===
--- src/gcc-mainline/gcc/dwarf2cfi.c (revision 182341)
+++ src/gcc-mainline/gcc/dwarf2cfi.c (working copy)
@@ -2452,10 +2452,12 @@ scan_trace (dw_trace_info *trace)
if (INSN_FROM_TARGET_P (elt))
{
HOST_WIDE_INT restore_args_size;
+ cfi_vec save_row_reg_save;
add_cfi_insn = NULL;
restore_args_size = cur_trace-end_true_args_size;
cur_cfa = cur_row-cfa;
+ save_row_reg_save = VEC_copy (dw_cfi_ref, gc, cur_row-reg_save);
scan_insn_after (elt);
@@ -2466,6 +2468,7 @@ scan_trace (dw_trace_info *trace)
cur_trace-end_true_args_size = restore_args_size;
cur_row-cfa = this_cfa;
+ cur_row-reg_save = save_row_reg_save;
cur_cfa = this_cfa;
continue;
}
...
[Bug libstdc++/51618] synchronous futures are slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 --- Comment #4 from Dave Abrahams dave at boostpro dot com 2011-12-19 13:24:16 UTC --- Not a problem; thanks for looking.
[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51471
--- Comment #13 from vries at gcc dot gnu.org 2011-12-19 13:23:41 UTC ---
(In reply to comment #11)
This is the patch which I am testing:
Index: genattrtab.c
===
--- genattrtab.c(revision 182342)
+++ genattrtab.c(working copy)
@@ -4280,6 +4280,11 @@ write_eligible_delay (const char *kind)
printf ( if (!INSN_P (candidate_insn))\n);
printf (return 0;\n);
printf (\n);
+ /* Frame related instructions are hard to put in the delay slot for
+ debugging info reasons. */
+ printf ( if (RTX_FRAME_RELATED_P (candidate_insn))\n);
+ printf (return 0;\n);
+ printf (\n);
/* If more than one delay type, find out which type the delay insn is. */
What is the exact reason we're completely avoiding scheduling frame-related
insns in delay slots? Why don't we try to fix it like this?:
...
Index: src/gcc-mainline/gcc/reorg.c
===
--- src/gcc-mainline/gcc/reorg.c (revision 182341)
+++ src/gcc-mainline/gcc/reorg.c (working copy)
@@ -2716,7 +2716,7 @@ fill_slots_from_thread (rtx insn, rtx co
if (!must_annul
(condition == const_true_rtx
|| (! insn_sets_resource_p (trial, opposite_needed, true)
- ! may_trap_or_fault_p (pat
+ ! may_trap_or_fault_p (pat) !RTX_FRAME_RELATED_P
(trial
{
old_trial = trial;
trial = try_split (pat, trial, 0);
...
AFAIU, the only thing causing problems is frame-related insns being speculated.
[Bug bootstrap/51572] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 13:34:09 UTC --- Original profilebootstrap fail is fixed (from looking at gcc-testresults).
[Bug bootstrap/51572] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 --- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 13:39:04 UTC --- Author: rguenth Date: Mon Dec 19 13:37:06 2011 New Revision: 182479 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182479 Log: 2011-12-19 Richard Guenther rguent...@suse.de PR lto/51572 * tree.c (free_lang_data_in_type): Do not unlink TYPE_DECL from TYPE_FIELDS. (find_decls_types_r): Walk TYPE_DECLs in TYPE_FIELDS. * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Do not stream TREE_CHAIN. (write_ts_type_non_common_tree_pointers): Stream TYPE_FIELDS using streamer_write_chain. * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers): Do not stream TREE_CHAIN. (lto_input_ts_type_non_common_tree_pointers): Stream TYPE_FIELDS using streamer_read_chain. * gimple-streamer-in.c (input_gimple_stmt): Skip non-FIELD_DECLs. * gimple.c (gimple_canonical_types_compatible_p): Properly handle trailing non-FIELD_DECLs in TYPE_FIELDS. * g++.dg/lto/pr51572-2_0.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/pr51572-2_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-streamer-in.c trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-streamer-in.c trunk/gcc/tree-streamer-out.c trunk/gcc/tree.c
[Bug tree-optimization/51600] [4.7 Regression] ice in estimate_local_effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51600
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
Component|c++ |tree-optimization
Target Milestone|--- |4.7.0
Summary|ice in |[4.7 Regression] ice in
|estimate_local_effects |estimate_local_effects
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19
13:44:41 UTC ---
templateclass T inline T min(T a, T b) { return a b ? a : b; }
double cornerbound(double *P, double (*m)(double, double))
{
double b=m(P[0],P[3]);
return m(b,P[12]);
}
void bound(double *P, double (*m)(double, double), double b)
{
m(b,cornerbound(P,m));
}
void bounds(double fuzz, unsigned maxdepth)
{
double Px[]={};
double bx=Px[0];
bound(Px,min,bx);
}
[Bug tree-optimization/51606] [4.7 Regression] FAIL: gcc.dg/vect/pr51015.c (internal compiler error) on ppc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51606 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 14:22:36 UTC --- Author: jakub Date: Mon Dec 19 14:22:29 2011 New Revision: 182480 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182480 Log: PR middle-end/51590 PR tree-optimization/51606 * tree-vect-patterns.c (append_pattern_def_seq, new_pattern_def_seq): New inline functions. (vect_recog_over_widening_pattern, vect_recog_vector_vector_shift_pattern, vect_recog_sdivmod_pow2_pattern, vect_recog_mixed_size_cond_pattern, adjust_bool_pattern_cast, vect_recog_bool_pattern): Use them. * gcc.dg/vect/pr51590.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr51590.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug middle-end/51590] [4.7 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51590 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 14:22:36 UTC --- Author: jakub Date: Mon Dec 19 14:22:29 2011 New Revision: 182480 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182480 Log: PR middle-end/51590 PR tree-optimization/51606 * tree-vect-patterns.c (append_pattern_def_seq, new_pattern_def_seq): New inline functions. (vect_recog_over_widening_pattern, vect_recog_vector_vector_shift_pattern, vect_recog_sdivmod_pow2_pattern, vect_recog_mixed_size_cond_pattern, adjust_bool_pattern_cast, vect_recog_bool_pattern): Use them. * gcc.dg/vect/pr51590.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr51590.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug tree-optimization/51596] [4.7 Regression] ICE: verify_flow_info failed: BB 6 can not throw but has an EH edge with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51596 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 14:24:34 UTC --- Author: jakub Date: Mon Dec 19 14:24:29 2011 New Revision: 182481 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182481 Log: PR tree-optimization/51596 * tree-cfg.c (replace_uses_by): Call gimple_purge_dead_eh_edges when needed. * g++.dg/opt/pr51596.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr51596.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug tree-optimization/51596] [4.7 Regression] ICE: verify_flow_info failed: BB 6 can not throw but has an EH edge with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51596 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 14:27:13 UTC --- Fixed.
[Bug middle-end/51590] [4.7 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51590 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 14:26:48 UTC --- Fixed.
[Bug c++/51328] [4.4/4.5/4.6/4.7 Regression] ICE on invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51328 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-19 14:29:44 UTC --- Well, rejects it a instantiation time. Thus I guess rejecting it earlier is fine, but we don't want to misled people by saying that 'typename T::~T' would be ok.
[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #4 from Domingo Alvarez mingodad at gmail dot com 2011-12-19 14:30:26 UTC --- Created attachment 26143 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26143 Another program to demonstrate gcc bad code generation On the previous example program my conclusions doesn't make much senes because gcc was optimizing the code and removing all code without side effects or in other words the small executables end up almost empty (good job of gcc). This new program contains the previous and add a program main2.c that when compiled without any optimization to not ending empty demonstrate the problem. Doing almost any arithmetic operations with _Decimal64 without mix with _Decimal128 or with automatic convertion to double gives an executable of 270KB. If we mix with _Decimal128 gives executable of 473KB. Now if we add a call to isnan the executable goes to 2.374KB, almost 2MB monolithic code only to isnan or even if we use ceil or floor or any other math functions, it seems too much for only a small adittion. And if I use a home made function to convert from _Decima64 to double there is now increase on executable size, but if using automatic generated conversion from gcc it grows to 2.374KB. I think that there is a problem with the way the _Decimal* library is coded, maybe all in one single code file instead of small ones with only one function, because with one function per code file adding a new function call will not link a lot of unnecessary code. gcc main2.c -o no-opt-small.exe - 270KB gcc -DWITH_GCC_DEC2DBL main2.c -o no-opt-gcc-dec2dbl.exe - 2.374KB gcc -DWITH_MIX128 main2.c -o no-opt-mix128.exe - 473KB gcc -DWITH_ISNAN main2.c -o no-opt-isnan.exe - 2.374KB gcc -DWITH_MIX128 -DWITH_ISNAN main2.c -o no-opt-isnan-mix128.exe - 2.578KB
[Bug tree-optimization/51583] One more missing force_gimple_operand in SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51583 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2011-12-19 14:33:21 UTC --- Author: jamborm Date: Mon Dec 19 14:33:18 2011 New Revision: 182483 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182483 Log: 2011-12-19 Martin Jambor mjam...@suse.cz PR tree-optimization/51583 * tree-sra.c (load_assign_lhs_subreplacements): Call force_gimple_operand_gsi when necessary also in case of no corresponding replacement on the RHS. * testsuite/gcc.dg/tree-ssa/pr51583.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr51583.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #5 from Domingo Alvarez mingodad at gmail dot com 2011-12-19 14:34:11 UTC --- (In reply to comment #2) Which architecture are you compiling for? gcc mingw32 4.6.1 32bits
[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 --- Comment #6 from Domingo Alvarez mingodad at gmail dot com 2011-12-19 14:40:45 UTC --- Rewrite expected executable sizes with a realistic better code generation by gcc. If code generation is solved probably we can have better results with the following: lua 5.1.4 with double - 150KB lua 5.1.4 with _Decimal64 - 2.4MB *with ***bad code generation lua 5.1.4 with _Decimal64 - 370KB *with hopefully ***good code generation sqlite3 with double - 500KB sqlite3 with _Decimal64 - 3MB *with ***bad code generation sqlite3 with _Decimal64 - 930KB *with hopefully ***good code generation The same proportion probably will apply to any other program using _Decimal* wich will make using _Decimal* a very interesting option.
[Bug c++/50012] [4.5/4.6/4.7 Regression] C++ front end misses -Wsign-compare warnings when extraneous parentheses are present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50012 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 14:43:05 UTC --- This has been introduced with http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01402.html which has been written as a better way of: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01393.html Perhaps the older patch is a better way than this one, which, if I understand it right, is that ignoring of the promotion at the -Wsign-compare handling spot? Setting TREE_NO_WARNING, at least until we have a way to say which warnings we want to prohibit and which should be kept, is an ugly hack and shouldn't be taken lightly. While Ian's patch doesn't set TREE_NO_WARNING in this testcase, it just disables the warning if any of the operands is TREE_NO_WARNING and uses this bit for yet another purpose. The TREE_NO_WARNING bit in this case is set by finish_parenthesized_expr: 1504 if (EXPR_P (expr)) 1505/* This inhibits warnings in c_common_truthvalue_conversion. */ 1506TREE_NO_WARNING (expr) = 1; So, what was wrong with the first approach? And, perhaps for 4.8 we want to turn TREE_NO_WARNING bit into a bit that just tells us whether that tree in question is in some hash table (see e.g. DECL_HAS_VALUE_EXPR_P etc.) and that hash table would contain details what warnings are we supposed to ignore. This isn't the only problematic spot.
[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 14:59:44 UTC --- Seems to me that you don't seem to understand what it means that the dfp support bits from libgcc.a are statically linked into your application. There is no bad code generation, the only problem is that libbid has lots of small *.o files, then about 7 mid size *.o files (~ 16KB to ~ 64KB of code, almost no .rodata) and then a single huge one - bid_binarydecimal.o - which, while it contains a tiny bit above 64KB of code, contains additionally 2MB of read-only data in various tables, and unfortunately this huge 6MB of source file is used by many of the routines. The reason why the decimal stuff isn't in libgcc_s (i.e. shared library) is because _Decimal* support is huge amount of code for something used extremely rarely. It could be either built into a separate shared library and ask people to add that library in, or perhaps this single huge source file could be split into several smaller ones, so you get only the code you really need to handle the operations you are using, or it could be built with -ffunction-sections -fdata-sections and allow people to use -Wl,--gc-sections to garbage collect it. OT, your comments about using _Decimal64 as an interesting option to double are very weird, the two types are completely different, have different purpose, _Decimal* is (except for some PowerPC and S390* chips) completely software emulated type and thus very slow, double has on the other side usually very fast operations on it implemented in hw.
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-19 15:30:29 UTC --- Author: burnus Date: Mon Dec 19 15:30:23 2011 New Revision: 182484 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182484 Log: 2011-12-19 Tobias Burnus bur...@net-b.de PR fortran/51605 * match.c (gfc_match_select_type): Handle scalar polymophic coarrays. (select_type_set_tmp, ): Ditto; avoid segfault if !class_ok. * primary.c (gfc_match_rvalue): Avoid segfault if !class_ok. * resolve.c (resolve_select_type): Ditto. (resolve_assoc_var): Fix setting the TARGET attribute for polymorphic selectors which are pointers. 2011-12-19 Tobias Burnus bur...@net-b.de PR fortran/51605 * gfortran.dg/select_type_25.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/select_type_25.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366
--- Comment #5 from Denis Excoffier g...@denis-excoffier.org 2011-12-19
15:31:46 UTC ---
Reduced test case is:
% cat exclude.c
int version;
int zz1(char *);
static void zz2(int flags)
{
static int initialized = 0;
char xx[4096];
if (initialized)
return;
initialized = 1;
zz2(flags | (version ? 2 : 0));
zz2(flags);
zz1(xx);
}
void zz3()
{
zz2(0);
}
% gcc -v -O -c exclude.c
Using built-in specs.
COLLECT_GCC=/tmp/lcl/uxl/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-201112
10/bin/../libexec/gcc/i686-pc-cygwin/4.7.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /tmp/lcl/tmp/gcc/gcc-4.7-20111210/configure
--prefix=/tmp/lcl/u
xl/gcc-4.7-20111210 --with-local-prefix=/usr/local/here
--enable-languages=c,c++
--disable-sjlj-exceptions
Thread model: single
gcc version 4.7.0 20111210 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-O' '-c' '-mtune=generic' '-march=pentiumpro'
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-20111210/bin/../libexec/g
cc/i686-pc-cygwin/4.7.0/cc1.exe -quiet -v -iprefix
/cygdrive/D/Home/dexcoff1/dex
coff1/cyglcl/uxl/gcc-4.7-20111210/bin/../lib/gcc/i686-pc-cygwin/4.7.0/
-D__CYGWI
N32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/../include/w32
api -idirafter ../../include/w32api exclude.c -quiet -dumpbase exclude.c
-mtune=
generic -march=pentiumpro -auxbase exclude -O -version -o /tmp/ccK5Dvq6.s
GNU C (GCC) version 4.7.0 20111210 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.0 20111210 (experimental), GMP version
5.0
.2, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gc
c-4.7-20111210/bin/../lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/in
clude
ignoring duplicate directory
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-
4.7-20111210/bin/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.7.0/include
ignoring nonexistent directory /usr/local/here/include
ignoring duplicate directory
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-
4.7-20111210/bin/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.7.0/include-fixed
ignoring nonexistent directory
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gc
c-4.7-20111210/bin/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.7.0/../../../../i68
6-pc-cygwin/include
ignoring nonexistent directory ../../include/w32api
#include ... search starts here:
#include ... search starts here:
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-20111210/bin/../lib/gcc/i686-pc-cygwin/4.7.0/include
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-20111210/bin/../lib/gcc/i686-pc-cygwin/4.7.0/include-fixed
/cygdrive/D/Home/dexcoff1/dexcoff1/cyglcl/uxl/gcc-4.7-20111210/bin/../lib/gcc/../../include
/usr/include
/usr/lib/../include/w32api
End of search list.
GNU C (GCC) version 4.7.0 20111210 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.0 20111210 (experimental), GMP version
5.0.2, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e4de487ff334f86f04bb7cab20aac91a
exclude.c: In function 'zz2':
exclude.c:14:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2244
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
%
[Bug c++/51619] [c++0x] [4.6/4.7 Regression] ICE with array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51619 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 15:38:09 UTC --- Author: jakub Date: Mon Dec 19 15:38:06 2011 New Revision: 182485 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182485 Log: PR c++/51619 * semantics.c (cxx_eval_vec_init_1): If init is NULL for multidimensional array, just set eltinit to NULL_TREE. * g++.dg/cpp0x/pr51619.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr51619.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/51623] New: PowerPC section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51623 Bug #: 51623 Summary: PowerPC section type conflict Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: clt...@gcc.gnu.org Target: powerpc-linux Created attachment 26144 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26144 Uboot nand_dump testcase gcc-patches discussion thread: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01240.html During final output of objects, existence of a .text.unlikely section triggers a section flag mismatch when looking up in the section htab. More information in mailing list thread, attached are testcases, a larger one from U-boot, and a very minimal one trying to demonstrate the fail. (for the minimal testcase, use -Os/-O2 -mrelocatable to trigger, for the Uboot one add -ffreestanding)
[Bug rtl-optimization/51623] PowerPC section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51623 --- Comment #1 from Chung-Lin Tang cltang at gcc dot gnu.org 2011-12-19 15:44:10 UTC --- Created attachment 26145 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26145 Minimal testcase
[Bug c++/51619] [c++0x] [4.6 Regression] ICE with array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51619 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[c++0x] [4.6/4.7|[c++0x] [4.6 Regression] |Regression] ICE with array |ICE with array class member |class member| --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 15:48:05 UTC --- Fixed on the trunk so far. On the branch the PR49924 changes look very different between trunk and 4.6, so I wonder what exactly to do. Perhaps guard the else if (!init) code with else if (!init TREE_CODE (elttype) != ARRAY_TYPE) instead?
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 --- Comment #11 from Dan Nagle danlnagle at me dot com 2011-12-19 15:51:40 UTC --- Hi, I can confirm that changing the label of the select type to integer_or_logical_or_error removes the ICE. I did so at lines 9325 and 13536 in the original source. The new label is a better description of the purpose of the select type anyway. Thanks, everyone! The new version of coco has some (I think anyway) good new features, and some older stuff removed, as per requests. So it's very good to have gfortran on the list of compilers known to work. The new coco is in testing now, but I hope to be able to distribute it RSN. On Dec 19, 2011, at 08:17 , burnus at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-19 13:17:15 UTC --- Dan: Your program should work (with 4.6.2 - or with 4.7 + my patch) if you either change either the SELECT TYPE label or the subroutine name from integer_or_logical to something else. * * * Reduced test case for the ICE: contains subroutine foo BLOCK_NAME: block end block BLOCK_NAME end subroutine foo subroutine BLOCK_NAME() end subroutine BLOCK_NAME subroutine bar() end subroutine bar end -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug tree-optimization/51580] [4.7 regression] segfault during loop vectorization at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51580 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 15:53:37 UTC --- Please recheck with current trunk - http://gcc.gnu.org/viewcvs?root=gccview=revrev=182480 or later.
[Bug lto/51573] [4.7 Regression] ICE (segfault) in lto_varpool_encoder_encode_initializer_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51573 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 15:57:25 UTC --- Fixed.
[Bug lto/51573] [4.7 Regression] ICE (segfault) in lto_varpool_encoder_encode_initializer_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51573 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-19 15:57:06 UTC --- Author: rguenth Date: Mon Dec 19 15:57:02 2011 New Revision: 182487 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182487 Log: 2011-12-19 Richard Guenther rguent...@suse.de PR lto/51573 * streamer-hooks.h (struct streamer_hooks): Add second ref_p parameter to write_tree. (stream_write_tree): Adjust. (stream_write_tree_shallow_non_ref): New define. * lto-streamer.h (lto_output_tree): Adjust. * lto-streamer-out.c (lto_output_tree): Likewise. * tree-streamer-out.c (streamer_write_chain): Only force the immediate tree to be streamed as non-reference. * gcc.dg/lto/20111207-2_0.c: Adjust. * g++.dg/lto/pr51573-1_0.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/pr51573-1_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/lto-streamer.h trunk/gcc/streamer-hooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/lto/20111207-2_0.c trunk/gcc/tree-streamer-out.c
[Bug c++/51328] [4.4/4.5/4.6/4.7 Regression] ICE on invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51328 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-12-19 15:58:13 UTC --- (In reply to comment #3) Thus I guess rejecting it earlier is fine, but we don't want to misled people by saying that 'typename T::~T' would be ok. Agreed. I would expect it to be straightforward to catch this at the point we currently give the misleading message.
[Bug tree-optimization/51600] [4.7 Regression] ice in estimate_local_effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51600 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2011-12-19 16:08:28 UTC --- Well, this means that estimate_ipcp_clone_size_and_time returns a negative size growth estimate. The function is basically inlining heuristics with special interface so perhaps such mishaps are to be expected and I should take care even of negative values (PR 51362 was about this function returning zero size growth estimates). Or are they not, Honza?
[Bug c++/51553] brace initialization and conversion operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51553 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-19 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-12-19 16:40:33 UTC --- --- Comment #25 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-16 20:05:16 UTC --- Can you try the patch in PR 51471#c11 ? That patch fixes most of the maybe_record_trace_start on mips* for me. The patch fixes the ICE in the i686-linux x mips-irix6.5 cross and allowed a native bootstrap to continue beyond the previous failure point. I'm now seeing an Ada ICE which is unrelated since it also just occured on the 4.6 branch. Rainer
[Bug tree-optimization/51583] One more missing force_gimple_operand in SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51583 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2011-12-19 16:47:35 UTC --- Author: jamborm Date: Mon Dec 19 16:47:28 2011 New Revision: 182488 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182488 Log: 2011-12-19 Martin Jambor mjam...@suse.cz PR tree-optimization/51583 * tree-sra.c (load_assign_lhs_subreplacements): Call force_gimple_operand_gsi when necessary also in case of no corresponding replacement on the RHS. * testsuite/gcc.dg/tree-ssa/pr51583.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr51583.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-sra.c
[Bug ada/51624] New: [4.6/4.7 regression] Assert_Failure atree.adb:808 on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51624 Bug #: 51624 Summary: [4.6/4.7 regression] Assert_Failure atree.adb:808 on IRIX 6.5 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: char...@gcc.gnu.org, ebotca...@gcc.gnu.org Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 Between 20111209 (r182157) and 20111216 (r182397), Ada bootstrap started to fail on IRIX 6.5 in stage 3: +===GNAT BUG DETECTED==+ | 4.6.3 20111216 (prerelease) [gcc-4_6-branch revision 182397] (mips-sgi-irix6.5) | | Assert_Failure atree.adb:794 | | Error detected at ali.adb:2008:45 When I apply the patch for PR bootstrap/50686 just suggested, I observe a similar ICE on mainline, too: +===GNAT BUG DETECTED==+ | 4.7.0 20111216 (experimental) [trunk revision 182408] (mips-sgi-irix6.5) | | Assert_Failure atree.adb:808 | | Error detected at a-exexda.adb:635:15 This suggests that a recent patch that has also been backported to the 4.6 branch is the culprit. Rainer
[Bug c++/51625] New: -Wconversion should be on by default, or at least included in -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51625
Bug #: 51625
Summary: -Wconversion should be on by default, or at least
included in -Wall
Classification: Unclassified
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: p...@podsnap.com
Sometime after 4.1.2, conversion errors stopped being reported by default, and
in fact don't even show up with -Wall and -Wextra. My opinion is that they
should be reported by default unless explicitly suppressed, but failing that,
at least they should be included in -Wall.
% cat boffo.C
#include math.h
#include stdlib.h
#include stdio.h
#include cmath
//using namespace std;
int main() {
double x = abs(3.5), y= fabs(3.5);
printf(%g %g\n,x,y);
return 0;
}
% # No warning in 4.2.2 or 4.4.2
% /sbcimp/run/pd/gcc/32-bit/4.2.2/bin/g++ -Wextra -Wall boffo.C
% /sbcimp/run/pd/gcc/32-bit/4.4.2/bin/g++ -Wextra -Wall boffo.C
% # 4.1.2 warns, even without any option -W flags
% /sbcimp/run/pd/gcc/32-bit/4.1.2/bin/g++ -Wextra -Wall boffo.C
boffo.C: In function 'int main()':
boffo.C:7: warning: passing 'double' for argument 1 to 'int abs(int)'
% /sbcimp/run/pd/gcc/32-bit/4.1.2/bin/g++ boffo.C
boffo.C: In function 'int main()':
boffo.C:7: warning: passing 'double' for argument 1 to 'int abs(int)'
# 4.2.2 and 4.4.2 warn correctly when -Wconversion turned on
% /sbcimp/run/pd/gcc/32-bit/4.2.2/bin/g++ -Wextra -Wall -Wconversion boffo.C
boffo.C: In function 'int main()':
boffo.C:7: warning: passing 'double' for argument 1 to 'int abs(int)'
% /sbcimp/run/pd/gcc/32-bit/4.4.2/bin/g++ -Wextra -Wall -Wconversion boffo.C
boffo.C: In function 'int main()':
boffo.C:7: warning: conversion to 'int' alters 'double' constant value
[Bug c++/51328] [4.4/4.5/4.6/4.7 Regression] ICE on invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51328 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-19 17:22:24 UTC --- Ok thanks. I can do this.
[Bug target/48743] -march=native mis-detects AMD K6-2+ / K6-3 as Athlon - compiled C fails with illegal instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743 --- Comment #6 from Quentin Neill qneill at gcc dot gnu.org 2011-12-19 17:57:42 UTC --- Author: qneill Date: Mon Dec 19 17:57:32 2011 New Revision: 182489 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182489 Log: 2011-12-19 Quentin Neill quentin.ne...@amd.com 2011-12-19 Quentin Neill quentin.ne...@amd.com PR target/48743 * config/i386/driver-i386.c (host_detect_local_cpu): Also check family to distinguish PROCESSOR_ATHLON. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/driver-i386.c
[Bug libstdc++/51626] New: [4.6 Regression] [C++0x] can't use C++98 allocators with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51626
Bug #: 51626
Summary: [4.6 Regression] [C++0x] can't use C++98 allocators
with -std=c++0x
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
#include memory
#include vector
template class T
struct allocator98 : std::allocatorT
{
template class U struct rebind { typedef allocator98U other; };
allocator98() { }
template class U allocator98(const allocator98U) { };
void construct(T* p, const T val) { std::allocatorT::construct(p, val);
}
};
int main()
{
std::vector int, allocator98int v(1);
}
This fails in c++0x mode because std::__uninitialized_default_n_a() incorrectly
assumes it's OK to call Alloc::construct with a single argument. That is true
for std::allocator in C++0x mode, but not true for most user-defined allocators
written to the C++98 requirements.
This is the cause of https://svn.boost.org/trac/boost/ticket/5538
The bug is fixed in 4.7 because std::allocator_traits provides a default
implementation of construct, ensuring backwards-compatibility with C++98-style
allocators.
A workaround for user-defined allocators is to add:
void construct(pointer p) { return construct(p, value_type()); }
The fix for libstdc++ would be to avoid calling construct with a single
argument, or to backport a minimal version of allocator_traits from 4.7
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 --- Comment #4 from Steve Ellcey sje at cup dot hp.com 2011-12-19 18:33:07 UTC --- Yes, this was failing on ia64 hpux as well as hppa hpux.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 18:34:16 UTC --- I believe this is just because of very weird target avr stuff, either it is a target bug that can be fixed up in the backend somehow, or perhaps would need some middle-end help, but still it is avr specific. Doesn't seem to have anything to do with PR49330. The problem seems to be that the prologue here looks like: (insn/f 43 7 44 2 (set (mem/c:QI (post_dec:HI (reg/f:HI 32 __SP_L__)) [5 S1 A8]) (reg:QI 28 r28)) pr50063.c:9 -1 (nil)) (insn/f 44 43 45 2 (set (mem/c:QI (post_dec:HI (reg/f:HI 32 __SP_L__)) [5 S1 A8]) (reg:QI 29 r29)) pr50063.c:9 -1 (expr_list:REG_DEAD (reg:QI 29 r29) (nil))) (insn 45 44 46 2 (set (reg/f:HI 28 r28) (reg/f:HI 32 __SP_L__)) pr50063.c:9 -1 (nil)) (insn/f 46 45 47 2 (set (reg/f:HI 28 r28) (plus:HI (reg/f:HI 28 r28) (const_int -12 [0xfff4]))) pr50063.c:9 -1 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:HI 28 r28) (plus:HI (reg/f:HI 32 __SP_L__) (const_int -12 [0xfff4]))) (nil))) (insn 47 46 48 2 (set (reg/f:HI 32 __SP_L__) (reg/f:HI 28 r28)) pr50063.c:9 -1 (nil)) where reg 28 is frame pointer and reg 32 is stack pointer. When canon_true_dependence is called by DSE, one of the mem addresses is r28 plus CONST_INT, the other is a VALUE, which is in the end a VALUE of r28 plus some offset. But r28 (frame pointer) and r32 (stack pointer) have the same VALUE in this case, and because of the initialization of sp from fp r32 is actually before r28 in that VALUE's locs list. So, find_base_term for that VALUE returns (address r32), while find_base_term for r28 plus CONST_INT doesn't use cselib values at all and thus returns (address r28) and base_alias_check just fails. The question is why avr does this, and if it really has to do that, it should make sure somehow that for the alias analysis either REG_BASE_VALUE of r28 is the same as REG_BASE_VALUE of r32. E.g. it could define FIND_BASE_TERM and do something for r28/r32 if they are known to be the same. init_alias_analysis ignores prologue and epilogue insns after reload, which is probably why record_set isn't called here on the r32 = r28 set.
[Bug libstdc++/51626] [4.6 Regression] [C++0x] can't use C++98 allocators with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51626 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-19 18:38:56 UTC --- Bah, in my opinion it's late to attempt sophisticated things in 4.6, either we can do something minimal or we should just tell people that in 4.6 a C++0x container wants a C++0x allocator.
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605
--- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-19
18:41:24 UTC ---
(In reply to comment #9)
subroutine foo
BLOCK_NAME: block
end block BLOCK_NAME
end subroutine foo
subroutine BLOCK_NAME()
end subroutine BLOCK_NAME
The problem is the call to gfc_fixup_sibling_symbols which finds in
subroutine foo the symbol block_name (FL_LABEL) - and overrides it with the
subroutine (FL_PROCEDURE).
The source code has:
/* By 14.6.1.3, host association should be excluded
for the following. */
I think it missed F95's
(13) The name of a named construct
Patch:
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -3908,6 +3908,7 @@ gfc_fixup_sibling_symbols (gfc_symbol *sym, gfc_namespace
*siblings)
|| old_sym-attr.intrinsic
|| old_sym-attr.generic
|| old_sym-attr.flavor == FL_NAMELIST
+ || old_sym-attr.flavor == FL_LABEL
|| old_sym-attr.proc == PROC_ST_FUNCTION))
{
/* Replace it with the symbol from the parent namespace. */
[Bug target/48743] -march=native mis-detects AMD K6-2+ / K6-3 as Athlon - compiled C fails with illegal instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743 Quentin Neill qneill at gcc dot gnu.org changed: What|Removed |Added CC||qneill at gcc dot gnu.org --- Comment #7 from Quentin Neill qneill at gcc dot gnu.org 2011-12-19 18:55:49 UTC --- Waiting to fix in 4.5 and 4.6 per Uros: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00938.html Meanwhile, fixed in trunk (4.7) after testing on amdfam10 and bdver1: Author: qneill Date: Mon Dec 19 17:57:32 2011 New Revision: 182489 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182489 Log: 2011-12-19 Quentin Neill quentin.ne...@amd.com 2011-12-19 Quentin Neill quentin.ne...@amd.com PR target/48743 * config/i386/driver-i386.c (host_detect_local_cpu): Also check family to distinguish PROCESSOR_ATHLON. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/driver-i386.c
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #13 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-12-19 18:56:49 UTC --- (In reply to comment #12) I believe this is just because of very weird target avr stuff, either it is a target bug that can be fixed up in the backend somehow, or perhaps would need some middle-end help, but still it is avr specific. The insns describe exactly what the machine is doing: insn 43/44: Save FP (r28/29) to Stack. This in done in two QI pushes and not in one HI. SP push is post-decrement and with a HI push the resulting address would be wrong. AVR is 8-bit machine with 16-bit PMODE. insn 45: Initialize FP with SP insn 46: Set up a frame (12 bytes here). AVR's SP cannot be changed directly, not even atomically so changing SP is quite expensive and IRQs must be turned off. Therefore, prologue generation works out two methods of setting up frame/changing SP and picks the most efficient: * For big offsets it is: FP = SP; FP -= const; SP = FP * For small offsets SP is adjusted by dummy pushes/pops, for example: SP -= 2 as of: push(dummy); push(dummy); FP = SP Similar applies to epilogue generation. This example exercises the first approach. The 3rd step is (SP = FP): insn 47: Write back SP If the generic analysis ignores prologue/epilogue but optimizers optimize against prologue/epilogue using that incorrect information based on lazy analysis, then the problem is in generic code.
[Bug libstdc++/51626] [4.6 Regression] [C++0x] can't use C++98 allocators with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51626 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 18:57:45 UTC --- I agree with the sentiment, but unfortunately a C++11 allocator isn't required to provide a construct member at all. 17.6.3.5 p5 shows a minimal C++11 allocator, and that won't work either, so 4.6 doesn't correctly support user-defined C++98 allocators or user-defined C++11 allocators! I think the minimal fix is for __uninitialized_default_n_a and __uninitialized_default_a to default construct an object of the iterator's value_type and pass that to __alloc.construct(addressof(*cur)) A less-minimal fix would be to change all the containers to use __uninitialized_fill_a instead of __uninitialized_default_a
[Bug libstdc++/51626] [4.6 Regression] [C++0x] can't use C++98 allocators with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51626 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 19:04:53 UTC --- Unfortunately either of those would cause a regression for PR 32618
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P4 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 19:12:56 UTC --- Well, it is certainly desirable not to process the prologue insns during init_alias_analysis. The fact that stack pointer has the same value as frame pointer after the prologue is not usual and something the generic code isn't prepared for (usually either frame pointer is eliminated (of course then the register can be used for something else) or frame pointer is initialized from stack pointer and then decremented (or incremented) still inside of the prologue). So you need to tell the alias analysis about that, as the prologue isn't scanned, it is the backend responsibility to tell that.
