[Bug pch/47430] New: [4.6 Regression] Random PCH related bootstrap failures on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47430 Summary: [4.6 Regression] Random PCH related bootstrap failures on powerpc64-linux Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: b...@gcc.gnu.org, pa...@gcc.gnu.org I saw during the weekend two bootstrap failures in libstdc++. The problem seems to be that powerpc64 uses very large pages (64KB), address space randomization and the fact that for building stdtr1c++.h.gch and extc++.h.gch uses stdc++.h.gch. When building e.g. stdtr1c++.h.gch, stdc++.h.gch already likely exists and thus it first mmaps stdc++.h.gch at the desired address, which is likely TRY_EMPTY_VM_SPACE (OT, for __powerpc__ __LP64__, shouldn't it use some larger value, say 0x60ULL ?), thus when attempting to determine best VM slot for stdtr1c++.h.gch, that slot is already taken by stdc++.h.gch and thus can't be used. While there is some code to attempt to handle address space randomization, perhaps 32MB works well for 4KB pages, but is too small for larger pages or something, but it certainly fails from time to time on ppc64 and some shared library is mmapped at that point. Potential ways how to fix this, one or more of: 1) in host-linux.c define more than one TRY_EMPTY_VM_SPACE value for each OS, and if mmap at TRY_EMPTY_VM_SPACE fails, try TRY_EMPTY_VM_SPACE2 which is say 0x7000 for most 32-bit hosts and some GB appart from TRY_EMPTY_VM_SPACE for 64-bit hosts. 2) make sure other PCH is not read during compilation that is writing PCH 3) change the logic for address space randomization in host-linux.c, use larger buffer if page size is 4KB 4) change libstdc++ makefiles to make sure stdc++.h.gch does not exist when building the other *.gch files, use explicit ordering in the Makefile that it is first rm -f'ed, then the other gch files built, then stdc++.h.gch built Preferences?
[Bug pch/47430] [4.6 Regression] Random PCH related bootstrap failures on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47430 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug pch/47430] [4.6 Regression] Random PCH related bootstrap failures on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47430 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 08:51:53 UTC --- 3) might be too hard, at least on RHEL6/ppc64 the randomization of mmap has difference between smallest and largest address for one mmap is almost 1GB in a few attempts I've done (0xfff7911 to 0xfffb501). BTW, the fatal_error (had to relocate PCH); doesn't print, but instead segfaults, as line_map seems to be in some weird state prepared for the PCH read already at that point, thus it is pointing into the new PCH slot already.
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 Thomas thenlich at users dot sourceforge.net changed: What|Removed |Added CC||thenlich at users dot ||sourceforge.net --- Comment #5 from Thomas thenlich at users dot sourceforge.net 2011-01-24 08:53:10 UTC --- Even a partial, incomplete support of module IEEE_ARITHMETIC would be very useful and much appreciated: From http://gcc.gnu.org/ml/gcc/2008-11/msg00372.html a) To set an IEEE value (NaN, INF, etc.) b) Check whether a value is NaN, etc. and IEEE_VALUE(X, IEEE_QUIET_NAN) So we wouldn't have to resort to non-standard functions like ISNAN() (http://gcc.gnu.org/onlinedocs/gfortran/ISNAN.html) anymore.
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810
--- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr
2011-01-24 09:29:00 UTC ---
I have regtested my working tree (with other patches) with the patch in comment
#15 and got 180 new failures (likely 90 for both -m32 and -m64), but I have not
checked that carefully).
Among them, 124 are of the kind scan-tree-dump-times fre *: dump file does not
exist and seem to be due to the extra pass producing fre1 and fre2. I can
adjust the test for say fre2 and see what's happening.
Then I see
FAIL: gcc.dg/ipa/ipa-pta-14.c scan-ipa-dump pta foo.result = { NULL a[^ ]* a[^
]* c[^ ]* }
FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times matrix-reorg Flattened 3
dimensions 1
FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times matrix-reorg Flattened 2
dimensions 1
FAIL: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times matrix-reorg Flattened 2
dimensions 1
FAIL: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times matrix-reorg Flattened 2
dimensions 1
FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times matrix-reorg Flattened 3
dimensions 1
FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times matrix-reorg Transposed
3
FAIL: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times matrix-reorg Flattened 3
dimensions 1
FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times matrix-reorg Flattened 2
dimensions 1
FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times matrix-reorg Transposed
2
FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times matrix-reorg Flattened 3
dimensions 1
FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times matrix-reorg Transposed
2
FAIL: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times matrix-reorg Flattened 3
dimensions 1
FAIL: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times matrix-reorg Flattened 3
dimensions 1
FAIL: gcc.dg/torture/pta-structcopy-1.c -O2 scan-tree-dump alias points-to
vars: { i }
FAIL: gcc.dg/torture/pta-structcopy-1.c -O3 -fomit-frame-pointer
scan-tree-dump alias points-to vars: { i }
FAIL: gcc.dg/torture/pta-structcopy-1.c -O3 -g scan-tree-dump alias
points-to vars: { i }
FAIL: gcc.dg/torture/pta-structcopy-1.c -Os scan-tree-dump alias points-to
vars: { i }
FAIL: gcc.dg/torture/pta-structcopy-1.c -O2 -flto -flto-partition=none
scan-tree-dump alias points-to vars: { i }
FAIL: gcc.dg/torture/pta-structcopy-1.c -O2 -flto scan-tree-dump alias
points-to vars: { i }
FAIL: gcc.dg/tree-ssa/pta-ptrarith-1.c scan-tree-dump ealias q_., points-to
vars: { k }
FAIL: gcc.dg/tree-ssa/sra-9.c scan-tree-dump-times optimized = s.b 0
FAIL: gcc.dg/tree-ssa/ssa-dce-4.c scan-tree-dump-times cddce1 a\[[^
FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump stdarg f6: va_list escapes 0,
needs to save (3|12|24) GPR units
FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump stdarg f11: va_list escapes 0,
needs to save (3|12|24) GPR units
FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump stdarg f12: va_list escapes 0,
needs to save [1-9][0-9]* GPR units
FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump stdarg f13: va_list escapes 0,
needs to save [1-9][0-9]* GPR units
FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump stdarg f14: va_list escapes 0,
needs to save [1-9][0-9]* GPR units
FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline String::funcOne[^\n]*inline
copy in int main
FAIL: g++.dg/ipa/iinline-2.C scan-ipa-dump inline String::funcOne[^\n]*inline
copy in int main
So far I have only looked at gcc.dg/ipa/ipa-pta-14.c, for which grepping
foo.result yields
p_1 = foo.result
foo.result = foo.arg1
Equivalence classes for Direct node node id 15:foo.result are pointer: 8,
location:0
Unifying foo.result to foo.arg0
foo.result = { a.0+32 } same as foo.arg0
instead of
p_1 = foo.result
foo.result = D.2736_3
Equivalence classes for Direct node node id 15:foo.result are pointer: 13,
location:0
Unifying foo.result to p_1
foo.result = { NULL a.0+32 a.64+64 c.0+32 } same as p_1
Is it a missed optimization or wrong-code?
[Bug testsuite/45988] gfortran.dg/vect/fast-math-pr38968.f90 times out on 32-bit Solaris 10/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45988 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-01-24 09:30:39 UTC --- Author: ro Date: Mon Jan 24 09:30:31 2011 New Revision: 169153 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169153 Log: * gfortran.dg/array_constructor_33.f90: Use dg-timeout-factor 4. PR testsuite/45988 * gfortran.dg/vect/fast-math-pr38968.f90: Use dg-timeout-factor 2. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/array_constructor_33.f90 trunk/gcc/testsuite/gfortran.dg/vect/fast-math-pr38968.f90
[Bug testsuite/45988] gfortran.dg/vect/fast-math-pr38968.f90 times out on 32-bit Solaris 10/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45988 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg01234.htm ||l Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-01-24 09:41:22 UTC --- Fixed for 4.6.0.
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #37 from rguenther at suse dot de rguenther at suse dot de 2011-01-24 09:41:28 UTC --- On Fri, 21 Jan 2011, mikael at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #36 from Mikael Morin mikael at gcc dot gnu.org 2011-01-21 22:54:53 UTC --- (In reply to comment #34) Yep, that's what I figured eventually :) The question now is if for: -- type bar integer :: a end type bar type(bar), pointer :: b type(bar) :: c -- 'b' and 'c' should have the same type. In other words should type(bar),pointer be a different type vs type(bar) already in the frontend representation for types, or not? If they would be they wouldn't have shared components and we would be free to set attributes as we like. Not knowing much about the several engineering decisions taken while developing the frontend _I_ personally would have done it this way. Alas, no cake for me :) Well, the current scheme is in line with how the standard is meant: entities of the same type can have or not the target attribute; in other words attributes are orthogonal to the type. This doesn't fit the middle-end but having it fit the middle-end would lead to the reverse problem : every time we find two objects of different type, we would have to look for variants to check if the objects are indeed of different type or only of different variants (and thus compatible). Personally, I would put the fix in the middle-end (which doesn't mean there is nothing to do on the front-end side). Instead of having the C type-compatibility rules hardcoded in the middle-end, have some relaxed rules: two objects are type-compatible iff all of their sub-components are type compatible. That's what we do ;) And void * restrict is not compatible with void *. So you get the ICE. Richard.
[Bug tree-optimization/47411] [4.5 Regression] Bootstrap failure on x86-64/Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED AssignedTo|rguenther at suse dot de|rguenth at gcc dot gnu.org Target Milestone|--- |4.5.3 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-24 09:43:17 UTC --- Mine.
[Bug c/47428] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in copy_phis_for_bb, at tree-inline.c:1986
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47428 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 09:45:47 UTC --- Guess it is related to the implicit declaration of func_106 and too few parameters passed to it. Looking...
[Bug libfortran/47431] New: ctime() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47431 Summary: ctime() not thread-safe Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org In libgfortran/intrinsics/ctime.c we call the POSIX ctime() function, which need not be thread safe. Instead, we should use ctime_r() if available.
[Bug libfortran/47431] ctime() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47431 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.24 09:55:30 AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug libfortran/47432] New: ttyname() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432 Summary: ttyname() not thread-safe Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org In libgfortran/io/unix.c we call the POSIX ttyname() function, which need not be thread-safe. Instead we should call ttyname_r(), if available.
[Bug libfortran/47432] ttyname() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.24 09:57:38 AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug debug/45124] No DW_AT_accessibility for public DIEs in DW_TAG_class_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45124 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added CC||jan.kratochvil at redhat ||dot com --- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-01-24 10:41:17 UTC --- DWARF3 leaves the meaning for struct/union unspecified: An inheritance entry may have a DW_AT_accessibility attribute. If no accessibility attribute is present, private access is assumed for an entry of a class and public access is assumed for an entry of an interface. DWARF4 specifies: An inheritance entry may have a DW_AT_accessibility attribute. If no accessibility attribute is present, private access is assumed for an entry of a class and public access is assumed for an entry of an interface, struct or union. DWARF2 had: An inheritance entry may have a DW_AT_accessibility attribute. If no accessibility attribute is present, private access is assumed. So I guess DWARF3 was meant like what DWARF4 says and GDB should be changed for both DWARF3 and DWARF4.
[Bug tree-optimization/47428] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in copy_phis_for_bb, at tree-inline.c:1986
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47428 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 #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 11:13:17 UTC --- Created attachment 23095 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23095 gcc46-pr47428.patch Untested fix.
[Bug libstdc++/47433] New: libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 Summary: libstdc++ parallel mode calls std::swap explicitely Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: manuel.holtgr...@fu-berlin.de The parallel libstdc++ calls std::swap explicitely. To my knowledge, this disables the user to specify his own, possibly more efficient swap routine. This is especially severe in parallel sorting and partitioning. libstdc++-v3-parallel-trunk $ ack 'std::swap' balanced_quicksort.h 135:std::swap(*__pivot_pos, *(__end - 1)); 147: std::swap(*(__begin + __split_pos), *__pivot_pos); 287:std::swap(*__pivot_pos, *(__end - 1)); 306:std::swap(*__split_pos1, *__pivot_pos); losertree.h 237:std::swap(_M_losers[__pos]._M_sup, __sup); 238:std::swap(_M_losers[__pos]._M_source, __source); 239:std::swap(_M_losers[__pos]._M_key, __key); 333:std::swap(_M_losers[__pos]._M_sup, __sup); 334:std::swap(_M_losers[__pos]._M_source, __source); 335:std::swap(_M_losers[__pos]._M_key, __key); 464:std::swap(_M_losers[__pos]._M_sup, __sup); 465:std::swap(_M_losers[__pos]._M_source, __source); 466:std::swap(_M_losers[__pos]._M_keyp, __keyp); 541:std::swap(_M_losers[__pos]._M_sup, __sup); 542:std::swap(_M_losers[__pos]._M_source, __source); 543:std::swap(_M_losers[__pos]._M_keyp, __keyp); 697:std::swap(_M_losers[__pos]._M_source, __source); 698:std::swap(_M_losers[__pos]._M_key, __key); 788:std::swap(_M_losers[__pos]._M_source, __source); 789:std::swap(_M_losers[__pos]._M_key, __key); 937:std::swap(_M_losers[__pos]._M_source, __source); 938:std::swap(_M_losers[__pos]._M_keyp, __keyp); 1027:std::swap(_M_losers[__pos]._M_source, __source); 1028:std::swap(_M_losers[__pos]._M_keyp, __keyp); partition.h 181: std::swap(__begin[__thread_left], 241: std::swap_ranges(__begin + __thread_left_border 264: std::swap_ranges(__begin + __thread_right_border, 304:std::swap(__begin[__final_left], __begin[__final_right]); 357:std::swap(*__pivot_pos, *(__end - 1)); 379:std::swap(*__split_pos1, *__pivot_pos);
[Bug c++/45940] [trans-mem] Error of unsafe function even if annotated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45940 --- Comment #16 from Vincent Gramoli vincent.gramoli at epfl dot ch 2011-01-24 12:04:37 UTC --- Hi Aldy, The bug does you refer to does not seem to be assigned to anyone. Vincent On Jan 20, 2011, at 3:31 PM, aldyh at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45940 --- Comment #14 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-01-20 14:30:50 UTC --- Vincent, this is bug 47340. I will be looking at this today. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.24 12:12:09 CC||paolo.carlini at oracle dot ||com, singler at kit dot edu Ever Confirmed|0 |1 Severity|critical|normal --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-24 12:12:09 UTC --- Johannes, do you have an opinion about this? Otherwise, I'll simply go ahead and do the change.
[Bug c/47427] [4.6 Regression] ICE in process_constraint, at tree-ssa-structalias.c:2901
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47427 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 12:50:47 UTC --- I think this is pretty much the same issue as PR47428, except in this case it is not a PHI in which such a replacement is made, but for y_9 = 0; given that y is argument declared const the inliner replaces it with 1 = 0;. So perhaps the PR47428 patch isn't the right fix. The reason why y_9 is on the LHS of a set is copyrename. I guess a fix could be either not doing copyrename if an SSA_NAME of a TREE_READONLY var would be on the LHS of an assignment or result of a PHI, or drop the TREE_READONLY from the parameter in such a case (but that would result in us dropping such info in debug info), or avoid the optimization /* If the parameter is never assigned to, has no SSA_NAMEs created, we would not need to create a new variable here at all, if it weren't for debug info. Still, we can just use the argument value. */ if (TREE_READONLY (p) ... in setup_one_parameter. Richard/Honza, what do you think?
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-24 12:52:30 UTC --- Note: std::swap_ranges is fine, AFAICS.
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #3 from Manuel Holtgrewe manuel.holtgr...@fu-berlin.de 2011-01-24 12:56:16 UTC --- I agree, that there are no obvious problems with std::swap_ranges. Is anything specified in the standard in this direction?
[Bug libfortran/47434] New: Wrong field width for NaN with (F0.n) formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434 Summary: Wrong field width for NaN with (F0.n) formatting Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net When formatting NaN with a F edit descriptor where the field width is zero, the string blankNaN is written (field width = 4). The expected string would be NaN (field width = 3, the smallest positive actual field width that does not result in a field filled with asterisks). For example: program testnan real :: n = 0.0 n = 0.0 / n print (F0.2), n print (F3.2), n end program testnan Output: blankNaN NaN 10.7.2.1 (6) On output, with I, B, O, Z, F, and G editing, the specified value of the field width w may be zero. In such cases, the processor selects the smallest positive actual field width that does not result in a field filled with asterisks. The specified value of w shall not be zero on input. 10.7.2.3.2 F editing For an internal value that is an IEEE NaN, the output field consists of blanks, if necessary, followed by the letters 'NaN' and optionally followed by one to w - 5 alphanumeric processor-dependent characters enclosed in parentheses, right justified within the field. If w is less than 3, the field is filled with asterisks.
[Bug c/47427] [4.6 Regression] ICE in process_constraint, at tree-ssa-structalias.c:2901
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47427 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de 2011-01-24 12:59:58 UTC --- On Mon, 24 Jan 2011, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47427 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 12:50:47 UTC --- I think this is pretty much the same issue as PR47428, except in this case it is not a PHI in which such a replacement is made, but for y_9 = 0; given that y is argument declared const the inliner replaces it with 1 = 0;. So perhaps the PR47428 patch isn't the right fix. copyrename shouldn't do this (coalesce to TREE_READONLY vars - it also doesn't seem to not coalesce to TREE_THIS_VOLATILE vars, though those shouldn't be in SSA form). The reason why y_9 is on the LHS of a set is copyrename. I guess a fix could be either not doing copyrename if an SSA_NAME of a TREE_READONLY var would be on the LHS of an assignment or result of a PHI, or drop the TREE_READONLY from the parameter in such a case (but that would result in us dropping such info in debug info), or avoid the optimization /* If the parameter is never assigned to, has no SSA_NAMEs created, we would not need to create a new variable here at all, if it weren't for debug info. Still, we can just use the argument value. */ if (TREE_READONLY (p) ... in setup_one_parameter. Richard/Honza, what do you think? Fix copyrename. Richard.
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-24 13:10:43 UTC --- I don't think it is. I can double check later. Also, in losertree.h most uses involve built-in types (like bool or int) or pointers, and those are also fine. Beyond the issue discussed here, however, I'm not sure to understand the logic behind the __delete_min_insert members taking _Tp by *value* instead of constant ref. Johannes, are we sure we want those copies?
[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.24 13:12:19 CC||jvdelisle at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-01-24 13:12:19 UTC --- I will investigate.
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #5 from Johannes Singler singler at kit dot edu 2011-01-24 13:19:22 UTC --- What are you proposing for a fix? Omitting std::? Using std::iter_swap where appropriate, like stl_algo.h mostly does? The latter would be more consistent. Johannes
[Bug rtl-optimization/47389] ICE: in calc_dfs_tree, at dominance.c:395 with -fno-combine-stack-adjustments -fno-dse -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47389 --- Comment #4 from Zdenek Sojka zsojka at seznam dot cz 2011-01-24 13:21:50 UTC --- Created attachment 23096 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23096 short C testcase $ gcc -O -fno-combine-stack-adjustments -fno-dse -fno-guess-branch-probability -foptimize-sibling-calls testcase.c testcase.c: In function 'foo': testcase.c:15:1: internal compiler error: in calc_dfs_tree, at dominance.c:395 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Backtrace is similiar to the one in comment #0: (gdb) bt #0 fancy_abort (file=0x10d3be8 /mnt/svn/gcc-trunk/gcc/dominance.c, line=395, function=0x10d3ca5 calc_dfs_tree) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892 #1 0x006350d3 in calc_dfs_tree (di=0x7fffd4a0, reverse=0 '\000') at /mnt/svn/gcc-trunk/gcc/dominance.c:395 #2 0x006369e0 in calculate_dominance_info (dir=CDI_DOMINATORS) at /mnt/svn/gcc-trunk/gcc/dominance.c:656 #3 0x005eccad in flow_loops_find (loops=0x75d3bc60) at /mnt/svn/gcc-trunk/gcc/cfgloop.c:386 #4 0x007aa7ef in loop_optimizer_init (flags=16) at /mnt/svn/gcc-trunk/gcc/loop-init.c:52 #5 0x00fe7546 in if_convert () at /mnt/svn/gcc-trunk/gcc/ifcvt.c:4241 #6 0x00fe8fe9 in rest_of_handle_if_after_reload () at /mnt/svn/gcc-trunk/gcc/ifcvt.c:4418 #7 0x007f1ba6 in execute_one_pass (pass=0x1610400) at /mnt/svn/gcc-trunk/gcc/passes.c:1562 #8 0x007f1ea5 in execute_pass_list (pass=0x1610400) at /mnt/svn/gcc-trunk/gcc/passes.c:1617 #9 0x007f1eb7 in execute_pass_list (pass=0x160ae40) at /mnt/svn/gcc-trunk/gcc/passes.c:1618 #10 0x007f1eb7 in execute_pass_list (pass=0x160aea0) at /mnt/svn/gcc-trunk/gcc/passes.c:1618 #11 0x009341a6 in tree_rest_of_compilation (fndecl=0x75d4a000) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #12 0x00afa9a2 in cgraph_expand_function (node=0x75d4d000) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1522 #13 0x00afd06a in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1581 #14 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1841 #15 0x00afd5ea in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1042 #16 0x0050585c in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9843 #17 0x008dd544 in compile_file (argc=17, argv=0x7fffda18) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #18 do_compile (argc=17, argv=0x7fffda18) at /mnt/svn/gcc-trunk/gcc/toplev.c:1874 #19 toplev_main (argc=17, argv=0x7fffda18) at /mnt/svn/gcc-trunk/gcc/toplev.c:1937 #20 0x765f1bbd in __libc_start_main () from /lib/libc.so.6 #21 0x004ec455 in _start ()
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #6 from Johannes Singler singler at kit dot edu 2011-01-24 13:23:26 UTC --- Taking __key as value type in (some variants of __delete_min_insert) makes sense, since it is also used as a buffer for storing the current loser. Having a local variable that is initialized with the const ref would have the same effect, would it not? Johannes
[Bug c++/47429] -Wfatal-errors hiding line number of offending caller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47429 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.24 13:26:01 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-01-24 13:26:01 UTC --- This is an old bug but I cannot find it in bugzilla. There are several issues: * GCC doesn't have the concept of multi-line diagnostic, each line is independent. That is, we cannot do error(this is one line.\nThis is another). This is not difficult to implement but it is long and tedious. * GCC cannot build a single diagnostic that expands several lines from individual calls. That is, we cannot do Diagnostic diag; diag.error(‘int Blah::test’ is private); diag.note(within this context) diag.report(); This is much harder (and ugly) to solve in C. I am not sure about the status of Clang/LLVM with respect to this. Last time I looked their diagnostic machinery was too strongly based on GCC's so they suffered the same problem, but there have been loads of changes since then, so perhaps they fixed it already.
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-24 13:28:28 UTC --- For sure if we are swapping _Tps we have to omit the std::. In general, when we are not swapping built-ins or pointers we have to omit the qualification or use something else, like std::swap_ranges (which eventually calls unqualified swap anyway). Please let me know which are your plans Johannes and let's resolve this issue of 4.6.0, we don't have much time...
[Bug c/47435] New: [4.6 Regression] ICE: SIGSEGV in c_finish_case (c-typeck.c:8859) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47435 Summary: [4.6 Regression] ICE: SIGSEGV in c_finish_case (c-typeck.c:8859) on invalid code Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 23097 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23097 reduced testcase Compiler output: $ gcc testcase.c testcase.c: In function 'foo': testcase.c:5:5: error: a label can only be part of a statement and a declaration is not a statement testcase.c:5:5: error: unknown type name 'x' testcase.c:6:3: error: expected '=', ',', ';', 'asm' or '__attribute__' before '}' token testcase.c:4:5: error: label at end of compound statement ==28038== Invalid read of size 8 ==28038==at 0x513058: c_finish_case (c-typeck.c:8859) ==28038==by 0x535EF4: c_parser_statement_after_labels (c-parser.c:4626) ==28038==by 0x5372A7: c_parser_compound_statement_nostart (c-parser.c:4109) ==28038==by 0x538838: c_parser_compound_statement (c-parser.c:3946) ==28038==by 0x534F0A: c_parser_declaration_or_fndef (c-parser.c:1719) ==28038==by 0x539F8D: c_parser_external_declaration (c-parser.c:1332) ==28038==by 0x53AB67: c_parse_file (c-parser.c:1220) ==28038==by 0x574804: c_common_parse_file (c-opts.c:1071) ==28038==by 0x8DD507: toplev_main (toplev.c:579) ==28038==by 0x62FEBBC: (below main) (in /lib64/libc-2.11.2.so) ==28038== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==28038== testcase.c:6:3: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Output - 4.5: $ gcc testcase.c testcase.c: In function 'foo': testcase.c:5:5: error: 'x' undeclared (first use in this function) testcase.c:5:5: note: each undeclared identifier is reported only once for each function it appears in testcase.c:5:7: error: expected ';' before 'y' The diagnostics given by 4.5 was probably more helpful. Tested revisions: r169155 - crash 4.5 r168785 - OK
[Bug c++/47398] [4.5/4.6 Regression] tree check: accessed elt 10 of tree_vec with 9 elts in tsubst, at cp/pt.c:10500
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47398 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.24 13:36:24 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-24 13:53:27 UTC --- (In reply to comment #3) Is anything specified in the standard in this direction? 20.2.2 Swappable requirements [swappable.requirements] 3 The context in which swap(t, u) and swap(u, t) are evaluated shall ensure that a binary non-member function named “swap” is selected via overload resolution (13.3) on a candidate set that includes: — the two swap function templates defined in utility (20.3) and — the lookup set produced by argument-dependent lookup (3.4.2). The usual way to do that is: using std::swap; // overloads in utility are candidates swap(t, u); // overloads found by ADL are also candidates
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #9 from Johannes Singler singler at kit dot edu 2011-01-24 13:55:33 UTC --- I have made the attached minimal patch. Use std::iter_swap where possible, use swap for _Tp, and leave std::swap for built-in types. I will test and then submit the patch. Johannes
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #10 from Johannes Singler singler at kit dot edu 2011-01-24 13:57:16 UTC --- Created attachment 23098 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23098 Minimal patch avoid std::swap on template types.
[Bug tree-optimization/47427] [4.6 Regression] ICE in process_constraint, at tree-ssa-structalias.c:2901
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47427 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 #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 14:02:05 UTC --- Created attachment 23099 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23099 gcc46-pr47427.patch Untested fix.
[Bug tree-optimization/47428] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in copy_phis_for_bb, at tree-inline.c:1986
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47428 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #23095|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 14:03:41 UTC --- Created attachment 23100 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23100 gcc46-pr47427.patch Different untested fix.
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #22 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-24 14:07:14 UTC --- (In reply to comment #15) Enabling early FRE Index: passes.c === --- passes.c(revision 169136) +++ passes.c(working copy) @@ -760,6 +760,7 @@ NEXT_PASS (pass_remove_cgraph_callee_edges); NEXT_PASS (pass_rename_ssa_copies); NEXT_PASS (pass_ccp); + NEXT_PASS (pass_fre); NEXT_PASS (pass_forwprop); /* pass_build_ealias is a dummy pass that ensures that we execute TODO_rebuild_alias at this point. Re-building @@ -782,7 +783,7 @@ reduces perida size estimate to 694 (so by about 30%) and hookes law to 141 (by 11%). Not enough to make inlining happen, still. That FRE pass should be after pass_sra_early (certainly after pass_build_ealias).
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-24 14:11:05 UTC --- Thanks Johannes. Jon is right (and indeed we are already using the pattern elsewhere): when we are removing the std:: qualification from std::swap inside a namespace != std, let's also add an using std::swap before. Maybe isn't really necessary due to namespace association, but let's play safe. Patch pre-approved.
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 14:18:47 UTC --- So is this now fixed on the trunk? Can anyone run SPEC2k?
[Bug c++/47436] New: Variadic base-specifier-list of union rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47436
Summary: Variadic base-specifier-list of union rejected
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
GCC doesn't accept this
templatetypename ...T union A : T... { };
A a;
It complains at parse time of A about error: derived union 'AT' invalid.
However it doesn't know at that time whether or not the union will have bases
yet when instantiated.
[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-01-24 14:37:29 UTC --- A similar issue occurs with the values +Infinity and 0.0: program testnan real :: i, n = 0.0, m = tiny(0.0) i = 1.0 / n print (F0.2), i print (F3.2), i print (F0.2), n print (F3.2), n print (F0.2), m print (F3.2), m end program testnan Output: +Inf Inf 0.00 .00 .00 .00 The expected chosen field width is 3 in all cases, exactly for the same reason demanded by 10.7.2.1(6)
[Bug c/47435] [4.6 Regression] ICE: SIGSEGV in c_finish_case (c-typeck.c:8859) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47435 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.24 14:43:13 CC||bonzini at gnu dot org Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-01-24 14:43:13 UTC --- It is caused by revision 47435: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00621.html
[Bug libstdc++/47437] New: libstdc++ parallel mode: multiway_merge does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47437 Summary: libstdc++ parallel mode: multiway_merge does not compile Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: sing...@kit.edu CC: sing...@kit.edu, paolo.carl...@oracle.com, manuel.holtgr...@fu-berlin.de Depends on: 47433 Mainline currently fails to compile the parallel mode multiway merge facilities because of a spurious mutable reference. This is a serious regression. The fix is easy, though, and currently undergoes testing.
[Bug c/47435] [4.6 Regression] ICE: SIGSEGV in c_finish_case (c-typeck.c:8859) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47435 --- Comment #2 from Paolo Bonzini bonzini at gnu dot org 2011-01-24 14:47:15 UTC --- The code hardly makes any sense, so it's difficult to say which error message makes more sense. I'll look at the regression.
[Bug libstdc++/47437] libstdc++ parallel mode: multiway_merge does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47437 --- Comment #1 from Johannes Singler singler at kit dot edu 2011-01-24 14:48:42 UTC --- Created attachment 23101 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23101 Remove mutable qualifier from reference member.
[Bug libstdc++/47437] libstdc++ parallel mode: multiway_merge does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47437 Johannes Singler singler at kit dot edu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.24 14:49:38 AssignedTo|unassigned at gcc dot |singler at kit dot edu |gnu.org | Ever Confirmed|0 |1
[Bug libstdc++/47437] [4.6 Regression] libstdc++ parallel mode: multiway_merge does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 Summary|libstdc++ parallel mode:|[4.6 Regression] libstdc++ |multiway_merge does not |parallel mode: |compile |multiway_merge does not ||compile --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-24 14:51:55 UTC --- Ah, that's because I fixed PR 33558 for 4.6 and didn't run the parallel mode testsuite change pre-approved - thanks
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #22 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-24 14:54:51 UTC --- (In reply to comment #21) So is this now fixed on the trunk? Can anyone run SPEC2k? I can run it. I will report back when done.
[Bug rtl-optimization/47414] [4.6 Regression] wrong code with -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47414
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24
15:02:22 UTC ---
rtx_refs_may_alias_p (x=0x71969318, mem=0x71968360, tbaa_p=1 '\001')
for x
(mem/s/f:DI (reg/v/f:DI 2 cx [orig:59 nul ] [59]) [3 nul_23-D.2090.next+0 S8
A64])
and mem
(mem/s/f/c:DI (reg/f:DI 7 sp) [3 MEM[(struct A *)s].next+0 S8 A64])
returns 0, although they clearly do alias.
*.alias says:
nul_23 = { NULL ESCAPED NONLOCAL s HEAP HEAP HEAP } same as nul_29
[Bug rtl-optimization/47414] [4.6 Regression] wrong code with -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47414 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 15:21:32 UTC --- In particular it is aliasing_component_refs_p that says those 2 don't alias. Richi, can you please have a look?
[Bug c/47435] [4.6 Regression] ICE: SIGSEGV in c_finish_case (c-typeck.c:8859) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47435 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug libstdc++/47387] AIX ctype 'mask' override not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47387 --- Comment #4 from Graham Reed greed at pobox dot com 2011-01-24 15:29:55 UTC --- OK, I'll try and get the mailing list thing worked out today.
[Bug c++/47398] [4.5/4.6 Regression] tree check: accessed elt 10 of tree_vec with 9 elts in tsubst, at cp/pt.c:10500
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47398 --- Comment #3 from Dodji Seketeli dodji at gcc dot gnu.org 2011-01-24 16:05:26 UTC --- A patch was proposed at http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01646.html
[Bug rtl-optimization/47414] [4.6 Regression] wrong code with -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47414 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de 2011-01-24 16:08:44 UTC --- On Mon, 24 Jan 2011, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47414 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 15:21:32 UTC --- In particular it is aliasing_component_refs_p that says those 2 don't alias. Richi, can you please have a look? Sure. That's type-based disambiguation btw.
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 16:23:44 UTC --- Not sure if this is a bug at all, structure assignment should be implementable using memcpy or memmove and thus the side effects that will happen on it are not very well defined.
[Bug rtl-optimization/47414] [4.6 Regression] wrong code with -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47414 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-24 16:34:03 UTC --- Index: tree-ssa-alias.c === --- tree-ssa-alias.c(revision 169155) +++ tree-ssa-alias.c(working copy) @@ -808,7 +808,7 @@ indirect_ref_may_alias_decl_p (tree ref1 return aliasing_component_refs_p (ref1, TREE_TYPE (ptrtype1), ref1_alias_set, base1_alias_set, offset1, max_size1, - ref2, TREE_TYPE (base2), + ref2, TREE_TYPE (reference_alias_ptr_type (ref2)), ref2_alias_set, base2_alias_set, offset2, max_size2, true); fixes it.
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 --- Comment #3 from John Regehr regehr at cs dot utah.edu 2011-01-24 16:43:58 UTC --- (In reply to comment #2) Not sure if this is a bug at all, structure assignment should be implementable using memcpy or memmove and thus the side effects that will happen on it are not very well defined. Hi Jakub- volatile isn't a very strong guarantee, but realistically people assume that if a volatile is on the RHS of an assignment, a load from that location occurs (and a store, if on the LHS). My guess is that violating this contract will confuse embedded systems developers and break previously working code. Also, if the rule for volatile becomes significantly different from what I said above, we won't be able to do volatile testing anymore since violations will be sort of meaningless.
[Bug libstdc++/47437] [4.6 Regression] libstdc++ parallel mode: multiway_merge does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47437 --- Comment #3 from singler at gcc dot gnu.org singler at gcc dot gnu.org 2011-01-24 16:44:36 UTC --- Author: singler Date: Mon Jan 24 16:44:30 2011 New Revision: 169166 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169166 Log: 2011-01-24 Johannes Singler sing...@kit.edu PR libstdc++/47437 * include/parallel/multiway_merge.h (_UnguardedIterator): Remove useless mutable from reference declaration. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/multiway_merge.h
[Bug target/47408] Several of the Altivec tests fail if run with a compiler built with --with-cpu=power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47408 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org 2011-01-24 16:47:20 UTC --- Author: meissner Date: Mon Jan 24 16:47:16 2011 New Revision: 169167 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169167 Log: Fix PR 47408 and 47385 Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/altivec.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/altivec-15.C trunk/gcc/testsuite/g++.dg/ext/altivec-types-1.C trunk/gcc/testsuite/g++.dg/ext/altivec-types-2.C trunk/gcc/testsuite/g++.dg/ext/altivec-types-3.C trunk/gcc/testsuite/g++.dg/ext/altivec-types-4.C trunk/gcc/testsuite/gcc.target/powerpc/altivec-11.c trunk/gcc/testsuite/gcc.target/powerpc/altivec-14.c trunk/gcc/testsuite/gcc.target/powerpc/altivec-33.c trunk/gcc/testsuite/gcc.target/powerpc/altivec-types-1.c trunk/gcc/testsuite/gcc.target/powerpc/altivec-types-2.c trunk/gcc/testsuite/gcc.target/powerpc/altivec-types-3.c trunk/gcc/testsuite/gcc.target/powerpc/altivec-types-4.c trunk/gcc/testsuite/gcc.target/powerpc/ppc-vector-memcpy.c trunk/gcc/testsuite/gcc.target/powerpc/ppc-vector-memset.c
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 16:49:17 UTC --- This is related to PR45472 and is solely about volatile fields in aggregates.
[Bug libstdc++/47437] [4.6 Regression] libstdc++ parallel mode: multiway_merge does not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47437 Johannes Singler singler at kit dot edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Johannes Singler singler at kit dot edu 2011-01-24 16:52:37 UTC --- Fixed by above commit.
[Bug tree-optimization/45685] [4.6 Regression] missed conditional move opportunity in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #15 from Jeffrey A. Law law at redhat dot com 2011-01-24 16:56:02 UTC --- Alternately, we could have phi-opts clean this up. ISTM it's not that complex to determine if two PHI nodes have closely related values such as negation, trivial conversions, etc. While this kind of optimization doesn't directly result in a performance improvement, it may make it easier for later opts to improve the code. This would help codesize as we'd be replacing a pair of constant loads with a negation, trivial type conversion, etc.
[Bug target/47408] Several of the Altivec tests fail if run with a compiler built with --with-cpu=power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47408 --- Comment #3 from Michael Meissner meissner at gcc dot gnu.org 2011-01-24 16:57:07 UTC --- Author: meissner Date: Mon Jan 24 16:57:04 2011 New Revision: 169168 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169168 Log: Fix PR 47408 and 47385 Modified: branches/ibm/gcc-4_5-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_5-branch/gcc/config/rs6000/altivec.md branches/ibm/gcc-4_5-branch/gcc/testsuite/ChangeLog.ibm branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/ext/altivec-15.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/ext/altivec-types-1.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/ext/altivec-types-2.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/ext/altivec-types-3.C branches/ibm/gcc-4_5-branch/gcc/testsuite/g++.dg/ext/altivec-types-4.C branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/altivec-11.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/altivec-14.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/altivec-33.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/altivec-types-1.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/altivec-types-2.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/altivec-types-3.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/altivec-types-4.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/ppc-vector-memcpy.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/ppc-vector-memset.c
[Bug c/47438] New: function arguments memory alignment problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47438
Summary: function arguments memory alignment problem.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dbms...@hanmail.net
parameter memory aligment problem in 64 bit gcc compiler.
example )
int Test1(tranNo, name, path, sSpId, spId, spPg, type, size, parm)
long tranNo;
char* name, *path;
short sSpid, spId, spPg, type;
long size;
char* parm;
{
printf(--- size : %ld\n, size);
}
int Test2(tranNo, name, path, sSpId, spId, spPg, size, type, parm)
long tranNo;
char* name, *path;
short sSpid, spId, spPg;
long size;
short type;
char* parm;
{
printf(--- size : %ld\n, size);
}
main()
{
int xx = 7974288;
Test1(xx);
Test2(xx);
}
compiler option
gcc -O -m64 test.c
Above program u can see the different result output .
i think that some of passing parament causes memory alignment problem..
I like to know which version can solve that problem ?
please answer me asap ..
[Bug tree-optimization/47411] [4.5 Regression] Bootstrap failure on x86-64/Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-24 16:53:07 UTC --- I think a backport of 2010-06-30 Michael Matz m...@suse.de PR bootstrap/44699 * tree-vrp.c (vrp_finalize): Deal with changing num_ssa_names. * gimple-fold.c (gimplify_and_update_call_from_tree): If LHS is a gimple reg, attach the original VDEF to the last store in the sequence. is missing.
[Bug c/47438] function arguments memory alignment problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47438 --- Comment #1 from doh-hyun koh dbms007 at hanmail dot net 2011-01-24 17:02:45 UTC --- hi I am developing big application with old large source in linux .. even though I could manage some of bug, eventually the will be big troubles.. so I here I like to report the bugs and wait for your answer .. Please answer me asap ..
[Bug fortran/47439] New: Fun with scratch files on Windows MKTEMP only allows for 26 files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439 Summary: Fun with scratch files on Windows MKTEMP only allows for 26 files Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org, j...@gcc.gnu.org Reported by Claude Simone at http://groups.google.com/group/comp.lang.fortran/msg/b1bf5ce50080e89e Thread: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/8843f2317cb565cd A) Not more than 26 temporary files are possible To generate a temporay file, libgfortran/io/unix.c's tempfile calls the system's mktemp, which according to Microsoft's API has the following property: http://msdn.microsoft.com/en-us/library/34wc6k1f%28v=VS.80%29.aspx _mktemp preserves base and replaces the first trailing X with an alphabetic character. _mktemp replaces the following trailing X's with a five-digit value; this value is a unique number identifying the calling process, or in multithreaded programs, the calling thread. Hence, there are only a to z = 26 temporary files possible - at least concurrently. Thus, for Windows systems, gfortran needs an own implementation for mk(s)temp, which supports more. One possibility would be to change the BASE handed to mktemp. B) Files are not unlinked Newer Windows support for FILE_FLAG_DELETE_ON_CLOSE; cf. CreateFile Function at http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx See also http://msdn.microsoft.com/en-us/library/yeby3zcb%28v=VS.80%29.aspx for D and _O_TEMPORARY in fopen and _wfopen. However, in principle on exit libgfortran's static void __attribute__((destructor)) cleanup (void) should be called, which should delete files.
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #12 from singler at gcc dot gnu.org singler at gcc dot gnu.org 2011-01-24 17:07:40 UTC --- Author: singler Date: Mon Jan 24 17:07:35 2011 New Revision: 169171 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169171 Log: 2011-01-24 Johannes Singler sing...@kit.edu PR libstdc++/47433 * include/parallel/losertree.h (_LoserTree::__delete_min_insert): Do not qualify swap with std:: for value type, but include a using directive instead. (_LoserTreeUnguarded::__delete_min_insert): Likewise. * include/parallel/balanced_quicksort.h (__qsb_divide): Use std::iter_swap instead of std::swap. (__qsb_local_sort_with_helping): Likewise. * include/parallel/partition.h (__parallel_partition): Likewise. (__parallel_nth_element): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/balanced_quicksort.h trunk/libstdc++-v3/include/parallel/losertree.h trunk/libstdc++-v3/include/parallel/partition.h
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 Johannes Singler singler at kit dot edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Johannes Singler singler at kit dot edu 2011-01-24 17:10:05 UTC --- Fixed in mainline.
[Bug target/47440] New: Use LCM for vzeroupper optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47440 Summary: Use LCM for vzeroupper optimization Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com From: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01923.html http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00967.html LCM infrastructure (see lcm.c) is suggested for placing vzerouppers at optimum points. Targeting 4.7.
[Bug target/46519] Missing vzeroupper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46519 --- Comment #8 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-01-24 17:30:00 UTC --- Author: hjl Date: Mon Jan 24 17:29:58 2011 New Revision: 169173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169173 Log: Visit basic blocks using the work-list based algorithm. 2011-01-24 H.J. Lu hongjiu...@intel.com PR target/46519 * config/i386/i386.c: Include sbitmap.h and fibheap.h. (block_info): Add scanned and prev. (move_or_delete_vzeroupper_2): Return if the basic block has been scanned and the upper 128bit state is unchanged from the last scan. (move_or_delete_vzeroupper_1): Return true if the exit state is changed. (move_or_delete_vzeroupper): Visit basic blocks using the work-list based algorithm based on vt_find_locations in var-tracking.c. * config/i386/t-i386: Also depend on sbitmap.h and $(FIBHEAP_H). Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/t-i386
[Bug target/46519] Missing vzeroupper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46519 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2011-01-24 17:30:59 UTC --- Fixed.
[Bug c++/47441] New: g++ Introduces Internal Compiler Error: Bus error during compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47441
Summary: g++ Introduces Internal Compiler Error: Bus error
during compilation
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: erkanbosta...@gmail.com
Hello,
I am having this problem even when I am trying to compile a simple file such as
(I presented this to show that the problem is not a bug in my own code):
#include cstdlib
#include stdio.h
using namespace std;
int main(int argc, char** argv)
{
printf(hello\n);
return 0;
}
I have the following version for my g++ and operating system:
g++ version(g++ -v):
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
Operating system:
Ubuntu 10.10 - the Maverick Meerkat - released in October 2010
I did not give any options for building the compiler, it was there when I
reinstalled my system after a crash. I am using Solaris Studio 12.2 as the IDE
am using the GNU tools as the compiler.
The output of the compiler is as follows:
/usr/bin/make -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make[1]: Entering directory `/home/erkan/SolStudioProjects/BugTest2'
/usr/bin/make -f nbproject/Makefile-Debug.mk
dist/Debug/GNU-Linux-x86/bugtest2
make[2]: Entering directory `/home/erkan/SolStudioProjects/BugTest2'
mkdir -p build/Debug/GNU-Linux-x86
rm -f build/Debug/GNU-Linux-x86/main.o.d
g++-c -g -MMD -MP -MF build/Debug/GNU-Linux-x86/main.o.d -o
build/Debug/GNU-Linux-x86/main.o main.cpp
main.cpp: In function ‘int main(int, char**)’:
main.cpp:21: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions.
make[2]: *** [build/Debug/GNU-Linux-x86/main.o] Error 1
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
make[2]: Leaving directory `/home/erkan/SolStudioProjects/BugTest2'
make[1]: Leaving directory `/home/erkan/SolStudioProjects/BugTest2'
BUILD FAILED (exit value 2, total time: 14s)
I would be grateful if you could solve this problem as soon as possible or show
me a way to get around this as time is extremely important for my current task.
Regards.
[Bug c++/47429] -Wfatal-errors hiding line number of offending caller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47429 --- Comment #3 from Navin Kumar navin.kumar at gmail dot com 2011-01-24 17:42:03 UTC --- Wouldn't the simple fix be to make it a note() that 'int Blah::test' is private and the error() be the caller's attempt to use it?
[Bug c++/47429] -Wfatal-errors hiding line number of offending caller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47429 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-01-24 17:55:29 UTC --- It is common in the C/C++ front-ends that error() is followed by one or more notes() providing context, suggestions or more information. (That is, error: within this context should be a note). We could follow your proposal but I think it will change the output quite a bit and make it more difficult to understand. There are other even more complex cases, like printing template candidates, where there are multiple lines of notes (which currently are multiple calls to inform()).
[Bug libffi/47442] New: does not build multilib on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47442 Summary: does not build multilib on m68k Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org I am trying to build Go to target m68k-rtems. This target builds multilib with many variations. There are multiple instructions in libffi/src/m68k/sysv.S which are not supported in all CPU models. The build currently fails for -m68000 as the CPU model. /users/joel/test-gcc/gcc-svn/libffi/src/m68k/sysv.S:88: Error: operands mismatch -- statement `tst.l %a1' ignored /users/joel/test-gcc/gcc-svn/libffi/src/m68k/sysv.S:106: Error: invalid instruction for this architecture; needs 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], 547x [5470, 5471, 5472, 5473, 5474, 5475], 548x [5480, 5481, 5482, 5483, 5484, 5485] -- statement `fmove.s %fp0,(%a1)' ignored /users/joel/test-gcc/gcc-svn/libffi/src/m68k/sysv.S:112: Error: invalid instruction for this architecture; needs 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], 547x [5470, 5471, 5472, 5473, 5474, 5475], 548x [5480, 5481, 5482, 5483, 5484, 5485] -- statement `fmove.d %fp0,(%a1)' ignored /users/joel/test-gcc/gcc-svn/libffi/src/m68k/sysv.S:118: Error: invalid instruction for this architecture; needs M68K fpu (68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360]) -- statement `fmove.x %fp0,(%a1)' ignored /users/joel/test-gcc/gcc-svn/libffi/src/m68k/sysv.S:181: Error: invalid instruction for this architecture; needs 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], 547x [5470, 5471, 5472, 5473, 5474, 5475], 548x [5480, 5481, 5482, 5483, 5484, 5485] -- statement `fmove.s (%a0),%fp0' ignored
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #23 from Jack Howarth howarth at nitro dot med.uc.edu 2011-01-24 17:58:00 UTC --- (In reply to comment #22) That FRE pass should be after pass_sra_early (certainly after pass_build_ealias). Index: gcc/passes.c === --- gcc/passes.c(revision 169145) +++ gcc/passes.c(working copy) @@ -767,6 +767,7 @@ init_optimization_passes (void) locals into SSA form if possible. */ NEXT_PASS (pass_build_ealias); NEXT_PASS (pass_sra_early); + NEXT_PASS (pass_fre); NEXT_PASS (pass_copy_prop); NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_cd_dce); gives Elapsed CPU time = 8.43600E+00 for gfortran -O3 -ffast-math -funroll-loops -flto -fwhole-program fatigue.f90 -o fatigue and Elapsed CPU time = 4.16600E+00 for gfortran -O3 -ffast-math -funroll-loops -finline-limit=250 --param large-function-growth=250 -flto -fwhole-program fatigue.f90 -o fatigue
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 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-01-24 18:02:45 UTC --- Not sure if it actually was so good idea to remove the edge conditions. If the bb_predicate (first_edge-src) and bb_predicate (second_edge-src) are negations of each other, then it is easy, similarly if one of the first_edge-src and second_edge-src bbs dominates the other one. But if neither of those two bbs dominates the other one, then either we have the edge conditions and can use condition bb_predicate (bb) together with one (or the other) edge conditions, or we'd need to reconstruct both conditions (we have them gimplified) and xor them together to see the actual difference in between those and see in which one of the two conditions is the delta contained. How much memory savings did http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02294.html actually bring in? Perhaps we wouldn't have to store the whole conditions into edge aux fields, but instead just a boolean that would help find_phi_replacement_condition choose which of the two conditions to use (or it could be stored as two bits in the target bb's bb_predicate* structure). All I wanted to say is that especially with even far more complicated loops then this one reconstructing which condition and bb to use in find_phi_replacement_condition is going to be more difficult than finding it out earlier (during predicate_bbs most likely).
[Bug c++/47441] g++ Introduces Internal Compiler Error: Bus error during compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47441 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-24 18:06:31 UTC --- (In reply to comment #0) g++-c -g -MMD -MP -MF build/Debug/GNU-Linux-x86/main.o.d -o build/Debug/GNU-Linux-x86/main.o main.cpp main.cpp: In function ‘int main(int, char**)’: main.cpp:21: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. This bug should be reported to Ubuntu, following the instruction referred to above, because GCC 4.4.5 doesn't have this problem for anyone else.
[Bug c++/47429] -Wfatal-errors hiding line number of offending caller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47429 --- Comment #5 from Navin Kumar navin.kumar at gmail dot com 2011-01-24 18:07:45 UTC --- Hmm. I only need -Wfatal-errors because otherwise a small typo can cause heavily templated code to go berserk and output 10,000 lines of errors. Perhaps a compromise is to have the ability to specify how many errors are tolerated? Instead of -Wfatal-errors that bombs on the first error, perhaps -Wfatal-errors=5 that limits the output to 5 errors before failing?
[Bug c++/47429] -Wfatal-errors hiding line number of offending caller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47429 --- Comment #6 from froydnj at codesourcery dot com froydnj at codesourcery dot com 2011-01-24 18:09:12 UTC --- On Mon, Jan 24, 2011 at 06:07:50PM +, navin.kumar at gmail dot com wrote: Instead of -Wfatal-errors that bombs on the first error, perhaps -Wfatal-errors=5 that limits the output to 5 errors before failing? See -fmax-errors, new in 4.6.
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-24 18:16:47 UTC --- (In reply to comment #22) That FRE pass should be after pass_sra_early (certainly after pass_build_ealias). Moving pass_fre after pass_sra_early does not fix the failures in the test suite rported in comment #21.
[Bug tree-optimization/47443] New: [4.6 Regression] ICE: SSA name in freelist but still referenced or SIGSEGV with -fstack-check=generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47443 Summary: [4.6 Regression] ICE: SSA name in freelist but still referenced or SIGSEGV with -fstack-check=generic Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23102 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23102 reduced testcase I don't know how much is this related to PR47265 Compiler output: $ gcc -O -fstack-check=generic testcase.c testcase.c: In function 'foo': testcase.c:10:1: error: SSA name in freelist but still referenced D.2689_3 testcase.c:3:3: note: in statement D.2701_11 = D.2689_3 D.2702_10; testcase.c:10:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Backtrace for the error: (gdb) bt #0 error (gmsgid=0x1143688 SSA name in freelist but still referenced) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:747 #1 0x008e37e2 in verify_expr (tp=0x75d4b888, walk_subtrees=0x7fffd64c, data=value optimized out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:2599 #2 0x00a651df in walk_tree_1 (tp=0x75d4b888, func=0x8e31c0 verify_expr, data=0x7fffd750, pset=0x0, lh=0) at /mnt/svn/gcc-trunk/gcc/tree.c:10242 #3 0x0073f6ac in walk_gimple_op (stmt=0x75d4b840, callback_op=0x8e31c0 verify_expr, wi=0x7fffd750) at /mnt/svn/gcc-trunk/gcc/gimple.c:1362 #4 0x008eddf3 in verify_stmt () at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:4156 #5 verify_stmts () at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:4382 #6 0x00a02a7d in verify_ssa (check_modified_stmt=1 '\001') at /mnt/svn/gcc-trunk/gcc/tree-ssa.c:878 #7 0x007eeef9 in execute_function_todo (data=value optimized out) at /mnt/svn/gcc-trunk/gcc/passes.c:1246 #8 0x007ef5ed in execute_todo (flags=34823) at /mnt/svn/gcc-trunk/gcc/passes.c:1277 #9 0x007f1bdf in execute_one_pass (pass=0x160d000) at /mnt/svn/gcc-trunk/gcc/passes.c:1585 #10 0x007f1ea5 in execute_pass_list (pass=0x160d000) at /mnt/svn/gcc-trunk/gcc/passes.c:1617 #11 0x007f1eb7 in execute_pass_list (pass=0x160c940) at /mnt/svn/gcc-trunk/gcc/passes.c:1618 #12 0x007f10ac in do_per_function_toporder (callback=0x7f1e90 execute_pass_list, data=0x160c880) at /mnt/svn/gcc-trunk/gcc/passes.c:1148 #13 0x007f2346 in execute_ipa_pass_list (pass=0x160c9a0) at /mnt/svn/gcc-trunk/gcc/passes.c:1934 #14 0x00afd391 in ipa_passes () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1725 #15 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1797 #16 0x00afd5ea in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1042 #17 0x0050585c in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9843 #18 0x008dd544 in compile_file (argc=14, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #19 do_compile (argc=14, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1874 #20 toplev_main (argc=14, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1937 #21 0x765f1bbd in __libc_start_main () from /lib/libc.so.6 #22 0x004ec455 in _start () Backtrace for the segfault: Program received signal SIGSEGV, Segmentation fault. 0x0073efec in is_gimple_reg_type (t=0x75d4b478) at /mnt/svn/gcc-trunk/gcc/gimple.c:2841 2841 return !AGGREGATE_TYPE_P (type); (gdb) bt #0 0x0073efec in is_gimple_reg_type (t=0x75d4b478) at /mnt/svn/gcc-trunk/gcc/gimple.c:2841 #1 is_gimple_val (t=0x75d4b478) at /mnt/svn/gcc-trunk/gcc/gimple.c:2909 #2 0x008e577f in verify_gimple_assign_binary (stmt=value optimized out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:3361 #3 verify_gimple_assign (stmt=value optimized out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:3829 #4 verify_types_in_gimple_stmt (stmt=value optimized out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:3983 #5 0x008ede2f in verify_stmts () at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:4385 #6 0x00a02a7d in verify_ssa (check_modified_stmt=1 '\001') at /mnt/svn/gcc-trunk/gcc/tree-ssa.c:878 #7 0x007eeef9 in execute_function_todo (data=value optimized out) at /mnt/svn/gcc-trunk/gcc/passes.c:1246 #8 0x007ef5ed in execute_todo (flags=34823) at /mnt/svn/gcc-trunk/gcc/passes.c:1277 #9 0x007f1bdf in execute_one_pass (pass=0x160d000) at /mnt/svn/gcc-trunk/gcc/passes.c:1585 #10 0x007f1ea5 in execute_pass_list (pass=0x160d000) at /mnt/svn/gcc-trunk/gcc/passes.c:1617 #11 0x007f1eb7 in execute_pass_list (pass=0x160c940) at /mnt/svn/gcc-trunk/gcc/passes.c:1618 #12 0x007f10ac in do_per_function_toporder (callback=0x7f1e90
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #8 from Sebastian Pop spop at gcc dot gnu.org 2011-01-24 18:34:38 UTC --- The translation in predicate_all_scalar_phis assumes that the incoming edges OR up to true: it translates a phi node x = phi (y, z) into x = a ? y : z; In the testcase of this PR, the conditions of the two edges is not ORing up to true: we have something like this: x = a ? y : x; x = (!a and b) ? z : x; this is because we have a CFG containing diamond shape, and the write into x does not happen at every execution of the loop: (a and !b) should not modify the value of x. A possible solution is to filter out these cases in predicate_bbs.
[Bug tree-optimization/47443] [4.6 Regression] ICE: SSA name in freelist but still referenced or SIGSEGV with -fstack-check=generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47443 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-01-24 18:35:47 UTC --- Created attachment 23103 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23103 different crash $ gcc -O -fstack-check=generic testcase2.c testcase2.c: In function 'foo': testcase2.c:13:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It crashes at different place, but maybe it's the same problem: Program received signal SIGSEGV, Segmentation fault. 0x00714225 in fold_comparison (loc=333, code=LT_EXPR, type=0x77ed8498, op0=0x75d4b478, op1=0x75d4b898) at /mnt/svn/gcc-trunk/gcc/fold-const.c:8587 8587 if (POINTER_TYPE_P (TREE_TYPE (arg0)) (gdb) bt #0 0x00714225 in fold_comparison (loc=333, code=LT_EXPR, type=0x77ed8498, op0=0x75d4b478, op1=0x75d4b898) at /mnt/svn/gcc-trunk/gcc/fold-const.c:8587 #1 0x006debf1 in fold_binary_loc (loc=333, code=LT_EXPR, type=0x77ed8498, op0=0x75d4b478, op1=0x75d4b898) at /mnt/svn/gcc-trunk/gcc/fold-const.c:12708 #2 0x006f93a1 in fold_build2_stat_loc (loc=333, code=LT_EXPR, type=0x77ed8498, op0=0x75d4b478, op1=0x75d4b898) at /mnt/svn/gcc-trunk/gcc/fold-const.c:13982 #3 0x00991baa in forward_propagate_into_gimple_cond (stmt=0x75d3c460) at /mnt/svn/gcc-trunk/gcc/tree-ssa-forwprop.c:422 #4 0x00991edd in tree_ssa_forward_propagate_single_use_vars () at /mnt/svn/gcc-trunk/gcc/tree-ssa-forwprop.c:2085 #5 0x007f1ba6 in execute_one_pass (pass=0x160d000) at /mnt/svn/gcc-trunk/gcc/passes.c:1562 #6 0x007f1ea5 in execute_pass_list (pass=0x160d000) at /mnt/svn/gcc-trunk/gcc/passes.c:1617 #7 0x007f1eb7 in execute_pass_list (pass=0x160c940) at /mnt/svn/gcc-trunk/gcc/passes.c:1618 #8 0x007f10ac in do_per_function_toporder (callback=0x7f1e90 execute_pass_list, data=0x160c880) at /mnt/svn/gcc-trunk/gcc/passes.c:1148 #9 0x007f2346 in execute_ipa_pass_list (pass=0x160c9a0) at /mnt/svn/gcc-trunk/gcc/passes.c:1934 #10 0x00afd391 in ipa_passes () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1725 #11 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1797 #12 0x00afd5ea in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1042 #13 0x0050585c in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9843 #14 0x008dd544 in compile_file (argc=14, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #15 do_compile (argc=14, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1874 #16 toplev_main (argc=14, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1937 #17 0x765f1bbd in __libc_start_main () from /lib/libc.so.6 #18 0x004ec455 in _start ()
[Bug c++/47444] New: False warning: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47444
Summary: False warning: array subscript is above array bounds
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eidle...@mail.ru
Created attachment 23104
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23104
c++ code
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/eid-letni/opt/gcc/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/eid-letni/opt/gcc
--enable-languages=c,c++ : (reconfigured) ../configure
--prefix=/home/eid-letni/opt/gcc --enable-languages=c,c++,lto --no-create
--no-recursion
Thread model: posix
gcc version 4.6.0 20110124 (experimental) (GCC)
$ uname -a
Linux eidletni 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 01:41:57 UTC 2010
i686 GNU/Linux
$ g++ -O3 -Wall -c a.ii
Warning in function bool f2(unsigned) :
bool f1();
struct A
{
bool b1;
bool b2;
A(unsigned i);
};
bool f2(unsigned i)
{
enum { SIZE = 2 };
if ( i=SIZE f1() )
throw 1;
bool v[SIZE] = { 1, 1 };
return v[i];
}
A::A(unsigned i):
b1(f2(i)),
b2(f2(i))
{}
This warning is false, because constructor of struct A never called with bad
parameters.
Warning disappears if:
*) remove f1() call in if ( i=SIZE f1() )
*) make return true instead of throw 1
*) inline struct A constructor, inline A::A(unsigned i)
*) make size of array bool v[] equal 1, enum { SIZE = 1 }
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #9 from Sebastian Pop spop at gcc dot gnu.org 2011-01-24 18:38:13 UTC --- Sorry, (!a and !b) should not modify the value of x.
[Bug pch/47430] [4.6 Regression] Random PCH related bootstrap failures on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47430 --- Comment #2 from Benjamin Kosnik bkoz at gcc dot gnu.org 2011-01-24 18:53:14 UTC --- 4) is not possible, as stdc++.h is included in precompiled/stdtr1c++.h and the extension PCH. (ie, chained pches.) We don't want to re-order this, and build stdtr1c++.h without stdc++.h, as then PCH file sizes for stdtr1c++.h.gch/extc++.h.gch will balloon massively. You can work around this with --disable-libstdcxx-pch at configure time for PPC. Long term solution IMHO is to make .gch files smaller.
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #10 from Sebastian Pop spop at gcc dot gnu.org 2011-01-24 18:55:48 UTC --- The BB of the phi node to be rewritten should post-dominate the BBs in which the arguments of the phi node are defined. The following gcc_assert will ICE when the translation done in predicate_scalar_phi is unsafe: diff --git a/gcc/tree-if-conv.c b/gcc/tree-if-conv.c index cc7ad8a..9a3e2b5 100644 --- a/gcc/tree-if-conv.c +++ b/gcc/tree-if-conv.c @@ -992,6 +992,7 @@ if_convertible_loop_p_1 (struct loop *loop, return false; calculate_dominance_info (CDI_DOMINATORS); + calculate_dominance_info (CDI_POST_DOMINATORS); /* Allow statements that can be handled during if-conversion. */ ifc_bbs = get_loop_body_in_if_conv_order (loop); @@ -1244,6 +1245,15 @@ predicate_scalar_phi (gimple phi, tree cond, arg_1 = gimple_phi_arg_def (phi, 1); } + gcc_assert ((TREE_CODE (arg_0) != SSA_NAME + || dominated_by_p (CDI_POST_DOMINATORS, + gimple_bb (SSA_NAME_DEF_STMT (arg_0)), + bb)) + (TREE_CODE (arg_1) != SSA_NAME + || dominated_by_p (CDI_POST_DOMINATORS, + gimple_bb (SSA_NAME_DEF_STMT (arg_1)), + bb))); + /* Build new RHS using selected condition and arguments. */ rhs = build3 (COND_EXPR, TREE_TYPE (res), unshare_expr (cond), arg_0, arg_1);
[Bug pch/47430] [4.6 Regression] Random PCH related bootstrap failures on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47430 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 19:19:44 UTC --- Created attachment 23105 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23105 gcc46-pr47430-workaround.patch This patch shows a sample implementation of 4) which seems to work just fine. It should have no effect on what is actually provided by the headers, just make sure stdc++.gch/* isn't used during stdtr1c++.gch etc. compilation. BTW, it surprises me that for -std=c++0x extc++.h doesn't include bits/stdc++.h, I can understand why it doesn't include tr1 stuff in that case, but I'd expect the standard stuff to be included nevertheless.
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 19:24:57 UTC --- The # iftmp.0_6 = PHI 3(5), 1(6) PHI node certainly wouldn't trigger that assert, as it has non-SSA_NAMEs in arguments, yet there is the same problem with building that condition.
[Bug target/43154] vec_mergel and vec_mergeh should support V2DF/V2DI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43154 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Michael Meissner meissner at gcc dot gnu.org 2011-01-24 19:52:28 UTC --- Fixed on February 2, 2010.
[Bug libstdc++/47387] AIX ctype 'mask' override not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47387 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-01-24 19:53:38 UTC --- Author: paolo Date: Mon Jan 24 19:53:35 2011 New Revision: 169178 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169178 Log: 2011-01-24 Graham Reed gr...@pobox.com PR libstdc++/47387 * config/os/aix/ctype_inline.h (ctypechar::is): Use _M_table if provided. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/os/aix/ctype_inline.h
[Bug libstdc++/47387] AIX ctype 'mask' override not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47387 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 Severity|minor |normal --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-24 19:54:58 UTC --- Applied.
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #12 from Sebastian Pop spop at gcc dot gnu.org 2011-01-24 19:57:40 UTC --- Created attachment 23106 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23106 proposed fix Thanks Jakub for thinking out a counter example, what about this fix?
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-24 20:04:08 UTC --- Can't loop-header have more than 2 predecessors without causing any problems? Other than that it might work fine.
[Bug fortran/47445] New: testsuite/gfortran.dg/impure_1.f08 FAILs with -O -fno-omit-frame-pointer -fpeel-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47445 Summary: testsuite/gfortran.dg/impure_1.f08 FAILs with -O -fno-omit-frame-pointer -fpeel-loops Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23107 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23107 reduced testcase (hopefully correctly) Output: $ gfortran -std=f2008 -fall-intrinsics -O -fno-omit-frame-pointer -fpeel-loops impure_1.f08 $ ./a.out Aborted Tested revisions: r169155 - fail 4.5 - can't compile
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #14 from Sebastian Pop spop at gcc dot gnu.org 2011-01-24 20:14:55 UTC --- Right, thanks for catching that: I handled it only in the first place and not in the second: gcc_assert (bb == bb-loop_father-header || bb_postdominates_preds (bb)); I am seeing that this check is redundant, as just before calling predicate_scalar_phi, we have: if (bb == loop-header) continue; As this is in a gcc_assert I don't mind the extra check, just to make it more clear when somebody reads this code again. If so, I will send the amended patch to gcc-patches.
