[Bug driver/52556] Ability to change GLIBC_DYNAMIC_LINKER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556
--- Comment #5 from Benda Xu heroxbd at sohu dot com ---
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=.} %fdump-final-insns,
DRIVER_SELF_SPECS, CONFIGURE_SPECS, GOMP_SELF_SPECS, GTM_SELF_SPECS
};
so it is a list of specs for the driver *itself*, should not be used to specify
link spec.
If you mean passing --with-specs=-Wl,-dynamic-linker=/whatever/ld.so to
configure, it is broken in multilib cases.
Therefore we lack of a convenient way to specify a default alternative location
of the dynamic linker.
Benda
[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
[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 ubizjak at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Adding CC.
[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 Jan Hubicka hubicka at gcc dot gnu.org 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 hubicka at gcc dot gnu.org --- 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 --- 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 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 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::Foov::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 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 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 ubizjak at gmail dot com --- Another similar bootstrap failure in final.c [1]. [1] http://gcc.gnu.org/ml/gcc-regression/2013-08/msg00278.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=30670action=edit patch Here is a regression-free patch which gets rid of the ICE.
[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 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 iains at gcc dot gnu.org --- (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. snip ... seems plausible, will try it on my next build cycle. #if defined(HAVE_CC_TLS) !defined (USE_EMUTLS) does, indeed, work.
[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 paolo.carlini at oracle dot com changed: What|Removed |Added CC||dragonroot at gmail dot com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 58187 has been marked as a duplicate of this bug. ***
[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 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 57887 ***
[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 hubicka at ucw dot cz --- 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++/58178] variant function name was used for user defined constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-08-18 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Indeed. Please provide information about your target, thanks.
[Bug c++/58176] ICE in output_constant, at varasm.c:4658
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58176 Paolo Carlini paolo.carlini at oracle dot com 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 paolo.carlini at oracle dot com --- Doesn't look like a regression. I'm anyway adding Jason in CC, the issue seems subtle.
[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 dominiq at lps dot ens.fr --- #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++/58184] Pointer to overloaded function is non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58184 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- The same problem exists for gcc 4.9.0 HEAD
[Bug target/53976] [SH] Unnecessary clrt after bt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976 --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org --- 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 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 abensonca at gmail dot com --- You're absolutely correct - my mistake!
[Bug fortran/58177] Incorrect warning message about unused PRIVATE module variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58177 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org --- Closing, then. Do keep these bug reports, coming, though :-)
[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 tkoenig at gcc dot gnu.org --- It might actually be better to move calling arith_error to resolution stage.
[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 iains at gcc dot gnu.org --- (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 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 iains at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org --- 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 #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- thus fixed. Thanks!
[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 jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Sun Aug 18 15:23:24 2013 New Revision: 201827 URL: http://gcc.gnu.org/viewcvs?rev=201827root=gccview=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=201828root=gccview=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 fortran/58189] Color diagnostics for gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58189 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- See also PR44054 about re-using the middle-end infrastructure
[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 burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- My impression is that -Werror= is not properly supported by gfortran - only -Werror by itself. (See also PR44054.)
[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 burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (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 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 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::vectorint 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_iteratorint (*)(int),
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
std::__cxx1998::vectorint, std::allocatorint , std::__debug::vectorint
, 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_iteratorint (*)(int),
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
std::__cxx1998::vectorint, std::allocatorint , std::__debug::vectorint
, 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_iteratorint (*)(int),
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
std::__cxx1998::vectorint, std::allocatorint , std::__debug::vectorint
, boost::use_default, boost::use_default, boost::transform_iteratorint
(*)(int), __gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
std::__cxx1998::vectorint, std::allocatorint , std::__debug::vectorint
, boost::use_default, boost::use_default, const int,
std::iterator_traitsboost::transform_iteratorint (*)(int),
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
std::__cxx1998::vectorint, std::allocatorint , std::__debug::vectorint
, 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: templateclass
_ForwardIterator, class _Tp 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_categoryboost::transform_iteratorint (*)(int),
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
std::__cxx1998::vectorint, std::allocatorint , std::__debug::vectorint
, boost::use_default, boost::use_default ((*(const
boost::transform_iteratorint (*)(int),
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
std::__cxx1998::vectorint, std::allocatorint , std::__debug::vectorint
, boost::use_default, boost::use_default*)( __first)))’ (type
‘std::iterator_traitsboost::transform_iteratorint (*)(int),
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
std::__cxx1998::vectorint, std::allocatorint , std::__debug::vectorint
, boost::use_default, boost::use_default ::iterator_category {aka
boost::detail::iterator_category_with_traversalstd::input_iterator_tag,
boost::random_access_traversal_tag}’) to type ‘std::forward_iterator_tag’
std::__iterator_category(__first));
^
/usr/include/c++/4.8/debug/functions.h:412:5: note: templateclass _Iterator,
class _Sequence, class _Tp 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_iteratorint (*)(int),
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
std::__cxx1998::vectorint, std::allocatorint ,
[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 woodroof at gmail dot com --- Created attachment 30671 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30671action=edit Preprocessed file archive
