[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 --- Comment #2 from Kenton Varda --- Note: Both the Ubuntu and Cygwin systems were x86_64. I don't know if the problem occurs in 32-bit mode.
[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 --- Comment #1 from Kenton Varda --- Created attachment 30672 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30672&action=edit Demonstration of enum class passing bug
[Bug c++/58192] New: G++ emits incorrect code when passing enum classes as function parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 Bug ID: 58192 Summary: G++ emits incorrect code when passing enum classes as function parameters Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: temporal at gmail dot com Demonstration attached. It repros with g++ 4.8.1 (tested on Ubuntu and Cygwin). I think I saw similar problems with g++ 4.7.3, but this particular test case does not seem to repro with it.
[Bug c++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 --- Comment #1 from Danil Ilinykh --- Created attachment 30671 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30671&action=edit Preprocessed file archive
[Bug c++/58191] New: Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191
Bug ID: 58191
Summary: Can't use boost transform_iterator with _GLIBCXX_DEBUG
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: woodroof at gmail dot com
Given:
A simple code:
int calc_value(int original_value)
{
return original_value % 3;
}
int main()
{
std::vector numbers;
std::upper_bound(
boost::make_transform_iterator(numbers.begin(), calc_value),
boost::make_transform_iterator(numbers.end(), calc_value),
1);
}
Gcc version: g++ (Ubuntu 4.8.1-2ubuntu1~13.04) 4.8.1
Additional command line params: -D_GLIBCXX_DEBUG
Result: Compilation error
In file included from /usr/include/c++/4.8/debug/debug.h:127:0,
from /usr/include/c++/4.8/bits/stl_iterator_base_funcs.h:65,
from /usr/include/c++/4.8/bits/stl_algobase.h:66,
from /usr/include/c++/4.8/vector:60,
from 1.cpp:1:
/usr/include/c++/4.8/debug/functions.h: In instantiation of ‘bool
__gnu_debug::__check_partitioned_upper(_ForwardIterator, _ForwardIterator,
const _Tp&) [with _ForwardIterator = boost::transform_iterator > >, std::__debug::vector
>, boost::use_default, boost::use_default>; _Tp = int]’:
/usr/include/c++/4.8/bits/stl_algo.h:2506:358: required from ‘_FIter
std::upper_bound(_FIter, _FIter, const _Tp&) [with _FIter =
boost::transform_iterator > >, std::__debug::vector
>, boost::use_default, boost::use_default>; _Tp = int]’
1.cpp:16:4: required from here
/usr/include/c++/4.8/debug/functions.h:428:42: error: no matching function for
call to ‘__check_partitioned_upper_aux(boost::transform_iterator > >, std::__debug::vector
>, boost::use_default, boost::use_default>&, boost::transform_iterator > >, std::__debug::vector
>, boost::use_default, boost::use_default>&, const int&,
std::iterator_traits > >, std::__debug::vector
>, boost::use_default, boost::use_default> >::iterator_category)’
std::__iterator_category(__first));
^
/usr/include/c++/4.8/debug/functions.h:428:42: note: candidates are:
/usr/include/c++/4.8/debug/functions.h:393:5: note: template bool
__gnu_debug::__check_partitioned_upper_aux(_ForwardIterator, _ForwardIterator,
const _Tp&, std::forward_iterator_tag)
__check_partitioned_upper_aux(_ForwardIterator __first,
^
/usr/include/c++/4.8/debug/functions.h:393:5: note: template argument
deduction/substitution failed:
/usr/include/c++/4.8/debug/functions.h:428:42: note: cannot convert
‘std::__iterator_category > >, std::__debug::vector
>, boost::use_default, boost::use_default> >((*(const
boost::transform_iterator > >, std::__debug::vector
>, boost::use_default, boost::use_default>*)(& __first)))’ (type
‘std::iterator_traits > >, std::__debug::vector
>, boost::use_default, boost::use_default> >::iterator_category {aka
boost::detail::iterator_category_with_traversal}’) to type ‘std::forward_iterator_tag’
std::__iterator_category(__first));
^
/usr/include/c++/4.8/debug/functions.h:412:5: note: template bool
__gnu_debug::__check_partitioned_upper_aux(const
__gnu_debug::_Safe_iterator<_Iterator, _Sequence>&, const
__gnu_debug::_Safe_iterator<_Iterator, _Sequence>&, const _Tp&,
std::random_access_iterator_tag)
__check_partitioned_upper_aux(
^
/usr/include/c++/4.8/debug/functions.h:412:5: note: template argument
deduction/substitution failed:
/usr/include/c++/4.8/debug/functions.h:428:42: note:
‘boost::transform_iterator > >, std::__debug::vector
>, boost::use_default, boost::use_default>’ is not derived from ‘const
__gnu_debug::_Safe_iterator<_Iterator, _Sequence>’
std::__iterator_category(__first));
^
/usr/include/c++/4.8/debug/functions.h:498:5: note: template bool
__gnu_debug::__check_partitioned_upper_aux(const
__gnu_debug::_Safe_iterator<_Iterator, _Sequence>&, const
__gnu_debug::_Safe_iterator<_Iterator, _Sequence>&, const _Tp&, _Pred,
std::random_access_iterator_tag)
__check_partitioned_upper_aux(
^
/usr/include/c++/4.8/debug/functions.h:498:5: note: template argument
deduction/substitution failed:
/usr/include/c++/4.8/debug/functions.h:428:42: note:
‘boost::transform_iterator > >, std::__debug::vector
>, boost::use_default, boost::use_default>’ is not derived from ‘const
__gnu_debug::_Safe_iterator<_Iterator, _Sequence>’
std::__iterator_category(__first));
^
/usr/include/c++/4.8/debug/functions.h:477:5: note: template bool
__gnu_debug::__check_partitioned_upper_aux(_ForwardIterator, _ForwardIterator,
const _Tp&, _Pred, std::forward_iterator_tag)
__check_partitioned_upper_aux(_ForwardIterator __first,
^
/usr/include/c++/4.8/debug/functions
[Bug c++/58190] New: FAIL: g++.dg/pr57878.C (test for excess errors) on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58190
Bug ID: 58190
Summary: FAIL: g++.dg/pr57878.C (test for excess errors) on
x86_64-apple-darwin10
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, vmakarov at redhat dot com
Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
Build: x86_64-apple-darwin10
The test FAIL: g++.dg/pr57878.C (introduced at r 201036) fails on
x86_64-apple-darwin10 with
/opt/gcc/work/gcc/testsuite/g++.dg/pr57878.C:27:53: error: 'operator new' takes
type 'size_t' ('long unsigned int') as first parameter [-fpermissive]
inline void* operator new(std::size_t, void* __p) noexcept {
I get the error with older versions of g++, e.g., 4.8.1, and with -m32 and
-m64.
[Bug fortran/58100] Spurious "DO loop at (1) will be executed zero times" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58100 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #1) > Still present after r201658 (pr5, after it -Wall is needed). With that patch, -W(no-)zerotrip permits to toggle the warning, which I think it sufficient. Everything else requires more analysis (e.g. the "if"'s else branch is never executed in this case), which I believe is not worthwhile. Roland: Is the new warning option -W(no-)zerotrip sufficient for you? (Side remark: there are conflicts with early optimization: For debugging, no folding/simplification should be done by front-ends. On the other hand, some simplification is useful - and the ME is too late for it.]
[Bug fortran/57924] -Werror -Warray-temporaries -Wno-error=array-temporaries fails on array temporary warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57924 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- My impression is that -Werror= is not properly supported by gfortran - only -Werror by itself. (See also PR44054.)
[Bug fortran/58189] Color diagnostics for gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58189 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- See also PR44054 about re-using the middle-end infrastructure
[Bug tree-optimization/58006] [4.8/4.9 Regression] ICE compiling VegaStrike with -ffast-math -ftree-parallelize-loops=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58006 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Sun Aug 18 15:23:24 2013 New Revision: 201827 URL: http://gcc.gnu.org/viewcvs?rev=201827&root=gcc&view=rev Log: PR tree-optimization/58006 * tree-parloops.c (take_address_of): Don't ICE if get_name returns NULL. (eliminate_local_variables_stmt): Remove clobber stmts. * g++.dg/opt/pr58006.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr58006.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c Author: jakub Date: Sun Aug 18 15:24:12 2013 New Revision: 201828 URL: http://gcc.gnu.org/viewcvs?rev=201828&root=gcc&view=rev Log: PR tree-optimization/58006 * tree-parloops.c (take_address_of): Don't ICE if get_name returns NULL. (eliminate_local_variables_stmt): Remove clobber stmts. * g++.dg/opt/pr58006.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/opt/pr58006.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-parloops.c
[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127 --- Comment #11 from Dominique d'Humieres --- > thus fixed. Thanks!
[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Iain Sandoe --- thus fixed.
[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127 --- Comment #9 from Iain Sandoe --- (In reply to Jan Hubicka from comment #7) > > > > that's kind of a pity, since IIRC one of the main reasons for recasting the > > emutls implementation as a separate pass was to allow for uses like this; > > but, having said that, probably not a high priority. > MThere are performance implications of doing so. One way would be to add > facility to insert new variables into emutls late (it is probably doable). > Other easy way around would be to add gcov function to set both pointers to > proper values and do it as function call. > > I am not sure if this is feasible performance wise - the counter is in TLS > just to avoid too many colisions. Generally profiling should work resonably > well even without TLS for that. ack, let's not pursue that then. > If you do have chance to commit it, consider the patch preapproved. applied as 201829 libgcc: PR gcov-profile/58127 * libgcov.c (__gcov_indirect_call_callee): Don't make this a __thread var for emulated TLS. (__gcov_indirect_call_counters): Likewise.
[Bug fortran/58027] "Arithmetic overflow converting ..." in PARAMETER triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027 --- Comment #2 from Thomas Koenig --- It might actually be better to move calling arith_error to resolution stage.
[Bug fortran/58177] Incorrect warning message about unused PRIVATE module variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58177 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Thomas Koenig --- Closing, then. Do keep these bug reports, coming, though :-)
[Bug fortran/58177] Incorrect warning message about unused PRIVATE module variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58177 --- Comment #2 from Andrew Benson --- You're absolutely correct - my mistake!
[Bug target/53976] [SH] Unnecessary clrt after bt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976 --- Comment #4 from Oleg Endo --- One option to get rid of the redundant clrt and sett in BBs that are reached with a conditional branch would be to add an SH specific RTL pass that analyses the BBs and eliminates the insns in question. Another option could be to try and inject artificial sett / clrt insns at the start of BBs that are reached by conditional branches, and then split them away to nops or output empty asm with insn length 0. The idea would be to let other already existing RTL passes figure out the redundant T bit sets. There is already a similar functionality in cse.c (cse_condition_code_reg), but it probably wouldn't kick in, since clrt / sett insns are emitted until the split1 pass before register allocation and cse2 runs before that. But still, maybe another RTL pass would figure it out. It doesn't necessarily need to be before register allocation, since the T bit is a hard-reg anyway.
[Bug c++/58184] Pointer to overloaded function is non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58184 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- The same problem exists for gcc 4.9.0 HEAD
[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127 --- Comment #8 from Dominique d'Humieres --- > > #if defined(HAVE_CC_TLS) && !defined (USE_EMUTLS) > > does, indeed, work. I have done a clean bootstrap with --- ../_clean/libgcc/libgcov.c2013-08-11 13:28:22.0 +0200 +++ libgcc/libgcov.c2013-08-18 12:30:01.0 +0200 @@ -1162,11 +1162,11 @@ __gcov_indirect_call_profiler (gcov_type The variables are set directly by GCC instrumented code, so declaration here must match one in tree-profile.c */ -#ifdef HAVE_CC_TLS +#if defined(HAVE_CC_TLS) && !defined (USE_EMUTLS) __thread #endif void * __gcov_indirect_call_callee; -#ifdef HAVE_CC_TLS +#if defined(HAVE_CC_TLS) && !defined (USE_EMUTLS) __thread #endif gcov_type * __gcov_indirect_call_counters; and the failures for gcc.dg/tree-prof/* and g++.dg/tree-prof/* are gone. Thanks.
[Bug c++/58176] ICE in output_constant, at varasm.c:4658
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58176 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-18 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Doesn't look like a regression. I'm anyway adding Jason in CC, the issue seems subtle.
[Bug c++/58178] variant function name was used for user defined constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-08-18 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini --- Indeed. Please provide information about your target, thanks.
[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127 --- Comment #7 from Jan Hubicka --- > > that's kind of a pity, since IIRC one of the main reasons for recasting the > emutls implementation as a separate pass was to allow for uses like this; > but, having said that, probably not a high priority. MThere are performance implications of doing so. One way would be to add facility to insert new variables into emutls late (it is probably doable). Other easy way around would be to add gcov function to set both pointers to proper values and do it as function call. I am not sure if this is feasible performance wise - the counter is in TLS just to avoid too many colisions. Generally profiling should work resonably well even without TLS for that. > > #if defined(HAVE_CC_TLS) && !defined (USE_EMUTLS) > > does, indeed, work. If you do have chance to commit it, consider the patch preapproved. I will be offline during the afternoon. Honza
[Bug c++/58187] Initialization of a non-static data member using a template argument doesn't work when the template is inside of another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58187 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini --- Dup. *** This bug has been marked as a duplicate of bug 57887 ***
[Bug c++/57887] nested non-type template parameters not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57887 Paolo Carlini changed: What|Removed |Added CC||dragonroot at gmail dot com --- Comment #1 from Paolo Carlini --- *** Bug 58187 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127 --- Comment #6 from Iain Sandoe --- (In reply to Iain Sandoe from comment #5) > (In reply to Jan Hubicka from comment #4) > > The secret plan was to not use TLS for emutls. that's kind of a pity, since IIRC one of the main reasons for recasting the emutls implementation as a separate pass was to allow for uses like this; but, having said that, probably not a high priority. > > There seems to be macro USE_EMUTLS specifying if we have real TLS or emuTLS. > ... seems plausible, will try it on my next build cycle. #if defined(HAVE_CC_TLS) && !defined (USE_EMUTLS) does, indeed, work.
[Bug fortran/58189] New: Color diagnostics for gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58189 Bug ID: 58189 Summary: Color diagnostics for gfortran Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org The upcoming GCC release 4.9 will support colorized diagnostics, which already works in the C/C++ front ends (-fdiagnostics-color). gfortran does not yet support this, but this PR should remind us to implement it before the release. Some links: * http://gcc.gnu.org/gcc-4.9/changes.html * http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html#Language-Independent-Options * http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00767.html
[Bug fortran/58185] [4.8/4.9 Regression] [OOP] ICE when selector in SELECT TYPE is non-polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58185 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 #3 from janus at gcc dot gnu.org --- Created attachment 30670 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30670&action=edit patch Here is a regression-free patch which gets rid of the ICE.
[Bug bootstrap/58186] LTO profiledbootstrap fails in stage feedback for fortran/frontend-passes.c with "edge ... has no corresponding call_stmt"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58186 --- Comment #3 from Uroš Bizjak --- Another similar bootstrap failure in final.c [1]. [1] http://gcc.gnu.org/ml/gcc-regression/2013-08/msg00278.html
[Bug fortran/58177] Incorrect warning message about unused PRIVATE module variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58177 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org --- (In reply to Andrew Benson from comment #0) > module a > logical :: m > end module a > module b > logical, private :: m > contains > subroutine bb() > use a > m=.true. > end subroutine bb > end module b > > [...] > > logical, private :: m > >1 > Warning: Unused PRIVATE module variable 'm' declared at (1) AFAICS the warning is correct: Your USE statement imports all public symbols from module a, including 'm'. Therefore the 'm' from 'a' is used and not the 'm' from 'b'. The same is achieved by explicitly importing 'm' via use a, only: m which gives the same warning (correctly, I would say). Or am I missing something here?
[Bug c++/58188] New: ICE in gimple_add_tmp_var, at gimplify.c:738
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58188
Bug ID: 58188
Summary: ICE in gimple_add_tmp_var, at gimplify.c:738
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dragonroot at gmail dot com
The following code causes an ICE:
test.cc =
struct B {};
struct A
{
A( B );
};
struct Bar
{
template< unsigned v >
struct Foo
{
A z = B();
unsigned value;
Foo(): value( v ) {}
};
struct Baz
{
Foo< 8 > foo1;
Foo< 1 > foo3;
};
};
Bar::Baz baz;
===
$ g++-4.8 -c -std=c++11 test.cc
test.cc: In constructor ‘Bar::Foo::Foo() [with unsigned int v = 1u]’:
test.cc:14:21: internal compiler error: in gimple_add_tmp_var, at
gimplify.c:738
Foo(): value( v ) {}
^
...
P.S. This might possibly be related to bug 58187.
[Bug c++/58187] New: Initialization of a non-static data member using a template argument doesn't work when the template is inside of another class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58187
Bug ID: 58187
Summary: Initialization of a non-static data member using a
template argument doesn't work when the template is
inside of another class
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dragonroot at gmail dot com
The following does not compile:
== test.cc =
struct Bar
{
template< unsigned v >
struct Foo
{
unsigned value = v;
};
};
$ g++-4.8 -c -std=c++11 test.cc
test.cc:6:22: error: ‘v’ was not declared in this scope
unsigned value = v;
^
$ g++-4.8 --version
g++-4.8 (Debian 4.8.1-9) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug fortran/58185] [4.8/4.9 Regression] [OOP] ICE when selector in SELECT TYPE is non-polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58185 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to janus from comment #1) > 0x567f7e copy_ts_from_selector_to_associate > /home/janus/gcc49/trunk/gcc/fortran/match.c:5171 I think this is where the problem is. This function should be fixed to not call gfc_build_class_symbol with ts->u.derived == NULL.
[Bug bootstrap/58186] LTO profiledbootstrap fails in stage feedback for fortran/frontend-passes.c with "edge ... has no corresponding call_stmt"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58186 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-08-18 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jan Hubicka --- mine...
[Bug fortran/58185] [4.8/4.9 Regression] [OOP] ICE when selector in SELECT TYPE is non-polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58185 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-18 CC||janus at gcc dot gnu.org Summary|ICE when selector in SELECT |[4.8/4.9 Regression] [OOP] |TYPE is non-polymorphic |ICE when selector in SELECT ||TYPE is non-polymorphic Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. Minimal test case: integer :: array select type (a => array) end select end With 4.7 this gives the correct error: select type (a => array) 1 Error: Selector shall be polymorphic in SELECT TYPE statement at (1) while 4.8 and trunk show an ICE with the following backtrace: f951: internal compiler error: Segmentation fault 0x8bb59f crash_signal /home/janus/gcc49/trunk/gcc/toplev.c:335 0x51c28c get_unique_type_string /home/janus/gcc49/trunk/gcc/fortran/class.c:466 0x51d566 get_unique_hashed_string /home/janus/gcc49/trunk/gcc/fortran/class.c:489 0x520ae6 gfc_build_class_symbol(gfc_typespec*, symbol_attribute*, gfc_array_spec**, bool) /home/janus/gcc49/trunk/gcc/fortran/class.c:583 0x567f7e copy_ts_from_selector_to_associate /home/janus/gcc49/trunk/gcc/fortran/match.c:5171 0x567f7e gfc_match_select_type() /home/janus/gcc49/trunk/gcc/fortran/match.c:5342
[Bug bootstrap/58186] LTO profiledbootstrap fails in stage feedback for fortran/frontend-passes.c with "edge ... has no corresponding call_stmt"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58186 Uroš Bizjak changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Uroš Bizjak --- Adding CC.
[Bug bootstrap/58186] New: LTO profiledbootstrap fails in stage feedback for fortran/frontend-passes.c with "edge ... has no corresponding call_stmt"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58186 Bug ID: 58186 Summary: LTO profiledbootstrap fails in stage feedback for fortran/frontend-passes.c with "edge ... has no corresponding call_stmt" Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com LTO profiled bootstrap of gcc, configured --with-build-config=bootstrap-lto --enable-languages=c,c++,fortran fails with: /home/uros/gcc-svn/trunk/gcc/fortran/frontend-passes.c:2149:1: error: edge gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*)->doloop_code(gfc_code**, int*, void*) has no corresponding call_stmt } ^ # .MEM_35 = VDEF <.MEM_32> result_36 = codefn_33(D) (c_1, &walk_subtrees, data_34(D)); _Z15gfc_code_walkerPP8gfc_codePFiS1_PiPvEPFiPP8gfc_exprS2_S3_ES3_/155 (gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*)) @0x7f4e4cf0aab0 Type: function definition analyzed Visibility: externally_visible public References: _ZL16in_omp_workshare/116 (read)_ZL12doloop_level/120 (read)_ZL12doloop_level/120 (write)_ZL12forall_level/115 (read)_ZL12forall_level/115 (write)_ZL16in_omp_workshare/116 (write)_ZL16in_omp_workshare/116 (write)_ZL12forall_level/115 (read)_ZL12forall_level/115 (write)_ZL12doloop_level/120 (read)_ZL12doloop_level/120 (write)_ZL16in_omp_workshare/116 (write)_ZL11doloop_codePP8gfc_codePiPv/151 (addr) (speculative) Referring: Availability: available Profile id: 839983705 Function flags: executed 100x body Called by: _Z14gfc_run_passesP13gfc_namespace/122 (100x) (1.00 per call) _ZL18optimize_namespaceP13gfc_namespace/136 (1.00 per call) _ZL18optimize_namespaceP13gfc_namespace/136 (1.00 per call) _ZL18optimize_namespaceP13gfc_namespace/136 (1.00 per call) _ZL18optimize_namespaceP13gfc_namespace/136 (1.00 per call) _ZL18optimize_reductionP13gfc_namespace/137 (1.00 per call) _Z15gfc_code_walkerPP8gfc_codePFiS1_PiPvEPFiPP8gfc_exprS2_S3_ES3_/155 _Z15gfc_code_walkerPP8gfc_codePFiS1_PiPvEPFiPP8gfc_exprS2_S3_ES3_/155 _Z15gfc_code_walkerPP8gfc_codePFiS1_PiPvEPFiPP8gfc_exprS2_S3_ES3_/155 Calls: _ZL11doloop_codePP8gfc_codePiPv/151 (speculative) (26x) (0.26 per call) _Z15gfc_code_walkerPP8gfc_codePFiS1_PiPvEPFiPP8gfc_exprS2_S3_ES3_/155 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 (26x) (0.26 per call) _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 (26x) (0.26 per call) _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 (26x) (0.26 per call) _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 (26x) (0.26 per call) _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES3_/154 _Z15gfc_expr_walkerPP8gfc_exprPFiS1_PiPvES
[Bug driver/52556] Ability to change GLIBC_DYNAMIC_LINKER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556
--- Comment #5 from Benda Xu ---
Dear Jakub,
I find your comment misleading for the --with-specs option.
It sets CONFIGURE_SPECS macro, which is used in gcc.c as
static const char *const driver_self_specs[] = {
"%{fdump-final-insns:-fdump-final-insns=.} %
