[Bug libfortran/61035] Crash in getcwd intrinsic due to stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61035 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Janne Blomqvist jb at gcc dot gnu.org --- Fixed, closing
[Bug preprocessor/61165] New: unfriendly diagnostic from macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61165
Bug ID: 61165
Summary: unfriendly diagnostic from macro expansion
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Consider this source:
extern void *allocate (int);
#define my_alloc(X) allocate (X)
int *alloc_int(void)
{
int *result = my_alloc(sizeof (int));
return result;
}
Now compile with -Wc++-compat:
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘alloc_int’:
r.c:3:21: warning: request for implicit conversion from ‘void *’ to ‘int *’ not
permitted in C++ [-Wc++-compat]
#define my_alloc(X) allocate (X)
^
r.c:7:17: note: in expansion of macro ‘my_alloc’
int *result = my_alloc(sizeof (int));
^
I find this a bit strange. The actual warning: line points to
the #define -- but here I think I would have expected this to
point to the call instead, with a note: pointing to the macro
definition.
[Bug preprocessor/61165] unfriendly diagnostic from macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61165
--- Comment #1 from Tom Tromey tromey at gcc dot gnu.org ---
Also, note what happens if one changes the body of the function:
extern void *allocate (int);
#define my_alloc(X) allocate (X)
int *alloc_int(void)
{
return my_alloc(sizeof (int));
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘alloc_int’:
r.c:7:3: warning: request for implicit conversion from ‘void *’ to ‘int *’ not
permitted in C++ [-Wc++-compat]
return my_alloc(sizeof (int));
^
Now there's no mention of the macro at all.
[Bug preprocessor/60858] 64-bit multi-character constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60858 --- Comment #2 from SwissP swissp2013 at gmail dot com --- Andrew, Also patches go to gcc-patches@ and should include a testcase or two. Not familiar with the bugzilla interface I could not find where gcc-patches@ resides on the site. Can you give me a link to the relevant resource? Thank you for your help!
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #4 from Tom Tromey tromey at gcc dot gnu.org ---
Note that it is also wrong in the initializer case.
enum e f(void)
{
enum e result = 0;
return result;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:5:8: warning: enum conversion in initialization is invalid in C++
[-Wc++-compat]
enum e result = 0;
^
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #5 from Tom Tromey tromey at gcc dot gnu.org ---
But, curiously, in this case it points to the RHS of the assignment
(I still tend to think the = is the best location):
extern void *alloc (void);
int *f (void) {
int *r = alloc ();
return r;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:4:12: warning: request for implicit conversion from ‘void *’ to ‘int *’ not
permitted in C++ [-Wc++-compat]
int *r = alloc ();
^
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-13 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.1 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r202145 (aka speculative devirtualization addition).
[Bug libstdc++/61166] New: overflow when parse number in std::duration operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166
Bug ID: 61166
Summary: overflow when parse number in std::duration operator
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kan.liu.229 at gmail dot com
overflow may occur when using a number whose size exceeds sizeof(unsigned) in
chrono_literals. Because the parse classes in include/bits/parse_number.h just
use *unsigned* for member type. However, it should accept *unsigned long long*
I think. This issue also exists in trunk I think.
#include chrono
using namespace std;
using namespace std::chrono;
int main() {
// std::numeric_limitsunsigned::max() == 4294967295
cout 429496729510 endl;
cout (429496729510h).count() endl;
return 0;
}
And the result is
429496729510
926648584
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #4)
Note that it is also wrong in the initializer case.
Right, my patch fixes this too.
(In reply to Tom Tromey from comment #5)
But, curiously, in this case it points to the RHS of the assignment
Yeah, this warning comes from a different spot than the previous ones.
(I still tend to think the = is the best location):
extern void *alloc (void);
int *f (void) {
int *r = alloc ();
return r;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:4:12: warning: request for implicit conversion from ‘void *’ to ‘int *’
not permitted in C++ [-Wc++-compat]
int *r = alloc ();
^
I'd prefer the RHS location here; it's the RHS that's being converted.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #7 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Marek Polacek from comment #6) I'd prefer the RHS location here; it's the RHS that's being converted. I was hoping to automate some conversion from C to C++ using the error locations. So from this perspective, something relatively consistent would be nice. It could be the RHS or it could be the =, for my purposes they are equally good. I tend to think of the = as being the reason for the conversion, but I wouldn't want to make any claims for it beyond that.
[Bug middle-end/60787] [4.7 Regression] ICE in expand_builtin_eh_common, at except.c:1953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60787 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- r172430 exposed it, r190284 made it latent again. The testcase also fails with early inlining disabled.
[Bug ipa/60973] Invalid propagation of a tail call in devirt pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60973 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-13 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Ok.
[Bug tree-optimization/60382] [4.8 Regression] ICE on valid code at -O3 on x86_64-linux-gnu (in vect_create_epilog_for_reduction, at tree-vect-loop.c:4352)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60382 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- hmm, interesting - I can't reproduce the failure but will backport anyway (it's a safe fix).
[Bug c++/10437] using namespace at global scope creates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10437 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Richard Smith from comment #11) I disagree. The failure is not in the immediate context of the substitution, so this is a hard error. GCC seems to be doing the right thing in all cases here. Agreed. I think GCC has been fixed in both respects since this was active and this can be closed (maybe after adding the examples to the test suite, but I think we have equivalents already).
[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61060 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue May 13 08:28:53 2014 New Revision: 210352 URL: http://gcc.gnu.org/viewcvs?rev=210352root=gccview=rev Log: PR target/61060 * config/i386/i386.c (ix86_expand_set_or_movmem): If count_exp is const0_rtx, return immediately. Don't test count == 0 when it is always true. * gcc.dg/pr61060.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61060.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61060 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue May 13 08:31:29 2014 New Revision: 210353 URL: http://gcc.gnu.org/viewcvs?rev=210353root=gccview=rev Log: PR target/61060 * config/i386/i386.c (ix86_expand_set_or_movmem): If count_exp is const0_rtx, return immediately. Don't test count == 0 when it is always true. * gcc.dg/pr61060.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61060.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c++/61167] New: ::std::map::operator[]() throws arithmetic exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61167 Bug ID: 61167 Summary: ::std::map::operator[]() throws arithmetic exception Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hrehf...@uni-koblenz.de See the following bug-report: https://github.com/Andersbakken/rtags/issues/174#issuecomment-42923032 This is the code: https://github.com/Andersbakken/rtags/blob/master/src/Project.cpp#L503 Version: 4.9.0 20140507 (prerelease) (yesterday's archlinux gcc) Sorry that this is not a minimal example or a better bug report. I have almost zero knowlege about the code, but this seems like it should never happen. (I thought it would be better to report /something/, feel free to ignore. I will tell the others to add to the report if possible. )
[Bug c/61144] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #16 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Rich Felker from comment #15) Can you clarify? As far as I can tell, the other bug is a missed optimization and this is an overly-aggressive, incorrect optimization. The same test is wrong, it optimizes cases it shouldn't and doesn't optimize cases it should (I am not familiar enough to tell, just trusting you), goes together. Having testcases in both directions will be useful when Jan (or someone else) rewrites it.
[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW CC||doko at gcc dot gnu.org Resolution|FIXED |--- --- Comment #8 from Matthias Klose doko at gcc dot gnu.org --- I see these test cases failing with 4.9 20140512. Looking at the testresults ML, they are seen by others too. http://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00892.html
[Bug libstdc++/61075] parallel std::accumulate reduct type cannot be different than the iterated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61075 --- Comment #4 from Denes Matetelki denes.matetelki at gmail dot com --- Thank you for the reply, Jonathan. I understand your reasoning and not sure if my desires has much impact in the future of GCC. I'm suprised that the same source code cannot be compiled with parallel mode. It would be ugly to branch with #ifdef _GLIBCXX_PARALLEL. Also, I feel it should be allowed for the user to create a custom labda to add up custom types, just like in the single threaded mode. The std::experimental::reduce is experimental, how shall I solve the problem now? The world accumulate shows the intention, shall I use my own implementation of reduce till that time: a parallel for_each then a single threaded for to sum up?
[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61060 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.10.0, 4.9.1 Resolution|--- |FIXED Known to fail|4.10.0, 4.9.1 |4.9.0 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now for 4.9.1+.
[Bug libstdc++/61143] [4.9/4.10 Regression] Arithmetic exception on emplacing into unordered_map moved out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61143 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||hrehf...@uni-koblenz.de --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 61167 has been marked as a duplicate of this bug. ***
[Bug c++/61167] ::std::map::operator[]() throws arithmetic exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61167 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- You're talking about std::unordered_map not std::map, and it doesn't throw anything, but this has already been reported. *** This bug has been marked as a duplicate of bug 61143 ***
[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094 --- Comment #9 from Matthias Klose doko at gcc dot gnu.org --- x86_64-linux-gnu and i586-linux-gnu too
[Bug libstdc++/61075] parallel std::accumulate reduct type cannot be different than the iterated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61075
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Denes Matetelki from comment #4)
I'm suprised that the same source code cannot be compiled with parallel
mode. It would be ugly to branch with #ifdef _GLIBCXX_PARALLEL.
Also, I feel it should be allowed for the user to create a custom labda to
add up custom types, just like in the single threaded mode.
It is allowed, you just need to meet the additional requirement that Custom is
convertible to int, for example add this member function:
explicit operator int() const { return m_i; }
N.B. the parallel mode is unlikely to see any new work or improvements. Instead
we are more likely to focus on implementing the Paralellism TS (of which N3850
is the current draft).
[Bug c++/61167] ::std::map::operator[]() throws arithmetic exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61167 --- Comment #2 from hrehf...@uni-koblenz.de --- Thanks! :-)
[Bug libstdc++/61143] [4.9/4.10 Regression] Arithmetic exception on emplacing into unordered_map moved out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61143
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |major
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org ---
The best workaround for now is to reset the container to a good state after
moving from it:
std::unordered_mapint, int b = std::move(a);
a = {};
a.emplace(1, 1);
[Bug c/61165] bad location for conversion in return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61165 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-13 CC||manu at gcc dot gnu.org Component|preprocessor|c Summary|unfriendly diagnostic from |bad location for conversion |macro expansion |in return Ever confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Tom Tromey from comment #1) Now there's no mention of the macro at all. The macro expansion note depends on the location, if the location points to something unrelated to the macro expansion, then it cannot work. So the problem is the location.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Tom Tromey from comment #7) (In reply to Marek Polacek from comment #6) I'd prefer the RHS location here; it's the RHS that's being converted. I was hoping to automate some conversion from C to C++ using the error locations. So from this perspective, something relatively consistent would be nice. It could be the RHS or it could be the =, for my purposes they are equally good. I tend to think of the = as being the reason for the conversion, but I wouldn't want to make any claims for it beyond that. If you point to '=', then the macro expansion note will not appear in your other example (PR61165).
[Bug c/61165] bad location for conversion in return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61165 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Tom Tromey from comment #0) I find this a bit strange. The actual warning: line points to the #define -- but here I think I would have expected this to point to the call instead, with a note: pointing to the macro definition. I tend to agree on this, but unfortunately, the previous discussion on this didn't reach any consensus. See PR52998.
[Bug c/61165] bad location for conversion in return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61165 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #3) (In reply to Tom Tromey from comment #0) I find this a bit strange. The actual warning: line points to the #define -- but here I think I would have expected this to point to the call instead, with a note: pointing to the macro definition. I tend to agree on this, but unfortunately, the previous discussion on this didn't reach any consensus. See PR52998. Sorry, that should be PR55252.
[Bug lto/61168] New: Assembler options (-Wa,*) are not propagated when using -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61168 Bug ID: 61168 Summary: Assembler options (-Wa,*) are not propagated when using -flto Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: hubicka at ucw dot cz, iains at gcc dot gnu.org Compiling a code with -Wa,-q pass the -q option to the assembler: as -arch x86_64 -force_cpusubtype_ALL -q -o /var/folders/... (on darwin). Adding -flto does not allow it: as -arch x86_64 -force_cpusubtype_ALL -o /var/folders/...
[Bug fortran/61138] [4.8/4.9/4.10 Regression] Wrong code with pointer-bounds remapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61138 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.8.3
[Bug c/61137] [4.10 regression] FAIL: gcc.target/ia64/small-addr-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61137 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug tree-optimization/61139] missed fma optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61139 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-13 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The issue is that reassoc doesn't fold stmts but we end up with bb 2: _3 = *x_2(D); - _5 = w_4(D) - _3; - _6 = _5 + w_4(D); + _8 = -_3; + _9 = w_4(D) + w_4(D); + _6 = _9 - _3; instead of _9 = w_4(D) * 2.; of course FMA recognition could also be enhanced to handle this case (of course all the issue re-appears for w + w + w then, which should be w * 3.). So probably reassocs job in the end anyway. Confirmed.
[Bug tree-optimization/61139] missed fma/reassoc optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61139 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|missed fma optimization |missed fma/reassoc ||optimization --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Thus, reassoc doesn't seem to transform w + w + w into n * w, neither with integer nor with FP types.
[Bug libstdc++/61075] parallel std::accumulate reduct type cannot be different than the iterated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61075 Denes Matetelki denes.matetelki at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Denes Matetelki denes.matetelki at gmail dot com --- I see. Thank you for your help, I'll implement the convert operator.
[Bug libstdc++/61075] parallel std::accumulate reduct type cannot be different than the iterated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61075 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |WONTFIX --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- I'm going to set this to WONTFIX instead. It is a real bug in the parallel mode, but we're not going to fix it because doing so isn't really possible, and the parallel mode is not being actively developed.
[Bug libstdc++/61166] overflow when parse number in std::duration operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|kan.liu.229 at gmail dot com |3dw4rd at verizon dot net --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Ed, please have a look to this one too.
[Bug c++/12944] [meta-bug] C++ name-lookup problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944 Bug 12944 depends on bug 10437, which changed state. Bug 10437 Summary: using namespace at global scope creates incorrect code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10437 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/10437] using namespace at global scope creates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10437 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Let's close this, then.
[Bug ipa/60973] Invalid propagation of a tail call in devirt pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60973 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 13 11:04:44 2014 New Revision: 210364 URL: http://gcc.gnu.org/viewcvs?rev=210364root=gccview=rev Log: 2014-05-13 Richard Biener rguent...@suse.de PR ipa/60973 * tree-inline.c (remap_gimple_stmt): Clear tail call flag, it needs revisiting whether the call still may be tail-called. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug ipa/60973] Invalid propagation of a tail call in devirt pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60973 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 13 11:06:00 2014 New Revision: 210365 URL: http://gcc.gnu.org/viewcvs?rev=210365root=gccview=rev Log: 2014-05-13 Richard Biener rguent...@suse.de PR ipa/60973 * tree-inline.c (remap_gimple_stmt): Clear tail call flag, it needs revisiting whether the call still may be tail-called. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/tree-inline.c
[Bug ipa/60973] Invalid propagation of a tail call in devirt pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60973 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed for 4.9.1.
[Bug middle-end/61141] [4.10 Regression] c-common.c:1502:1: ICE: in reset_insn_used_flags, at emit-rtl.c:2677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug libstdc++/60497] unique_ptrT tries to complete its type T even though it's not required to be a complete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60497 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue May 13 11:18:01 2014 New Revision: 210366 URL: http://gcc.gnu.org/viewcvs?rev=210366root=gccview=rev Log: PR libstdc++/60497 * include/std/tuple (get, __tuple_compare): Qualify more calls to prevent ADL. Cast comparison results to bool. * testsuite/20_util/tuple/60497.cc: Test accessing rvalues. * testsuite/20_util/tuple/comparison_operators/overloaded.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/tuple/comparison_operators/overloaded.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/tuple trunk/libstdc++-v3/testsuite/20_util/tuple/60497.cc
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.8.2 Version|unknown |4.9.0 Keywords||wrong-code Last reconfirmed||2014-05-13 Component|c |ipa CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 Summary|Invalid optimizations for |[4.9/4.10 Regression] |extern vars with local weak |Invalid optimizations for |definitions |extern vars with local weak ||definitions Target Milestone|--- |4.9.1 Known to fail||4.9.0 --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed for 4.9.0. Note that I agree that the testcase looks suspicious, but weak aliases have odd behavior.
[Bug target/61154] [4.10 Regression][ARM] wide-int merge introduced regressions in vshuf tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0 Summary|[ARM] wide-int merge|[4.10 Regression][ARM] |introduced regressions in |wide-int merge introduced |vshuf tests |regressions in vshuf tests
[Bug c++/61134] [4.7/4.8/4.9/4.10 Regression][C++11] bogus no matching function for call...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61134 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.4 Version|unknown |4.8.2 Target Milestone|--- |4.7.4
[Bug c/61129] Feature request: integer-overflow-detecting arithmetic intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61129 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- There was a recent proof-of-concept patch on the mailinglist to implement that.
[Bug c++/61169] New: [4.6,4.7,4.8,4.9] unnecessarily honors bracket in mathematical statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61169
Bug ID: 61169
Summary: [4.6,4.7,4.8,4.9] unnecessarily honors bracket in
mathematical statements
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hannesroest at gmx dot ch
I hope this is the right place to report this. During some code review of a C++
project, we have noticed that GCC seems to honor brackets added in mathematical
statements in the code unnecessarily and produce slightly suboptimal code under
some circumstances. I am not sure whether this is a feature or not but it can
lead to suboptimal code as we discovered in our codebase and I hoped that I
could get some answers here.
Specifically, the issue is how GCC treats an expression like (x*x) with
brackets vs an expression like x*x without the brackets and prevents
optimization in the first case. Specifically, one can see this in the
following example where gcc = 4.6 uses 4 instructions for the second function
test4ops but only 3 instructions for the first function test3ops.
Interestingly, gcc 4.6 used 3 instructions for both functions:
$ cat test.C
int test3ops(int x, int c, int d) {
return c * x + d * x * x;
}
int test4ops(int x, int c, int d) {
return c * x + d * (x * x);
}
$ gcc -S -O3 test.C
$ cat test.s
.filetest.C
.text
.p2align 4,,15
.globl_Z8test3opsiii
.type_Z8test3opsiii, @function
_Z8test3opsiii:
.LFB0:
.cfi_startproc
imull%edi, %edx
leal(%rdx,%rsi), %eax
imull%edi, %eax
ret
.cfi_endproc
.LFE0:
.size_Z8test3opsiii, .-_Z8test3opsiii
.p2align 4,,15
.globl_Z8test4opsiii
.type_Z8test4opsiii, @function
_Z8test4opsiii:
.LFB1:
.cfi_startproc
imull%edi, %esi
imull%edi, %edi
imull%edx, %edi
leal(%rsi,%rdi), %eax
ret
.cfi_endproc
.LFE1:
.size_Z8test4opsiii, .-_Z8test4opsiii
.identGCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
.section.note.GNU-stack,,@progbits
$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
[Bug target/61170] New: FAIL: libgomp.fortran/declare-simd-[12].f90 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61170
Bug ID: 61170
Summary: FAIL: libgomp.fortran/declare-simd-[12].f90 on darwin
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, jakub at gcc dot gnu.org
Host: x86_64-apple-darwin13
Target: x86_64-apple-darwin13
Build: x86_64-apple-darwin13
The tests libgomp.fortran/declare-simd-[12].f90 fail on darwin, because
gfortran generates avx code not supported by the native 'as'. This can be fixed
with the following patch (using clang assembler)
diff -up ../_clean/libgomp/testsuite/libgomp.fortran/declare-simd-1.f90
libgomp/testsuite/libgomp.fortran/declare-simd-1.f90
--- ../_clean/libgomp/testsuite/libgomp.fortran/declare-simd-1.f90
2014-05-12 09:39:21.0 +0200
+++ libgomp/testsuite/libgomp.fortran/declare-simd-1.f902014-05-12
14:50:04.0 +0200
@@ -1,6 +1,7 @@
! { dg-options -fno-inline }
! { dg-additional-options -msse2 { target sse2_runtime } }
! { dg-additional-options -mavx { target avx_runtime } }
+! { dg-additional-options -Wa,-q { target x86_64-apple-darwin13* } }
module declare_simd_1_mod
contains
diff -up ../_clean/libgomp/testsuite/libgomp.fortran/declare-simd-2.f90
libgomp/testsuite/libgomp.fortran/declare-simd-2.f90
--- ../_clean/libgomp/testsuite/libgomp.fortran/declare-simd-2.f90
2014-05-12 09:39:21.0 +0200
+++ libgomp/testsuite/libgomp.fortran/declare-simd-2.f902014-05-12
14:50:36.0 +0200
@@ -3,6 +3,7 @@
! { dg-additional-sources declare-simd-3.f90 }
! { dg-additional-options -msse2 { target sse2_runtime } }
! { dg-additional-options -mavx { target avx_runtime } }
+! { dg-additional-options -Wa,-q { target x86_64-apple-darwin13* } }
module declare_simd_2_mod
contains
except for the tests with -flto: see pr61168.
[Bug tree-optimization/61171] New: vectorization fails for a reduction in presence of subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61171
Bug ID: 61171
Summary: vectorization fails for a reduction in presence of
subtraction
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
give this code
cat bug.cc
float px[1024];
float xx, vv;
unsigned int N=1024;
void ok() {
for (auto j=0U; jN; ++j) {
auto ax = px[j]-xx;
vv-=ax;
}
}
void noOk() {
for (auto j=0U; jN; ++j) {
auto ax = xx-px[j];
vv+=ax;
}
}
c++ -std=c++11 -Ofast -S bug.cc -march=haswell -fopt-info-vec-missed; cat
bug.s
ok vectorize, noOk does not because
bug.cc:13:3: note: reduction: not commutative/associative: vv.6_9 = _2 - _6;
even if the code is clearly identical (at least with Ofast)
[Bug c++/61172] New: C++11: ICE with invalid call to template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61172
Bug ID: 61172
Summary: C++11: ICE with invalid call to template class
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobi at gcc dot gnu.org
I'm seeing this bug with all g++-4.7 I have access to. There seems to be no
duplicate in bugzilla, even though there are a few similar bugs they are fixed
in 4.7.0 the latest. Even if this is fixed in trunk (I cannot check this right
now), adding a testcase may be sensible:
$ cat t.cc
#include vector
struct foobar {
int a;
};
int main(){
std::vectorfoobar foo;
//Should fail: foobar has no constructor with one argument
foo.emplace_back(0);
}
$ g++ t.cc
t.cc: In function 'int main()':
t.cc:10:9: error: 'class std::vectorfoobar' has no member named
'emplace_back'
$ g++ --std=c++11 t.cc
'
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See https://trac.macports.org/newticket for instructions.
tobi@tobias-schluters-computer tmp$
[Bug libfortran/61173] New: [4.9/4.10 Regression] Erroneous end of file with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 Bug ID: 61173 Summary: [4.9/4.10 Regression] Erroneous end of file with internal read Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: jvdelisle at gcc dot gnu.org Compiling the following test from https://gcc.gnu.org/ml/fortran/2014-05/msg00046.html module bd character(len=256), dimension(:), allocatable, save :: source contains subroutine init_data allocate(source(3)) deallocate(source) allocate(source(2)) source=[ 1 1 1, 4 4 4] end subroutine init_data end module bd program read_internal use bd integer :: x(6),i,iostat character(len=512) :: iomsg call init_data read(source,*,iostat=iostat,iomsg=iomsg) (x(i), i=1,6) if( iostat /= 0 ) then write(*,*) Error: ,trim(iomsg) else write(*,*) (x(i), i=1,6) end if end program read_internal with 4.9.0 or trunk gives at runtime the following error Error: End of file r208320 (2014-03-04) gives 1 1 1 4 4 4 and r208478 (2014-03-11) gives the error. This likely due to r208438 (pr38199).
[Bug c++/61172] C++11: ICE with invalid call to template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61172 --- Comment #1 from Tobias Schlüter tobi at gcc dot gnu.org --- (I see that it mentions macports. To avoid all confusion: I also see this ICE it with unmodified gcc-4.7.2 on Linux.)
[Bug c++/61172] C++11: ICE with invalid call to template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61172 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 57086 ***
[Bug c++/57086] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57086 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||tobi at gcc dot gnu.org --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 61172 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/61169] [4.6,4.7,4.8,4.9] unnecessarily honors bracket in mathematical statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61169 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Component|c++ |tree-optimization --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Doesn't seem a C++ front-end issue to me.
[Bug c++/61174] New: [4.9 Regression] Bad resolving of specialized template with const-qualified member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61174 Bug ID: 61174 Summary: [4.9 Regression] Bad resolving of specialized template with const-qualified member function Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nco...@aldebaran-robotics.com Created attachment 32788 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32788action=edit A file reproducing the bug With 4.8 it compiles. With 4.9.0 we got: main.cpp: In instantiation of ‘struct Aint (C::*)() const’: main.cpp:22:8: required from ‘void make(T) [with T = int (C::*)() const]’ main.cpp:27:13: required from here main.cpp:6:18: attention : invalid application of ‘sizeof’ to a function type [-Wpointer-arith] int fail[sizeof(T) - 1000]; ^ main.cpp: In function ‘void make(T) [with T = int (C::*)() const]’: main.cpp:22:8: erreur: size of variable ‘a’ is too large AT a; ^ Because it use the attribute specialization of our template.
[Bug c++/61174] Bad resolving of specialized template with const-qualified member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61174 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|[4.9 Regression] Bad|Bad resolving of |resolving of specialized|specialized template with |template with |const-qualified member |const-qualified member |function |function| Severity|major |normal --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Pretty sure this is invalid, thus not a regression (clang SolarisStudio agree)
[Bug tree-optimization/61175] New: failing vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61175
Bug ID: 61175
Summary: failing vectorization
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
of these three function only oneOk vectorize.
float px[1024];
float vx[1024];
unsigned int N=1024;
void one(unsigned int i) {
for (auto j=i+1; jN; ++j) {
auto ax = px[j]-px[i];
vx[i]-=ax;
vx[j]+=ax;
}
}
void oneOK(unsigned int k) {
auto tmp = vx[k];
for (auto j=0; jk-1; ++j) {
auto ax = px[j]-px[k];
tmp-=ax;
vx[j]+=ax;
}
vx[k]=tmp;
}
void oneNope(unsigned int k) {
for (auto j=0; jk-1; ++j) {
auto ax = px[j]-px[k];
vx[k]-=ax;
vx[j]+=ax;
}
}
[Bug c++/61172] C++11: ICE with invalid call to template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61172 --- Comment #3 from Tobias Schlüter tobi at gcc dot gnu.org --- Thanks! I wonder which option I missed when I was searching for duplicates :(
[Bug tree-optimization/60382] [4.8 Regression] ICE on valid code at -O3 on x86_64-linux-gnu (in vect_create_epilog_for_reduction, at tree-vect-loop.c:4352)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60382 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 13 13:21:47 2014 New Revision: 210371 URL: http://gcc.gnu.org/viewcvs?rev=210371root=gccview=rev Log: 2014-05-13 Richard Biener rguent...@suse.de Backport from mainline 2014-03-04 Richard Biener rguent...@suse.de PR tree-optimization/60382 * tree-vect-loop.c (vect_is_simple_reduction_1): Do not consider dead PHIs a reduction. * gcc.dg/vect/pr60382.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/pr60382.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-loop.c
[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous end of file with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.9.1
[Bug tree-optimization/61169] [4.6,4.7,4.8,4.9] unnecessarily honors bracket in mathematical statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61169 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- You want -ffast-math, or more specificall -fassociative-math. Re-association can change FP values which is not allowed and the first expression is (d * x) * x.
[Bug libstdc++/61166] overflow when parse number in std::duration operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 --- Comment #2 from emsr at gcc dot gnu.org --- Created attachment 32789 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32789action=edit Patch to parse_nmber to make it unsigned long long all over. Works on x86_64-linux.
[Bug libstdc++/61166] overflow when parse number in std::duration operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 --- Comment #3 from Kan Liu kan.liu.229 at gmail dot com --- (In reply to emsr from comment #2) Created attachment 32789 [details] Patch to parse_nmber to make it unsigned long long all over. Works on x86_64-linux. Yeah, it works. Thank you!
[Bug libstdc++/61166] overflow when parse number in std::duration operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 --- Comment #4 from Kan Liu kan.liu.229 at gmail dot com --- btw, is it really necessary to use functionality in parse_number.h to parse manually? What *parse_number* has done is no more than the general *operator(unsigned long long)*, and it just enables *0b* and *0B* prefix for the numbers. I think *operator(unsigned long long)* is quite enough for this.
[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc - clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #3 from Tony Theodore tony.theodore at gmail dot com --- I'm building a cross compiler with: Host: x86_64-apple-darwin13.1.0 Targets: i686-pc-mingw32 x86_64-w64-mingw32 i686-w64-mingw32 Build: x86_64-apple-darwin13.1.0 It would have helped enormously if you'd stated so in the first place. Compiler details: $ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix On Mac OS X 10.7, gcc -v *does accept* -static-libgcc, though, although it's also LLVM-based. No idea why they changed this in 10.9. Your proposed patch has two problems, unfortunately: * Don't check for $GCC. I don't care who the compiler thinks he is as long as it accepts -static-libgcc. * The gcc version check is wrong: -static-libgcc goes back way long (even 2.95 and perhaps even before). It did apply to -static-libstdc++, though I don't know what a version check buys us if the compiler accepts the option. Please try the attached patch instead. Manual testing with Oracle Studio cc (which doesn't accept -static-libgcc) and gcc gave the correct results. Rainer
[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc - clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 32790 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32790action=edit proposed patch
[Bug c++/61174] Bad resolving of specialized template with const-qualified member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61174 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- By the way, this does *not* compile with 4.8, neither with 4.7, ...
[Bug plugins/61176] New: [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
Bug ID: 61176
Summary: [4.9/4.10 Regression] plugin builds including gimple.h
not building
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
$ cat test.cpp
#include gcc-plugin.h
#include tree.h
#include gimple.h
int main(void) {
return 0;
}
$ g++-4.9 test.cpp -o test -I$(g++-4.9 -print-file-name=plugin)/include
...
/usr/lib/gcc/x86_64-linux-gnu/4.9/plugin/include/gimple.h:276:22: error:
field ‘call_used’ has incomplete type ‘pt_solution’ struct pt_solution
call_used;
including tree-ssa-alias.h works around it, but more headers are needed.
Assuming that gimple.h is needed by plugins how do you find out about all the
required includes?
[Bug c++/57086] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57086 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||stanislav.manilov at gmail dot com --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 60081 has been marked as a duplicate of this bug. ***
[Bug c++/60081] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60081 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- *** This bug has been marked as a duplicate of bug 57086 ***
[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous end of file with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 Keith Refson krefson at googlemail dot com changed: What|Removed |Added CC||krefson at googlemail dot com --- Comment #1 from Keith Refson krefson at googlemail dot com --- I just worked out why the testcase originally failed to reproduce the problem. libgfortran.so was dynamically linking against the older version in /lib64 not the version in /usr/local/gcc-4.9/lib. This fails as expected in my testcase after all.
[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous end of file with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-13 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I just worked out why the testcase originally failed to reproduce the problem. libgfortran.so was dynamically linking against the older version in /lib64 not the version in /usr/local/gcc-4.9/lib. This fails as expected in my testcase after all. Indeed a problem I know (I do the bisection with self contained versions).
[Bug c++/61174] Bad resolving of specialized template with const-qualified member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61174 --- Comment #3 from alkino nco...@aldebaran-robotics.com --- It works with ideone (gcc-4.8.1) https://ideone.com/t8Jww2
[Bug fortran/60928] gfortran issue with allocatable components and OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-13 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test fails at runtime with Attempting to allocate already allocated variable 'bar' when compiled with gfortran from revision 4.5 up to trunk.
[Bug c++/61174] Bad resolving of specialized template with const-qualified member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61174 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- But the testcase is invalid.
[Bug fortran/47054] Compilation error when cray pointers are declared in both host and internal subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47054 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-13 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still failing at r210330 (4.10.0).
[Bug libstdc++/60497] unique_ptrT tries to complete its type T even though it's not required to be a complete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60497 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- This issue actually touches half the library. Using std::bind with unique_ptrBA tries to complete A Using unique_lockSomethingunique_ptrBA tries to complete A Using call_once(o, f, Somethingunique_ptrBA) tries to complete A etc. etc. There are a few more unqualified std::get calls that I'm fixing, but most of the problems come from using the built-in operator, which does ADL and so tries to complete A. That means we must use std::addressof even on internal library types without an overloaded operator if they have any template arguments of user-defined types.
[Bug fortran/61156] [4.7/4.8/4.9/4.10 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61156 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-13 Summary|Internal compiler error for |[4.7/4.8/4.9/4.10 |Fortran files when |Regression] Internal |specifying a file instead |compiler error for Fortran |of an include directory |files when specifying a |with -I |file instead of an include ||directory with -I Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed at r210330 (4.10.0). If I use src.f90 instead of src.F90, the ICE occurs only with the -cpp option. I don't get any ICE with 4.4.7 or before, but with all the versions from 4.5.0 r157958 up to trunk (4.10.0 r210336).
[Bug c++/61174] Bad resolving of specialized template with const-qualified member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61174 --- Comment #5 from alkino nco...@aldebaran-robotics.com --- Can you tell me why, please? Thanks to look at it.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- There was never the promise that the plugin API were anything close to stable.
[Bug c++/61174] Bad resolving of specialized template with const-qualified member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61174
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com ---
Instead of starting from scratch, why don't you use
std::is_member_function_pointer? It handles correctly all sorts of member
functions. Alternately, study the implementation and learn from it.
In any case, you have of course a problem with the constness of g, you would
have to add:
templatetypename C, typename T struct AT (C::*)() const
{
int ok;
};
because otherwise the first specialization - as you can easily learn from
type_traits - matches f and all sorts of member pointers, for that matter.
[Bug libstdc++/61143] [4.9/4.10 Regression] Arithmetic exception on emplacing into unordered_map moved out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61143 --- Comment #9 from Felix Fontein felix at fontein dot de --- Another workaround is to use reserve(), as in: std::unordered_mapint, int b = std::move(a); a.reserve(1); // any number 0 will do a.emplace(1, 1);
[Bug fortran/60928] gfortran issue with allocatable components and OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- This is invalid in OpenMP 3.1, because OpenMP 3.1 doesn't support anything beyond Fortran 95. And in my reading it is also invalid in OpenMP 4.0, because it falls into Allocatable enhancement that is listed as not supported in OpenMP 4.0. So I believe the unsupported part is: - allocatable dummy arguments - allocate statement - transferring an allocation (move_alloc intrinsic) - intrinsic assignment to an allocatable entity - derived type components with allocatable attribute I think all these are meant to be supported in OpenMP 4.1.
[Bug c++/54310] Order of operations during overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54310 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Current SolarisStudio also accepts it. I guess I'm going to add the testcase and close the bug.
[Bug c/61177] New: armv6zk: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61177 Bug ID: 61177 Summary: armv6zk: gcc Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rion4ik at gmail dot com
[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc - clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981 --- Comment #6 from Tony Theodore tony.theodore at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #4) --- Comment #3 from Tony Theodore tony.theodore at gmail dot com --- I'm building a cross compiler with: It would have helped enormously if you'd stated so in the first place. Apologies. Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix On Mac OS X 10.7, gcc -v *does accept* -static-libgcc, though, although it's also LLVM-based. No idea why they changed this in 10.9. Up till LLVM 3.3 there was a gcc plugin called DragonEgg which used gcc as a front-end and LLVM as the back-end. Now gcc is basically an alias for the clang front-end. Your proposed patch has two problems, unfortunately: * Don't check for $GCC. I don't care who the compiler thinks he is as long as it accepts -static-libgcc. * The gcc version check is wrong: -static-libgcc goes back way long (even 2.95 and perhaps even before). It did apply to -static-libstdc++, though I don't know what a version check buys us if the compiler accepts the option. Thanks for the explanation, that make sense. Please try the attached patch instead. Manual testing with Oracle Studio cc (which doesn't accept -static-libgcc) and gcc gave the correct results. I can confirm that this works with all three mingw targets (after installing autoconf 2.64) - thank you very much! Cheers, Tony
[Bug c/61165] bad location for conversion in return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61165 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Tom Tromey tromey at gcc dot gnu.org --- I think 55252 is a more complete analysis of the same problem. Thanks for pointing that one out. *** This bug has been marked as a duplicate of bug 55252 ***
[Bug c/61177] armv6zk: gcc fails compile one source file with fPIC and mthumb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61177 Rion rion4ik at gmail dot com changed: What|Removed |Added CC||rion4ik at gmail dot com Known to work||4.6.1, 4.7.3 Summary|armv6zk: gcc|armv6zk: gcc fails compile ||one source file with fPIC ||and mthumb --- Comment #1 from Rion rion4ik at gmail dot com --- probably I have to report this to buildroot, but I didn't notice any suspicious patches there which may lead to such behaviour $ armeb-buildroot-linux-uclibcgnueabi-gcc -v -save-temps -mthumb -fPIC -c test.c -o test.o Using built-in specs. COLLECT_GCC=/srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/armeb-buildroot-linux-uclibcgnueabi-gcc COLLECT_LTO_WRAPPER=/srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../libexec/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/lto-wrapper Target: armeb-buildroot-linux-uclibcgnueabi Configured with: ./configure --prefix=/srv/Vendors/Intel/PumaToolchain-buildroot201308//usr --sysconfdir=/srv/Vendors/Intel/PumaToolchain-buildroot201308//etc --enable-shared --disable-static --disable-gtk-doc --disable-doc --disable-docs --disable-documentation --with-xmlto=no --with-fop=no --target=armeb-buildroot-linux-uclibcgnueabi --with-sysroot=/srv/Vendors/Intel/PumaToolchain-buildroot201308//usr/armeb-buildroot-linux-uclibcgnueabi/sysroot --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --with-gmp=/srv/Vendors/Intel/PumaToolchain-buildroot201308//usr --with-mpfr=/srv/Vendors/Intel/PumaToolchain-buildroot201308//usr --enable-target-optspace --enable-tls --enable-threads --with-mpc=/srv/Vendors/Intel/PumaToolchain-buildroot201308//usr --with-float=soft --disable-decimal-float --with-arch=armv6zk --with-tune=arm1176jz-s --with-abi=aapcs-linux --with-float=soft --with-mode=arm --with-pkgversion='Buildroot 2013.08.1' --with-bugurl=http://bugs.buildroot.net/ --enable-languages=c,c++ --with-build-time-tools=/srv/Vendors/Intel/PumaToolchain-buildroot201308//usr/armeb-buildroot-linux-uclibcgnueabi/bin --disable-libgomp Thread model: posix gcc version 4.6.4 (Buildroot 2013.08.1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mthumb' '-fPIC' '-c' '-o' 'gw_rnddb2NEW.o' '-march=armv6zk' '-mtune=arm1176jz-s' '-mfloat-abi=soft' '-mabi=aapcs-linux' /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../libexec/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/cc1 -E -quiet -v -iprefix /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../lib/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/ -isysroot /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../armeb-buildroot-linux-uclibcgnueabi/sysroot test.c -mthumb -march=armv6zk -mtune=arm1176jz-s -mfloat-abi=soft -mabi=aapcs-linux -fPIC -fpch-preprocess -o test.i ignoring duplicate directory /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../lib/gcc/../../lib/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/include ignoring nonexistent directory /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../armeb-buildroot-linux-uclibcgnueabi/sysroot/usr/local/include ignoring duplicate directory /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../lib/gcc/../../lib/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/include-fixed ignoring duplicate directory /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../lib/gcc/../../lib/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/../../../../armeb-buildroot-linux-uclibcgnueabi/include #include ... search starts here: #include ... search starts here: /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../lib/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/include /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../lib/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/include-fixed /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../lib/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/../../../../armeb-buildroot-linux-uclibcgnueabi/include /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../armeb-buildroot-linux-uclibcgnueabi/sysroot/usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mthumb' '-fPIC' '-c' '-o' 'gw_rnddb2NEW.o' '-march=armv6zk' '-mtune=arm1176jz-s' '-mfloat-abi=soft' '-mabi=aapcs-linux' /srv/Vendors/Intel/PumaToolchain-buildroot201308/usr/bin/../libexec/gcc/armeb-buildroot-linux-uclibcgnueabi/4.6.4/cc1 -fpreprocessed test.i -quiet -dumpbase test.c -mthumb -march=armv6zk -mtune=arm1176jz-s -mfloat-abi=soft -mabi=aapcs-linux -auxbase-strip gw_rnddb2NEW.o -version -fPIC -o test.s GNU C (Buildroot 2013.08.1) version 4.6.4 (armeb-buildroot-linux-uclibcgnueabi) compiled by GNU C version 4.6.3, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics:
[Bug c/61177] armv6zk: gcc fails compile one source file with fPIC and mthumb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61177 --- Comment #2 from Rion rion4ik at gmail dot com --- Created attachment 32791 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32791action=edit test.c example code.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #9 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #8) If you point to '=', then the macro expansion note will not appear in your other example (PR61165). Yeah, I still think the '=' is preferable. I think it lets one know exactly where to insert a cast.
[Bug c++/61178] New: expansion pattern '#'nontype_argument_pack' not supported by dump_expr#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61178
Bug ID: 61178
Summary: expansion pattern '#'nontype_argument_pack' not
supported by dump_expr#
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tower120 at gmail dot com
I got strange error:
expansion pattern '#'nontype_argument_pack' not supported by dump_expr#
With the following code:
http://coliru.stacked-crooked.com/a/bbacd7e9bec149f0
--
#include iostream
#include utility
#include type_traits
#include typeinfo
using namespace std;
struct Void{
static constexpr int size = 0;
};
templatetypename T0, typename T1
class Variadic{
private:
typedef VariadicT0, T1 thisT;
public:
/** Do not use this constructor */
Variadic(T0 el0, T1 el1): value(el0), next(el1) {}
// avoiding decltype
typedef T0 valueT;
T0 value;
typedef T1 nextT;
T1 next; // may be next pair
/**
* Chainable method
*/
templatetypename ValueT
/*constexpr*/ inline VariadicValueT, thisT add(ValueT value){
return VariadicValueT, thisT(value, (*this) );
}
};
templatetypename T
static inline VariadicT, Void make_variadic(T value){
return VariadicT, Void(value, Void());
}
/// ERROR IS HERE!
templatetypename Arg0, typename... Args
static inline auto make_variadic(Arg0 value0, Args... values) - decltype(
fill(make_variadicArg0(value0), values...) ) {
return fill(make_variadicArg0(value0), values...);
}
/// THIS ONE BELOW, WORKS FINE
/*
templatetypename Arg0, typename... Args
static inline auto make_variadic(Arg0 value0, Args... values) -
decltype(fill(VariadicArg0, Void(value0, Void()), values...)) {
return fill(VariadicArg0, Void(value0, Void()), values...);
}*/
templatetypename T, typename Arg0, typename... Args
static inline auto fill(T self, Arg0 value, Args... values) -
decltype(fill(self.add(value), values...)){
return fill(self.add(value), values...);
}
templatetypename T, typename Arg0
static inline auto fill(T self, Arg0 value) - decltype(self.add(value)){
return self.add(value);
}
int main()
{
auto list = make_variadic(1, 2, 3);
}
--
Command line from coliru:
g++-4.8 -std=c++11 -O2 -Wall -Wextra -pedantic -pthread -pedantic-errors
main.cpp -lm ./a.out
Clang compile this without errors.
If I replace make_variadic call (see code above) with function body, it works
ok.
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #14 from Tom Tromey tromey at gcc dot gnu.org --- *** Bug 61165 has been marked as a duplicate of this bug. ***
[Bug c++/54890] Incorrect SFINAE Rejection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54890 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Jason, can you help me (re-)triaging this?
[Bug c++/60628] [4.7/4.8 Regression] [c++11] ICE initializing array of auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60628 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue May 13 16:05:07 2014 New Revision: 210382 URL: http://gcc.gnu.org/viewcvs?rev=210382root=gccview=rev Log: PR c++/60628 * decl.c (create_array_type_for_decl): Complain about array of auto. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/auto42.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/decl.c
[Bug c++/60367] Default argument object is not getting constructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue May 13 16:05:01 2014 New Revision: 210381 URL: http://gcc.gnu.org/viewcvs?rev=210381root=gccview=rev Log: PR c++/60367 * call.c (convert_default_arg): Remove special handling for CONSTRUCTOR. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/overload/defarg8.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/call.c
