Procedure Pointer and OpenMP GFortran Bug
There seems to be a bug involving procedure pointers and OpenMP when using the default(none) clause when starting a parallel region. This means that if there is a procedure pointer inside a parallel region, and a default(none) clause is present, a compile time error will occur. If the default(none) clause is removed, or replaced by default(shared), the program compiles properly. I think GNU Fortran is confusing whether a procedure pointer is a variable or not. If it is a variable then it must be defined when default(none) is specified. However, it is not allowed as a variable name in a shared clause. Is a procedure pointer a variable or not? FYI the Intel compiler allows all conventions shown below. I know Intel Fortran is often loose on enforcing standard compliance, so I don't know which method is right, but something should be done to allow a default(none) clause with procedure pointers. Best Regards, David Bal P.S. This problem occurs with GFortran 4.6, 4.8 and the latest 4.9 experimental. ! EXAMPLE CODE BELOW module test contains subroutine double(a) integer, intent(in out) :: a a = a * 2 end subroutine double end module test program procedure_pointer_openmp_bug use test implicit none interface subroutine My_Interface(A) integer, intent(in out) :: a end subroutine My_Interface end interface procedure (My_Interface), pointer :: math integer, parameter :: nA = 10 integer, dimension(nA) :: A = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] integer :: i math = double ! ***VERSION 1 - Error: ‘math’ not specified in enclosing parallel ! !$omp parallel do ! !$omp default(none) ! !$omp shared(A) ! ***VERSION 2 - Error: Object 'math' is not a variable at (1) ! !$omp parallel do ! !$omp default(none) ! !$omp shared(A, math) ! ***VERSION 3 - COMPILES AND RUNS ! !$omp parallel do ! !$omp default(shared) ! !$omp shared(A) ! ***VERSION 4 - COMPILES AND RUNS !$omp parallel do !$omp shared(A) do i = 1, nA call math(A(i)) end do !$omp end parallel do write (*,*) A end program procedure_pointer_openmp_bug ! EXAMPLE CODE ABOVE
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 --- Comment #20 from Marek Polacek mpolacek at gcc dot gnu.org --- Yes, the patch maybe fixes the debuginfo issue, but there's something else that is wrong. E.g., on the testcase from PR58018, we have in reassociate_bb *after* (and that is important) optimize_range_tests this: bb 7: [...] e.1_16 = _14 e.0_15; _17 = f_12 = 0; _18 = (int) _17; e.1_19 = e.1_16 _18; _20 = f_12 0; _23 = f_12 0; _24 = (int) _23; _21 = (int) _20; e.1_22 = e.1_19 _21; [...] Now, in reassociate_bb, we go over the stmts, from the last stmt to the first stmt in the bb. For the appropriate stmts, we call rewrite_expr_tree to rewrite the linearized statements according to the operand_entry_t ops vector, in this case we call it on e.1_22 = e.1_19 _21; and the vector ops contains Op 0 - rank: 589826, tree: _14 Op 1 - rank: 3, tree: _24 Op 2 - rank: 1, tree: e.0_15 In rewrite_expr_tree, we recursively call this function on e.1_19, whose SSA_NAME_DEF_STMT is e.1_19 = e.1_16 _18; This stmt is then transformed into e.1_19 = _24 e.0_15; But, at the point where e.1_19 is defined, the _24 isn't defined yet! So, it seems, ensure_ops_are_available should handle a situation like this. However, it doesn't: perhaps the issue is that find_insert_point won't find the right insert point (the stmt is e.1_19 = e.1_16 _18;, the dep_stmt is _24 = (int) _23;), in there we have: if (gimple_uid (insert_stmt) == gimple_uid (dep_stmt) gimple_bb (insert_stmt) == gimple_bb (dep_stmt) insert_stmt != dep_stmt) insert_stmt = appears_later_in_bb (insert_stmt, dep_stmt); else if (not_dominated_by (insert_stmt, dep_stmt)) insert_stmt = dep_stmt; return insert_stmt; Neither of these condition holds; gimple_uid of the dep_stmt is 0 and of insert_stmt it is 16. Thus, find_insert_point returns e.1_19 = e.1_16 _18;. That's wrong, I suppose. Maybe the issue is that if the two stms are in the same bb, we just look at their UIDs and based on that we find out the dependency, but the new stms coming from optimize_range_tests don't have gimple UIDs set, thus this can't work. Likely I'm wrong, would appreciate if someone could shed some light on this. Looking into it more...
[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #9 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #8) AFAICT the main issue has been fixed almost two years ago: (1) The errors of the kind Error: 'add_vector_3d' and 'add_vector_2d' for GENERIC '+' at (1) are ambiguous are valid. After this interpretation has been established here, it is a bit unfortunate to see that current trunk (4.9.0 20130820, r201883) does not show the error any more (in contrast to 4.8 and 4.7). If we still believe that the error is correct, then this is a regression (would be interesting to know which revision caused it).
[Bug middle-end/58143] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 --- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de --- How can I set the status of this tracker to CONFIRMED ? Should'nt the component be tree-optimization instead of middle-end ?
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 Phil Muldoon pmuldoon at redhat dot com changed: What|Removed |Added CC||pmuldoon at redhat dot com --- Comment #12 from Phil Muldoon pmuldoon at redhat dot com --- I checked in a patch to fix this yesterday. Not sure why the bug did not auto-update. Here is the link to the patch: http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00497.html Author: pmuldoon Date: Tue Aug 20 19:20:42 2013 New Revision: 201888 URL: http://gcc.gnu.org/viewcvs?rev=201888root=gccview=rev Log: 2013-08-20 Phil Muldoon pmuld...@redhat.com PR libstdc++/53477 http://sourceware.org/bugzilla/show_bug.cgi?id=15195 * python/libstdcxx/v6/printers.py (Printer.__call__): If a value is a reference, fetch referenced value. (RxPrinter.invoke): Ditto. * testsuite/libstdc++-prettyprinters/cxx11.cc (main): Add -O0 flag. Add referenced value tests. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Martin Liška marxin.liska at gmail dot com changed: What|Removed |Added CC||marxin.liska at gmail dot com --- Comment #189 from Martin Liška marxin.liska at gmail dot com --- I've encountered problems connected with PGO: gcc revision: 201894 firefox changeset: 143205:1d6bf2bd4003 (Aug 20, 2013) I build instrumented binary without LTO and after that I use the profile for LTO: MYFLAGS=-flto=9 -fno-fat-lto-objects -ftoplevel-reorder -fprofile-use -Wno-error=coverage-mismatch I know that there are gcda files that are mentioned in this thread and were removed by me: jemalloc.gcda (makes sense) ptsynch.gcda (likewise) HashFunctions.gcda (?) sqlite3.gcda (?) After linking of sqlite3, there are many corrupted profiles like: /ssd/firefox/js/src/gc/Marking.cpp /ssd/firefox/js/src/frontend/BytecodeEmitter.cpp /ssd/firefox/js/src/frontend/Interpreter.cpp ... Example of an error: /ssd/firefox/js/src/gc/Marking.cpp: In function ‘js::gc::IsAboutToBeFinalizedJSAtom(JSAtom**)bool [clone .isra.65]’: /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: profile data is not flow-consistent } ^ /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 3-6 thought to be -81 /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 3-4 thought to be 39667 /ssd/firefox/js/src/gc/Marking.cpp: In function ‘js::gc::IsAboutToBeFinalizedjs::UnownedBaseShape(js::UnownedBaseShape**)bool [clone .isra.52]’: /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: profile data is not flow-consistent /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 3-6 thought to be -1 /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 3-4 thought to be 41156 /ssd/firefox/js/src/gc/Marking.cpp: In function ‘MarkInternalJSAtom(JSTracer*, JSAtom**)void’: /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: profile data is not flow-consistent /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 9-14 thought to be -39 /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 9-10 thought to be 180119 /ssd/firefox/js/src/gc/Marking.cpp: In function ‘MarkInternalJSObject(JSTracer*, JSObject**)void’: /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: profile data is not flow-consistent /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 11-18 thought to be -1 /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 11-12 thought to be 49007 /ssd/firefox/js/src/gc/Marking.cpp: In member function ‘js::MarkStackunsigned long::push(unsigned long)’: /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: profile data is not flow-consistent /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 4-6 thought to be -1 /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 4-5 thought to be 1 /ssd/firefox/js/src/gc/Marking.cpp: In member function ‘js::GCMarker::drainMarkStack(js::SliceBudget)’: /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: profile data is not flow-consistent /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 3-4 thought to be -7 /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 3-1 thought to be 7 /ssd/firefox/js/src/gc/Marking.cpp: In member function ‘js::ObjectImpl::slotSpan() const’: /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: profile data is not flow-consistent /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 5-7 thought to be -1 /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 5-6 thought to be 15965 Thank you, Martin
[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to janus from comment #9) After this interpretation has been established here, it is a bit unfortunate to see that current trunk (4.9.0 20130820, r201883) does not show the error any more (in contrast to 4.8 and 4.7). However, the variant in comment 2 still shows the error. The difference is that in comment 0 one has an argument with type(point3d) instead of class(3d), so maybe this is again an issue with symmetrization.
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Phil Muldoon from comment #12) I checked in a patch to fix this yesterday. Not sure why the bug did not auto-update. Unfortunately after the sourceware.org hardware upgrade the script to update bugzilla from commits was lost or disabled, and noone's restored it. Thanks for adding the commit details manually, most of us don't bother because it adds a step to the process and is quite tedious when you're making lots of commits. Is this RESOLVED now then?
[Bug c++/29143] address-of overloaded function does not work in function call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29143 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Not actively working on this.
[Bug c/58209] New: ICE in extract_range_from_binary_expr, at tree-vrp.c:2294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58209
Bug ID: 58209
Summary: ICE in extract_range_from_binary_expr, at
tree-vrp.c:2294
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
seen with 4.6.4, 4.7.3, 4.8.1 and trunk with -O2, lowering to -O1 works around
the issue.
$ gcc-4.7 -c -O2 foo.c
foo.c: In function 'pow2_s':
foo.c:3:7: internal compiler error: in build2_stat, at tree.c:3785
Please submit a full bug report,
with preprocessed source if appropriate.
$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 foo.c
foo.c: In function 'pow2_s':
foo.c:25:1: error: invalid (pointer) operands to plus/minus
}
^
acc_tmp_14 = add_acc_5 + _1;
foo.c:25:1: internal compiler error: verify_gimple failed
Please submit a full bug report,
$ cat foo.c
#include stdint.h
void *pow2_s(void *arg)
{
intptr_t n = (intptr_t)arg;
if (n == 0)
return (void *)1;
n--;
intptr_t s1 = (intptr_t)pow2_s((void *)n);
intptr_t s2 = (intptr_t)pow2_s((void *)n);
return (void *)(s1 + s2);
}
int main(void)
{
intptr_t n = 5;
pow2_s((void *)n);
return 0;
}
[Bug c++/54278] __attribute__((noreturn)) called from destructor when another auto-scoped variable has a non-trivial dtor erroneously fails with control reaches end of non-void function at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54278 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-21 CC|travis at gockelhut dot com| Ever confirmed|0 |1
[Bug rtl-optimization/58210] New: 400.perlbench fails with ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58210
Bug ID: 58210
Summary: 400.perlbench fails with ICE
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Ganesh.Gopalasubramanian at amd dot com
400.perlbench fails with the following error.
pp_sort.c:1352:1: error: type mismatch in pointer plus expression
S_qsortsv(pTHX_ gptr *list1, size_t nmemb, SVCOMPARE_t cmp, U32 flags)
^
struct SV * *
struct SV * *
struct SV * *
vect_vec_iv_.705_551 = vect_vec_iv_.705_565 + { 32B, 32B };
pp_sort.c:1352:1: error: type mismatch in pointer plus expression
struct SV * *
struct SV * *
struct SV * *
vect_vec_iv_.705_543 = vect_vec_iv_.705_565 + { 48B, 48B };
pp_sort.c:1352:1: error: type mismatch in pointer plus expression
struct SV * *
struct SV * *
struct SV * *
vect_vec_iv_.705_528 = vect_vec_iv_.705_565 + { 64B, 64B };
pp_sort.c:1352:1: internal compiler error: verify_gimple failed
0x55cdf4 ???
../sysdeps/x86_64/elf/start.S:113
[Bug c++/54310] Order of operations during overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54310 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Current ICC also accepts this.
[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786 --- Comment #11 from janus at gcc dot gnu.org --- (In reply to janus from comment #9) If we still believe that the error is correct, then this is a regression (would be interesting to know which revision caused it). Apparently it is due to r201329 (for PR 57530), in particular the interface.c part.
[Bug tree-optimization/58209] ICE in extract_range_from_binary_expr, at tree-vrp.c:2294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58209 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-21 CC||mpolacek at gcc dot gnu.org Component|c |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/58209] ICE in extract_range_from_binary_expr, at tree-vrp.c:2294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58209
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Reduced:
long *
foo (long n)
{
if (n)
return 0;
long l = (long) foo (0);
return (long *) (l + 1);
}
[Bug c++/56134] ICE: alias attribute on c++ static class member;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56134 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-21 Ever confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in mainline. I'm adding the testcase and closing the PR.
[Bug c++/56152] explicit template instantiation of protected template function redeclared as public fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56152 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-21 Ever confirmed|0 |1
[Bug tree-optimization/58209] ICE in extract_range_from_binary_expr, at tree-vrp.c:2294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58209
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Actually this one's better, the TC in #c2 ICEs only with trunk, the following
ICEs with 4.[678]/trunk:
long *
foo (long n)
{
if (n)
return (long *) 1;
long s = (long) foo (1);
return (long *) (s + 1);
}
[Bug c++/56134] ICE: alias attribute on c++ static class member;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56134 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/56130] __attribute__((deprecated)) does not affect C++ reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56130 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-21 Ever confirmed|0 |1
[Bug tree-optimization/58209] ICE in extract_range_from_binary_expr, at tree-vrp.c:2294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58209
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
And perhaps even better, use __INTPTR_TYPE__ instead of long...
typedef __INTPTR_TYPE__ T;
T *
foo (T n)
{
if (n)
return (T *) 1;
T s = (T) foo (1);
return (T *) (s + 1);
}
[Bug fortran/53950] [4.7/4.8/4.9 Regression] 1.5 times slowdown from 4.4.0 to 4.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53950 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from janus at gcc dot gnu.org --- (In reply to Yury Kapoyko from comment #4) I agree with you. This buf refers to mingw, I think, it could be closed. Doing so.
[Bug c++/56130] __attribute__((deprecated)) does not affect C++ reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56130 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2013-08-21 00:00:00 | Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug tree-optimization/58209] [4.7/4.8/4.9 Regression] ICE in extract_range_from_binary_expr, at tree-vrp.c:2294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58209 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|ICE in |[4.7/4.8/4.9 Regression] |extract_range_from_binary_e |ICE in |xpr, at tree-vrp.c:2294 |extract_range_from_binary_e ||xpr, at tree-vrp.c:2294 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Started in between r125500 and r126000, thus a regression.
[Bug fortran/57957] [F03] Double free with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|Double free with|[F03] Double free with |allocatable components |allocatable components --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #1) For GCC 4.9, one needs to wrap the code in the main program in BLOCK/END BLOCK as otherwise the end-of-scope deallocation does not trigger, which causes the failure. Updated test case: program main implicit none type :: type1 real, allocatable :: anum(:) end type type :: type2 type(type1) :: temp end type block type(type1) :: t1 type(type2) :: t2 t1 = type1([0.,1.]) t2 = type2(t1) end block end Note: The double free goes away when changing the line t2 = type2(t1) to t2%temp = t1 That means the actual problem is not the auto-dealloc itself (which is done properly), but the construction of t2: With the second variant, a deep copy is done (allocating a separate chunk of memory for t2%temp), while in the first one t2%temp only gets a reference to the memory allocated for t1 (which is of course wrong). Since both t1 and t2 are auto-deallocated, we try to free that memory twice.
[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- I still get the errors pr48786_2.f90:132.46: generic, public :: operator(+) = add_vector 1 Error: 'add_vector_3d' and 'add_vector_2d' for GENERIC '+' at (1) are ambiguous pr48786_2.f90:133.50: generic, public :: assignment(=) = assign 1 Error: 'assign_3d' and 'assign_2d' for GENERIC '=' at (1) are ambiguous pr48786_2.f90:249.6: use points2d3d ! Both 2D and 3D points available 1 Fatal Error: Can't open module file 'points2d3d.mod' for reading at (1): No such file or directory with the test in http://gcc.gnu.org/ml/fortran/2011-04/msg00293.html at r201817 or 4.8.1. The errors are gone with the following change --- pr48786_2.f902013-07-01 22:53:35.0 +0200 +++ pr48786_2_db.f902013-08-21 14:15:35.0 +0200 @@ -129,8 +129,8 @@ module points2d3d procedure :: add_vector = add_vector_3d procedure :: random = random_vector_3d procedure :: assign = assign_3d - generic, public :: operator(+) = add_vector - generic, public :: assignment(=) = assign +! generic, public :: operator(+) = add_vector +! generic, public :: assignment(=) = assign end type point3d contains in type, extends(point2d) :: point3d. Is this a bug or the expected behavior?
[Bug fortran/57696] [F03] Defined assignment for components not used when those are ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57696 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|Defined assignment for |[F03] Defined assignment |components not used when|for components not used |those are ALLOCATABLE |when those are ALLOCATABLE --- Comment #3 from janus at gcc dot gnu.org --- Related to PR 46897, I guess. The difference is that we are dealing with ALLOCATABLE components here.
[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|Segfault with defined |[OOP] Segfault with defined |assignment for components |assignment for components |during intrinsic assignment |during intrinsic assignment --- Comment #5 from janus at gcc dot gnu.org --- Related to PR 57696 and PR 46897, obviously.
[Bug target/58172] ifcvt test failures for armv8-a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58172 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-21 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Furthermore, reworking the testcase for thumb-ifcvt.c shows that some legitimate cases are now being missed, such as lslc Ld, Ln, #1.
[Bug fortran/58175] [F03] Incorrect warning message on scalar finalizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic CC||janus at gcc dot gnu.org Summary|Incorrect warning message |[F03] Incorrect warning |on scalar finalizer |message on scalar finalizer --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #1) Untested patch. ... indeed seems to fix the problem.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #190 from Jan Hubicka hubicka at ucw dot cz --- /ssd/firefox/js/src/gc/Marking.cpp: In function ???js::gc::IsAboutToBeFinalizedJSAtom(JSAtom**)bool [clone .isra.65]???: /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: profile data is not flow-consistent } ^ /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 3-6 thought to be -81 This actually loks like corruption from concurent updates (profiling is not thread safe). Do you get much more of these? I can imagine that garbage collector runs in parrallel and often. /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info: number of executions for edge 3-4 thought to be 39667 Perhaps we should fix dumping to dump full 64bit value.. :) Honza
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||janus at gcc dot gnu.org Summary|ICE with warnings and |[OOP] ICE when calling |unlimited polymorphic |SIZEOF on an unlimited ||polymorphic variable --- Comment #5 from janus at gcc dot gnu.org --- The ICE on comment 1 seems to be due to the SIZEOF call. Reduced test case: subroutine add_element_poly(e) class(*) :: e print *, sizeof(e) end subroutine Fails with 4.8 and current trunk.
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #14 from Phil Muldoon pmuldoon at redhat dot com --- It should be fixed for all cases in the PR. I think we can close it, and if any of the people commenting on this bug have issues, they can reopen it. My pmuld...@redhat.com account does not have sufficient privileges to alter the state of the bug, or the assignee. (Though I did not try with my gcc.gnu.org account)
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #15 from Marek Polacek mpolacek at gcc dot gnu.org --- With your gcc.gnu.org account it should work.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) The ICE on comment 1 seems to be due to the SIZEOF call. ... which is basically because SIZEOF is supposed to return the size of the declared type, and a CLASS(*) doesn't really have a declared type, cf. also http://gcc.gnu.org/onlinedocs/gfortran/SIZEOF.html Of course SIZEOF is a GNU extension, so we are free to define its behavior in any way we please. I don't remember why it was chosen to take the size of the declared type back in the day. When it was implemented for polymorphics, CLASS(*) was not yet available in gfortran. One way out: You could use STORAGE_SIZE, which is standard F08 and returns the size of the *dynamic* type. Also it seems to work well with CLASS(*). In any case the ICE should be fixed by one of the following approaches: 1) reject SIZEOF on CLASS(*) 2) make it return 0 for CLASS(*) 3) make it return the size of the dynamic type Option #3 is probably what you were expecting, right? I don't see any reason for not going this route, except that changing behavior is bad in general. But if it fixes an ICE, I guess it's not that bad after all ...
[Bug fortran/57798] [4.8/4.9 Regression] Incorrect handling of sum over first dimension of a product of automatic arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57798 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortr ||an/2013-08/msg00059.html --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org --- Patch submitted: http://gcc.gnu.org/ml/fortran/2013-08/msg00059.html
[Bug bootstrap/58206] [4.9 Regression] AIX bootstrap broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58206 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target||powerpc-ibm-aix* CC||law at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Build||powerpc*-*-* --- Comment #3 from David Edelsohn dje at gcc dot gnu.org --- This is caused by Rerun df_analyze after delete_unmarked_insns during DCE r201886.
[Bug target/58166] ARMv5: poor register allocation in function containing smull instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-21 Known to work||4.7.4 Ever confirmed|0 |1 Known to fail||4.8.2, 4.9.0 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Confirmed, used to do the right thing in gcc-4.7.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #7 from janus at gcc dot gnu.org --- Created attachment 30682 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30682action=edit patch Here is a preliminary patch to make SIZEOF return the size of the dynamic type for polymorphic variables, which at the same time fixes the ICE on CLASS(*) variables.
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Richard Earnshaw rearnsha at gcc dot gnu.org --- As Mikael says, this is undefined behaviour.
[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786 --- Comment #13 from janus at gcc dot gnu.org --- (In reply to janus from comment #11) Apparently it is due to r201329 (for PR 57530), in particular the interface.c part. However, reverting this via Index: gcc/fortran/interface.c === --- gcc/fortran/interface.c(revision 201883) +++ gcc/fortran/interface.c(working copy) @@ -514,12 +514,6 @@ compare_type (gfc_symbol *s1, gfc_symbol *s2) if (s2-attr.ext_attr (1 EXT_ATTR_NO_ARG_CHECK)) return 1; - /* TYPE and CLASS of the same declared type are type compatible, - but have different characteristics. */ - if ((s1-ts.type == BT_CLASS s2-ts.type == BT_DERIVED) - || (s1-ts.type == BT_DERIVED s2-ts.type == BT_CLASS)) -return 0; - return gfc_compare_types (s1-ts, s2-ts) || s2-ts.type == BT_ASSUMED; } results in these testsuite failures: FAIL: gfortran.dg/proc_ptr_30.f90 -O (test for errors, line 25) FAIL: gfortran.dg/proc_ptr_comp_32.f90 -O (test for errors, line 34) FAIL: gfortran.dg/proc_ptr_comp_33.f90 -O (test for errors, line 14) FAIL: gfortran.dg/proc_ptr_comp_33.f90 -O (test for errors, line 54) FAIL: gfortran.dg/dummy_procedure_4.f90 -O (test for errors, line 28)
[Bug target/57432] A mistake was appeared,when I build u-boot (arm-none-linux-gnueabi-gcc: Internal error: Bus error (program cc1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57432 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- gcc-4.4 is no longer maintained. If this still happens on a recent version of gcc (currently gcc-4.7 or later), please create a new bug report with a testcase that we can use to investigate the problem.
[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786 --- Comment #14 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #12) I still get the errors pr48786_2.f90:132.46: generic, public :: operator(+) = add_vector 1 Error: 'add_vector_3d' and 'add_vector_2d' for GENERIC '+' at (1) are ambiguous [...] with the test in http://gcc.gnu.org/ml/fortran/2011-04/msg00293.html at r201817 or 4.8.1. [...] Is this a bug or the expected behavior? The test case you refer to is the one from comment 2 and, as I mentioned, the behavior did not change for this one (according to previous evaluations in this PR the behavior is correct).
[Bug fortran/56378] [4.7/4.8 Regression] ICE with C_LOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56378 --- Comment #12 from janus at gcc dot gnu.org --- (In reply to Joost VandeVondele from comment #10) Fixed on trunk (4.9.0): ... by r197053, apparently. Since this looks way too large for backporting, I guess it will not be fixed on the 4.7 and 4.8 branches, right?
[Bug fortran/53801] gfortran warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53801 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) Could we close this PR as INVALID? Yes. Obviously not a gfortran bug ...
[Bug c++/58211] New: gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58211 Bug ID: 58211 Summary: gcc: internal compiler error: Segmentation fault (program as) Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reuveng at ectel dot com Error Message:on server AIX 6.1 oslevel - 6100-06-0501115 gcc -c Hello.cpp -o Hello.o gcc: internal compiler error: Segmentation fault (program as) Please submit a full bug report, with preprocessed source if appropriate.
[Bug target/58166] ARMv5: poor register allocation in function containing smull instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166 Jay Foad jay.foad at gmail dot com changed: What|Removed |Added Known to fail||4.8.0 --- Comment #2 from Jay Foad jay.foad at gmail dot com --- I've just built 4.8.0 from a source tarball and I see the same problem.
[Bug c++/58211] gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58211
Reuven reuveng at ectel dot com changed:
What|Removed |Added
Severity|normal |critical
--- Comment #1 from Reuven reuveng at ectel dot com ---
the program with constructor failed:
gcc -v -c Hello.cpp -o Hello.o
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/freeware/libexec/gcc/powerpc-ibm-aix6.1.0.0/4.6.2/lto-wrapper
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../gcc-4.6.2/configure --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran --prefix=/opt/freeware
--mandir=/opt/freeware/man --infodir=/opt/freeware/info --enable-threads
--enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd
--host=powerpc-ibm-aix6.1.0.0
Thread model: aix
gcc version 4.6.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'Hello.o'
/opt/freeware/libexec/gcc/powerpc-ibm-aix6.1.0.0/4.6.2/cc1plus -quiet -v
-D_ALL_SOURCE -D__COMPATMATH__ Hello.cpp -quiet -dumpbase Hello.cpp
-auxbase-strip Hello.o -version -o /tmp//ccyvIkUj.s
GNU C++ (GCC) version 4.6.2 (powerpc-ibm-aix6.1.0.0)
compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
warning: MPC header version 0.8.1 differs from library version 0.9.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.6.2/../../../../powerpc-ibm-aix6.1.0.0/include
#include ... search starts here:
#include ... search starts here:
/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.6.2/include/c++
/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.6.2/include/c++/powerpc-ibm-aix6.1.0.0
/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.6.2/include/c++/backward
/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.6.2/include
/opt/freeware/include
/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.6.2/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.6.2 (powerpc-ibm-aix6.1.0.0)
compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
warning: MPC header version 0.8.1 differs from library version 0.9.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 01a60e2afad33d9ba418b53aa218b625
COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'Hello.o'
/usr/bin/as -u -mppc -o Hello.o /tmp//ccyvIkUj.s
gcc: internal compiler error: Segmentation fault (program as)
program:Hello.cpp
class Token
{
public:
Token();
};
int main()
{
return 0;
}
Token::Token()
{
}
[Bug c++/58212] New: gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58212 Bug ID: 58212 Summary: gcc: internal compiler error: Segmentation fault (program as) Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reuveng at ectel dot com
[Bug c++/58211] gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58211 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- This is not a gcc bug, it is the assembler that is crashing. Report that to whoever provided you the assembler.
[Bug c++/58213] New: gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58213 Bug ID: 58213 Summary: gcc: internal compiler error: Segmentation fault (program as) Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reuveng at ectel dot com
[Bug c++/58214] New: gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58214 Bug ID: 58214 Summary: gcc: internal compiler error: Segmentation fault (program as) Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reuveng at ectel dot com
[Bug c++/58213] gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58213 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 58211 ***
[Bug c++/58212] gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58212 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 58211 ***
[Bug c++/58211] gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58211 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 58213 has been marked as a duplicate of this bug. ***
[Bug c++/58211] gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58211 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 58212 has been marked as a duplicate of this bug. ***
[Bug c++/58214] gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58214 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 58211 ***
[Bug c++/58211] gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58211 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 58214 has been marked as a duplicate of this bug. ***
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) Here is a preliminary patch to make SIZEOF return the size of the dynamic type for polymorphic variables, which at the same time fixes the ICE on CLASS(*) variables. Of course this fails on storage_size_1, which expects the old behavior for CLASS variables, but otherwise it regtests cleany. Index: gcc/testsuite/gfortran.dg/storage_size_1.f08 === --- gcc/testsuite/gfortran.dg/storage_size_1.f08(revision 201896) +++ gcc/testsuite/gfortran.dg/storage_size_1.f08(working copy) @@ -25,7 +25,7 @@ if (storage_size(a) /= 64) call abort() if (sizeof(b)/= 24) call abort() if (storage_size(b) /= 64) call abort() -if (sizeof(cp) /= 8) call abort() +if (sizeof(cp) /= 12) call abort() if (storage_size(cp) /= 96) call abort() end
[Bug c++/58211] gcc: internal compiler error: Segmentation fault (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58211 --- Comment #6 from Reuven reuveng at ectel dot com --- (In reply to Andreas Schwab from comment #2) This is not a gcc bug, it is the assembler that is crashing. Report that to whoever provided you the assembler. You mean open bug for IBM provider.
[Bug target/56979] ICE in output_operand: invalid operand for code 'P'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.4 --- Comment #7 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Also fixed on 4.7 and 4.8: 4.7: r201904 4.8: r201903
[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Version|unknown |4.8.0 Last reconfirmed||2013-08-21 Component|middle-end |tree-optimization CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Summary|wrong code at -O3 on|[4.8/4.9 regression] wrong |x86_64-linux-gnu|code at -O3 Target Milestone|--- |4.8.2
[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- That patch looks wrong, and would very likely penalize tons of code, this predicate is used in many places in the compiler and the operations don't trap.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #9 from janus at gcc dot gnu.org ---
And of course the changed behavior should be reflected in the documentation:
Index: gcc/fortran/intrinsic.texi
===
--- gcc/fortran/intrinsic.texi(revision 201896)
+++ gcc/fortran/intrinsic.texi(working copy)
@@ -11546,7 +11546,7 @@ number of bytes occupied by the argument. If the
to is returned. If the argument is of a derived type with @code{POINTER}
or @code{ALLOCATABLE} components, the return value does not account for
the sizes of the data pointed to by these components. If the argument is
-polymorphic, the size according to the declared type is returned. The argument
+polymorphic, the size according to the dynamic type is returned. The argument
may not be a procedure or procedure pointer.
@item @emph{Example}:
[Bug bootstrap/58206] [4.9 Regression] AIX bootstrap broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58206 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law law at redhat dot com --- Patch reverted per the c#1 from 57940 which makes it clear this patch is incorrect.
[Bug c++/56130] __attribute__((deprecated)) does not affect C++ reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56130 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0 (r201906)
[Bug c++/58072] [C++11] Error messages involving user-defined literals are poor (refer to tokens)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58072 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- This can be closed as fixed.
[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
--- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #8)
That patch looks wrong, and would very likely penalize tons of code, this
predicate is used in many places in the compiler and the operations don't
trap.
yes, thanks, I agree.
This means then the lim pass (and probably others like ifcvt too)
will move code out of the inner loop, as long as it does not trap.
But this creates undefined results, and that should not be used by the
loop optimization to throw away the loop termination code.
In this case I'd say the only other simple solution will be to take
out the function infer_loop_bounds_from_signedness() completely
at tree-ssa-loop-niter.c, right?
To illustrate what this function can do here is another example:
loop.c:
extern int bar ();
int
foo ()
{
int i, k;
for (i=0; i4; i++)
{
k=10*i;
if (bar ())
break;
}
return k;
}
if you compile this function with -O3 the resulting code is
very surprising (with zero warnings):
foo:
.LFB0:
.cfi_startproc
subl$12, %esp
.cfi_def_cfa_offset 16
callbar
testl %eax, %eax
jne .L3
callbar
testl %eax, %eax
.p2align 4,,4
jne .L4
.p2align 4,,6
callbar
movl$20, %eax
.L2:
addl$12, %esp
.cfi_remember_state
.cfi_def_cfa_offset 4
ret
.p2align 4,,7
.p2align 3
.L3:
.cfi_restore_state
xorl%eax, %eax
jmp .L2
.p2align 4,,7
.p2align 3
.L4:
movl$10, %eax
jmp .L2
Due to the fact, that k will overflow at the forth iteration,
the loop is terminated at the third iteration!
The reasoning is that the only way to prevent the undefined
behaviour of k, one of the first tree invocations of bar must
terminate the loop, and thus the loop is only unrolled 3 times.
But if the loop is a bit more complex it will not be unrolled,
and in this case the normal loop termination conditin i4
will not be used at all, resulting in an endless loop.
To prevent the loop unrolling I can add a printf:
loop.c:
extern int bar ();
int
foo ()
{
int i, k;
for (i=0; i4; i++)
{
k=10*i;
__builtin_printf(loop %d\n, i);
if (bar ())
break;
}
return k;
}
Now this is an endless loop (bar always returns 0 but the
compiler does not know)!
foo:
.LFB0:
.cfi_startproc
pushl %ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
xorl%ebx, %ebx
subl$24, %esp
.cfi_def_cfa_offset 32
.L2:
movl%ebx, 4(%esp)
movl$.LC0, (%esp)
callprintf
callbar
testl %eax, %eax
jne .L6
addl$1, %ebx
.p2align 4,,3
jmp .L2
.p2align 4,,7
.p2align 3
.L6:
addl$24, %esp
.cfi_def_cfa_offset 8
imull $10, %ebx, %eax
popl%ebx
.cfi_restore 3
.cfi_def_cfa_offset 4
ret
.cfi_endproc
[Bug c/50584] No warning for passing small array to C99 static array declarator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- The point of this language feature is for optimization, not diagnostics - but there is no requirement for either; GCC does all the checks required by C99 on the contexts in which [static] may be used. c99status.html specifically notes that it is not used for optimization.
