[Bug target/56853] GNU Fortran is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56853 --- Comment #6 from g toedt at embl dot de --- In my case i could fix it by reinstalling gmp. for macports you would have todo: port -f uninstall gmp port install -s gmp
[Bug tree-optimization/42970] Missed unused function return value elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Consider LTO. Note that the issue is that while we remove assignments to
unused variables from calls at the caller side we never remove a never used
return value from a return statement. This keeps the computation of
'counter' and 'counter' itself life and thus weakens IPA reference analysis.
For the following testcase we should be able to remove the call to
quantum_gate_counter _without using the trick of inlining it_.
Basically some IPA optimization should figure out that 'return counter'
is dead and it and all producing stmts can be elimiated. You cannot
elimiate the return stmt if you don't change the functions signature,
but if you don't want to do that you can for example just return 0.
It get's tricky with the requirements in the description but the idea
was that the early IPA-SRA pass would clone the function for unused
return value, local passes then would eliminate all stmts in the clone
making it const and thus we win. The tricky part here is that early
opts don't see the whole program so that quantum_gate_counter is
exported (and we share the 'counter' variable with the original function
which cannot be eliminated).
static int __attribute__((noinline,noclone))
quantum_gate_counter(int inc)
{
static int counter = 0;
if(inc 0)
counter += inc;
else if(inc 0)
counter = 0;
return counter;
}
int main()
{
quantum_gate_counter (1);
return 0;
}
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 --- Comment #5 from Vittorio Zecca zeccav at gmail dot com --- I do not think SIZE should be used to detect an undefined array pointer, but a size of zero warns the code that the array is mostly unusable and that perhaps something is wrong, while a nonzero size is telling the program it is fine to use the array. I agree with Dominique, I am still writing invalid code all the time, also because interactive computing makes it so easy and fast to write, compile, link and execute code. When I used punched cards in the seventies I had more time to think and reflect about my programs, also because the turnaround time was about 30 minutes as compared with 30 seconds today If the programmers did not write invalid code many people would be out of business:-)
[Bug tree-optimization/58028] [4.9 Regression] Several failures in libgomp.graphite after revision 200946
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC|rguenther at suse dot de |rguenth at gcc dot gnu.org Blocks||54094 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- First identify the revision that caused this. I would guess it's 2013-07-13 Tobias Grosser tob...@grosser.es PR tree-optimization/54094 * graphite-clast-to-gimple.c (translate_clast_for_loop): Derive the scheduling dimension for the parallelism check from the polyhedral information in the AST. * graphite-dependences.c (carries_deps): Do not assume the schedule is in 2D + 1 form. ?
[Bug c/38047] -Wredundant-decls does not take scope into account
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38047
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2008-11-07 11:26:14 |2011-11-10 10:26:14
Known to fail||4.8.2
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Similar
int main()
{
{
extern int foo;
foo;
}
{
extern int foo;
foo;
}
}
gcc -Wredundant-decls t.c -S
t.c: In function 'main':
t.c:8:16: warning: redundant redeclaration of 'foo' [-Wredundant-decls]
extern int foo;
^
t.c:4:16: note: previous declaration of 'foo' was here
extern int foo;
^
Re-confirmed.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 Nick Maclaren nmm1 at cam dot ac.uk changed: What|Removed |Added CC||nmm1 at cam dot ac.uk --- Comment #20 from Nick Maclaren nmm1 at cam dot ac.uk --- Richard Biener's approach to the default is the one that matches the C standard and Vincent Lefèvre is mistaken. C11 7.6.1p2 says: ... If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma ‘‘off’’, the behavior is undefined. The default state (‘‘on’’ or ‘‘off’’) for the pragma is implementation-defined. Defining it to be 'off' and not setting __STDC_IEC_559__ is very reasonable. Because generated code and the library are potentially dependent on the rounding mode (including even floating point to integer conversion!), the default should remain that rounding mode support is off until each target has been thoroughly checked that it does NOT break. There are also very strong grounds for not wanting IEEE 754 support by default, anyway, because of the performance impact and because a lot of programs won't reset the state before calling external functions (and hence may well give wrong answers). That is especially true if the code is used within a C++ program or uses GPUs or some SIMD units - let alone OpenMP :-(
[Bug target/58854] [4.8 regression] sub sp, fp, #40 hoisted above frame accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Now fixed.
[Bug target/58854] [4.8 regression] sub sp, fp, #40 hoisted above frame accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 --- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Mon Nov 11 09:38:14 2013 New Revision: 204665 URL: http://gcc.gnu.org/viewcvs?rev=204665root=gccview=rev Log: Backport fix for PR target/58854 2013-11-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com Backported from mainline 2013-10-30 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/58854 * config/arm/arm.c (arm_expand_epilogue_apcs_frame): Emit blockage Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/arm/arm.c
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970 --- Comment #30 from Jan Smets jan.sm...@alcatel-lucent.com --- Thanks!
[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #5 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- A patch is here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00931.html
[Bug target/57680] [META-BUG][target]deregister_frame_fn is set to invalid address in cygming-crtbegin.c:__gcc_deregister_frame due to unknown reason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- The reason is pretty obvious ... see pr 57982. Fix was applied to all open branches. Weak works on pe-coff different, and there seem to be inconsistencies, but this issue isn't related to this at all.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added Attachment #31192|0 |1 is obsolete|| --- Comment #12 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31193 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31193action=edit Second-try patch (In reply to Jakub Jelinek from comment #10) Hm, I was under impression that these only get activated when user has specified -static-libasan on cmdline... Sure. But for dynamically linked libasan.so you just add it to libasan_la_LDFLAGS and it will DTRT. Makes sense. Attaching new patch. I had to add the ugly -lstdc++ in pr59063-2.c because we do not autolink libsupc++ when '-fsanitize=address -static-libasan' is specified. This may be a bug.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 --- Comment #13 from Yury Gribov y.gribov at samsung dot com --- (In reply to Evgeniy Stepanov from comment #11) (In reply to Yury Gribov from comment #4) Evgeniy, what about a warning in GetRealFunctionAddress if real symbol is NULL? Warning sounds like a good idea. Cool. Should I file an issue at http://code.google.com/p/address-sanitizer/issues ?
[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- We have bb 4: # iftmp.2_1 = PHI foo(2), bar(3) _10 = 3; _34 = g.5_8 != 1; _35 = _10 != 3; in .optimized, as fold-all-builtins manages to produce that from bb 4: # iftmp.2_1 = PHI foo(3), bar(2) _10 = strlen (iftmp.2_1); _34 = g.5_8 != 1; _35 = _10 != 3; we don't re-fold the strlen call earlier as it doesn't change (only the PHI node feeding it does!). The fact that we don't propagate string-lengths separately in CCP makes this a somewhat ill-fit for handling during the CCP propagation stage. At -O2 jump threading and the strlen pass handle it well. So indeed an oddity - probably TER simply should not forward constants to not confuse RTL expansion.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 --- Comment #14 from Yury Gribov y.gribov at samsung dot com --- (In reply to Yury Gribov from comment #12) Makes sense. Attaching new patch. Forgot to mention - tested on x64_64.
[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- That is, sth like Index: gcc/tree-ssa-ter.c === --- gcc/tree-ssa-ter.c (revision 204664) +++ gcc/tree-ssa-ter.c (working copy) @@ -438,6 +439,12 @@ ter_is_replaceable_p (gimple stmt) !is_gimple_val (gimple_assign_rhs1 (stmt))) return false; + /* Do not propagate modeless constants - we may end up confusing the RTL +expanders. Leave the optimization to RTL CCP. */ + if (gimple_assign_single_p (stmt) + CONSTANT_CLASS_P (gimple_assign_rhs1 (stmt))) + return false; + return true; } return false;
[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049 --- Comment #8 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- (In reply to Richard Biener from comment #7) That is, sth like Index: gcc/tree-ssa-ter.c === --- gcc/tree-ssa-ter.c (revision 204664) +++ gcc/tree-ssa-ter.c (working copy) @@ -438,6 +439,12 @@ ter_is_replaceable_p (gimple stmt) !is_gimple_val (gimple_assign_rhs1 (stmt))) return false; + /* Do not propagate modeless constants - we may end up confusing the RTL +expanders. Leave the optimization to RTL CCP. */ + if (gimple_assign_single_p (stmt) + CONSTANT_CLASS_P (gimple_assign_rhs1 (stmt))) + return false; + return true; } return false; Constants are often very valuable for rtl expansion, allowing to use cheaper patterns. And some constant propagations are impossible in rtl because of mode oddities. E.g. when you have a have a mulsidi3 pattern, you generally have a sign_extend - you can't have a VOIDmode constant inside that. Therefore, I would rather have the middle-end move the constants to registers only when necessary to preserve the mode, and preferrably fold instead in the first place when optimizing.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 --- Comment #15 from Evgeniy Stepanov eugeni.stepanov at gmail dot com --- (In reply to Yury Gribov from comment #13) (In reply to Evgeniy Stepanov from comment #11) (In reply to Yury Gribov from comment #4) Evgeniy, what about a warning in GetRealFunctionAddress if real symbol is NULL? Warning sounds like a good idea. Cool. Should I file an issue at http://code.google.com/p/address-sanitizer/issues ? No need, I'm fixing it now.
[Bug libstdc++/59076] std::to_string(int ) could not be found in GCC 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59076 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- See Bug 52015, it's not supported on MinGW because of limitations in the MinGW runtime that need changes from MinGW developers. *** This bug has been marked as a duplicate of bug 52015 ***
[Bug libstdc++/52015] std::to_string does not work under MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||chun-fu.yang at hp dot com --- Comment #34 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 59076 has been marked as a duplicate of this bug. ***
[Bug c++/59056] enable_if turns a non-ambiguous template into an ambiguous one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Similar (but not identical) to PR 58752
[Bug c++/58822] Segfault when calling make_shared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822 --- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Michi Henning from comment #20) I'm pretty sure that I'm not using anything in shared_ptr that's outside the standard, and the standard way to get access to shared_ptr is to include memory. If I include something else, I end up in implementation territory, don't I? Yes, but you're trying to report a bug specific to this implementation, not in the standard. If you still haven't reduced this I'll do so, but it might have to wait a week or two.
[Bug c++/58822] Segfault when calling make_shared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822 --- Comment #25 from Michi Henning michi at triodia dot com --- (In reply to Jonathan Wakely from comment #24) (In reply to Michi Henning from comment #20) I'm pretty sure that I'm not using anything in shared_ptr that's outside the standard, and the standard way to get access to shared_ptr is to include memory. If I include something else, I end up in implementation territory, don't I? Yes, but you're trying to report a bug specific to this implementation, not in the standard. Right. As best as I can tell, this is a code generation bug in gcc. Clang generates code for the same thing that works fine. If you still haven't reduced this I'll do so, but it might have to wait a week or two. I'm really time-limited at the moment. I tried creduce, but the latest version requires an upgrade to Perl, and I haven't gotten around to installing that yet. One thing that is really taxing is the difficulty of whittling down the system headers. I started out with over 25,000 lines of very convoluted template code, which I have laboriously reduced to around 1300 lines. Of those, a good 800 lines or so are from type_traits, and its exceedingly difficult to reduce that included code further. I tried creduce, but it bombs on my machine. I'm told that I have to use the latest Perl for it to work, but haven't gotten around to installing that yet. If you care to have a look, I'd appreciate it very much! I'm under too much pressure at the moment to find the extra cycles to work on this. It's not a show-stopper right now for me, but it will be in another three weeks from. If only there were more than 24 hours in a day :-( Thanks, Michi.
[Bug libstdc++/58931] condition_variable::wait_until overflowed by large time_pointsteady_clock
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-11-11
Component|c++ |libstdc++
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Fixing PR 54562 doesn't help. This can be reduced to
#include chrono
#include cassert
int main()
{
using StClock = std::chrono::steady_clock;
using SysClock = std::chrono::system_clock;
auto st_atime = std::chrono::time_pointStClock::max();
const StClock::time_point st_now = StClock::now();
const SysClock::time_point sys_now = SysClock::now();
const auto delta = st_atime - st_now;
const auto sys_atime = sys_now + delta;
assert( sys_atime sys_now );
}
[Bug preprocessor/47756] Warning for #include instead of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756 --- Comment #6 from Olaf van der Spek olafvdspek at gmail dot com --- Hi Jonathan, The difference between and is implementation defined. AFAIK GCC only searches the include path with and first searches relative to the current file with . So the standard can't offer better guidance. Let's consider GCC on Linux. Do you use only for standard C / C++ headers or do you also use it for for example zlib and other platform provided headers? What do major coding styles say?
[Bug libstdc++/54562] mutex and condition variable timers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Nov 11 13:33:48 2013 New Revision: 204672 URL: http://gcc.gnu.org/viewcvs?rev=204672root=gccview=rev Log: PR libstdc++/54562 * include/std/mutex (__timed_mutex_impl::__clock_t): Use high_resolution_clock for absolute timeouts, because pthread_mutex_timedlock uses CLOCK_REALTIME not CLOCK_MONOTONIC. (__timed_mutex_impl::_M_try_lock_for): Use steady_clock for relative timeouts as per [thread.req.timing]. (__timed_mutex_impl::_M_try_lock_untilClock,Duration): Convert to __clock_t time point instead of using _M_try_lock_for. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/mutex
[Bug libstdc++/54562] mutex and condition variable timers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.9.0. We still don't handle clock adjustments, doing so requires looping which adds overhead that might not be desirable. I'll revisit that topic another time.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #21 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Nick Maclaren from comment #20) Richard Biener's approach to the default is the one that matches the C standard and Vincent Lefèvre is mistaken. No, I'm correct. Defining it to be 'off' and not setting __STDC_IEC_559__ is very reasonable. No, this is really stupid. If the user *decides* to set the STDC FENV_ACCESS pragma to on, then the compiler must not assume that it is off (this bug is not about the default state). At least it must behave in this way if -std=c99 (or c11) has been used. Otherwise a compilation failure may be better than getting wrong results.
[Bug tree-optimization/59077] New: ipa-pure-const.c (better_state): comment and code mistmatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59077 Bug ID: 59077 Summary: ipa-pure-const.c (better_state): comment and code mistmatch Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Doc and prototype for function better_state in ipa-pure-const.c: /* Merge STATE and STATE2 and LOOPING and LOOPING2 and store into STATE and LOOPING better of the two variants. Be sure to merge looping correctly. IPA_NEITHER functions have looping 0 even if they don't have to return. */ static inline void better_state (enum pure_const_state_e *state, bool *looping, enum pure_const_state_e state2, bool looping2) But if you read the code, nothing ever writes to state. I am looking at this file for the first time, so I don't know if it is missing: *state = MIN (*state, state2); at the end or if the comment is wrong or something else.
[Bug c/59073] [4.9 Regression] ICE with missing increment in OpenMP for-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59073 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Untested patch diff --git a/gcc/c-family/c-omp.c b/gcc/c-family/c-omp.c index f001a75..dea33c8 100644 --- a/gcc/c-family/c-omp.c +++ b/gcc/c-family/c-omp.c @@ -583 +583 @@ c_finish_omp_for (location_t locus, enum tree_code code, -return NULL; +return error_mark_node; diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 09cce1c..93ddf92 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -11575 +11575 @@ c_parser_omp_for_loop (location_t loc, c_parser *parser, - if (stmt) + if (stmt != error_mark_node) diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c index 366756f..b256831 100644 --- a/gcc/cp/semantics.c +++ b/gcc/cp/semantics.c @@ -6405,2 +6405,2 @@ finish_omp_for (location_t locus, enum tree_code code, - if (omp_for == NULL) -return NULL; + if (omp_for == error_mark_node) +return error_mark_node;
[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||samsonov at google dot com --- Comment #4 from Yury Gribov y.gribov at samsung dot com --- Added Alexey to maybe comment on making __asan_init a constructor.
[Bug c++/59071] sse2 intrinsics and constant expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59071 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-11 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug rtl-optimization/59064] [4.9 regression] FAIL: gcc.dg/vect/vect-ivdep-1.c (test for bogus messages, line )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59064 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/59058] [4.7/4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||3.3.6 Keywords||wrong-code Last reconfirmed||2013-11-11 Ever confirmed|0 |1 Summary|wrong code at -O3 on|[4.7/4.8/4.9 Regression] |x86_64-linux-gnu (affecting |wrong code at -O3 on |gcc 4.6 to trunk) |x86_64-linux-gnu (affecting ||gcc 4.6 to trunk) Target Milestone|--- |4.7.4 Known to fail||4.1.2 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, works with 3.3.
[Bug other/49661] et-forest.h uses extern C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49661 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- libiberty is a C library. I don't consider that relevant to any code not actually part of libiberty.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #22 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Mon, 11 Nov 2013, nmm1 at cam dot ac.uk wrote: There are also very strong grounds for not wanting IEEE 754 support by default, anyway, because of the performance impact and because a lot of programs won't reset the state before calling external functions (and hence may well give wrong answers). That is especially true if the code is used within a C++ program or uses GPUs or some SIMD units - let alone OpenMP :-( Note also that the documented default is -ftrapping-math -fno-rounding-math. I suspect that if -ftrapping-math actually implemented everything required for the floating-point exceptions aspects of FENV_ACCESS, it would be just as bad for optimization as -frounding-math - it would disallow constant-folding inexact floating-point expressions because that would eliminate the side effect of raising the inexact exception, for example (just as -frounding-math does disable such constant folding, although not in all cases it should, because the result depends on the rounding mode), and would mean a value computed before a function call can't be reused for the same computation after that call because the computation might raise exceptions that the function call could have cleared (just as -frounding-math should prevent such reuse because the call might change the rounding mode). So a key part of actually making rounding modes and exceptions work reliably would be working out a definition of GCC's default mode that allows more or less the same optimizations as at present, while allowing users wanting the full support (and consequent optimization cost) to specify the appropriate command-line options or FENV_ACCESS pragma to enable it.
[Bug target/58853] [4.9 regression] ICE in expand_set_or_movmem_prologue_epilogue_by_misaligned_moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853 --- Comment #7 from Jan Hubicka hubicka at ucw dot cz --- diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 53e04c4..dd8d943 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -23766,6 +23766,7 @@ ix86_expand_set_or_movmem (rtx dst, rtx src, rtx count_exp, rtx val_exp, also avoids redundant job when sizes are known precisely. */ misaligned_prologue_used = (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES MAX (desired_align, epilogue_size_needed) = 32 + desired_align = epilogue_size_needed ((desired_align align !align_bytes) || (!count epilogue_size_needed 1))); avoids crash. Yes, we can add this, too, for correctness with manual changes to tunning flags (so the patch is approved). What confuses me is why TARGET_MISALIGNED_MOVE_STRING_PROLOGUES seems to be true given that DEF_TUNE (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES, misaligned_move_string_prologues, m_386 | m_486 | m_CORE_ALL | m_AMD_MULTIPLE | m_GENERIC) and we tune for pentiumpro (that was intentionally left out for this purpose) Honza
[Bug target/59078] New: autoincrement feature of NEON store instructions is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59078
Bug ID: 59078
Summary: autoincrement feature of NEON store instructions is
not used
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tir5c3 at yahoo dot co.uk
The following testcase, when compiled with 'g++ test.cc -O3 -mfpu=neon
--save-temps -c', produces very inefficient code.
=
#include arm_neon.h
uint64_t* foo(uint64_t* x, uint32_t y)
{
uint64x2_t d = vreinterpretq_u64_u32(vdupq_n_u32(y));
vst1q_u64(x, d);
x+=2;
vst1q_u64(x, d);
x+=2;
vst1q_u64(x, d);
x+=2;
vst1q_u64(x, d);
x+=2;
vst1q_u64(x, d);
x+=2;
vst1q_u64(x, d);
x+=2;
vst1q_u64(x, d);
x+=2;
vst1q_u64(x, d);
x+=2;
return x;
}
The resulting assembly:
_Z3fooPyj:
push{r4, r5, r6, r7}
vdup.32q8, r1
addr7, r0, #32
addr6, r0, #48
addr5, r0, #64
addr4, r0, #80
addr1, r0, #96
addr2, r0, #112
movr3, r0
addsr0, r0, #128
vst1.64{d16-d17}, [r3:64]!
vst1.64{d16-d17}, [r3:64]
vst1.64{d16-d17}, [r7:64]
vst1.64{d16-d17}, [r6:64]
vst1.64{d16-d17}, [r5:64]
vst1.64{d16-d17}, [r4:64]
vst1.64{d16-d17}, [r1:64]
vst1.64{d16-d17}, [r2:64]
pop{r4, r5, r6, r7}
bxlr
The main problem is that pointer autoincrement feature of the vst1.64
instruction is not fully utilized. GCC apparently figures it out for the first
store, but it becomes confused later. I would expect GCC to produce the
following output:
_Z3fooPyj:
vdup.32q8, r1
vst1.64{d16-d17}, [r0:64]!
vst1.64{d16-d17}, [r0:64]!
vst1.64{d16-d17}, [r0:64]!
vst1.64{d16-d17}, [r0:64]!
vst1.64{d16-d17}, [r0:64]!
vst1.64{d16-d17}, [r0:64]!
vst1.64{d16-d17}, [r0:64]!
vst1.64{d16-d17}, [r0:64]!
bxlr
On unrolled loops GCC spills almost all registers to memory, which
causes two to three times worse performance compared to the optimal
version.
This bug has been tested on GCC 4.8.1. This email [1] suggests that mainline is
also affected.
[1]: http://gcc.gnu.org/ml/gcc-help/2013-11/msg00075.html
[Bug target/58853] [4.9 regression] ICE in expand_set_or_movmem_prologue_epilogue_by_misaligned_moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853 --- Comment #8 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jan Hubicka from comment #7) Yes, we can add this, too, for correctness with manual changes to tunning flags (so the patch is approved). What confuses me is why TARGET_MISALIGNED_MOVE_STRING_PROLOGUES seems to be true given that DEF_TUNE (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES, misaligned_move_string_prologues, m_386 | m_486 | m_CORE_ALL | m_AMD_MULTIPLE | m_GENERIC) and we tune for pentiumpro (that was intentionally left out for this purpose) Index: i386.c === --- i386.c (revision 204676) +++ i386.c (working copy) @@ -23764,7 +23764,7 @@ /* Misaligned move sequences handles both prologues and epilogues at once. Default code generation results in smaller code for large alignments and also avoids redundant job when sizes are known precisely. */ - misaligned_prologue_used = (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES + misaligned_prologue_used = (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES_EPILOGUES MAX (desired_align, epilogue_size_needed) = 32 ((desired_align align !align_bytes) || (!count epilogue_size_needed 1)));
[Bug target/58853] [4.9 regression] ICE in expand_set_or_movmem_prologue_epilogue_by_misaligned_moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853 --- Comment #9 from Jan Hubicka hubicka at ucw dot cz --- What confuses me is why TARGET_MISALIGNED_MOVE_STRING_PROLOGUES seems to be true given that DEF_TUNE (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES, misaligned_move_string_prologues, m_386 | m_486 | m_CORE_ALL | m_AMD_MULTIPLE | m_GENERIC) and we tune for pentiumpro (that was intentionally left out for this purpose) I think the problem is here: Index: config/i386/i386.h === --- config/i386/i386.h (revision 204166) +++ config/i386/i386.h (working copy) @@ -353,7 +353,7 @@ extern unsigned char ix86_tune_features[ #define TARGET_FAST_PREFIX ix86_tune_features[X86_TUNE_FAST_PREFIX] #define TARGET_SINGLE_STRINGOP ix86_tune_features[X86_TUNE_SINGLE_STRINGOP] #define TARGET_MISALIGNED_MOVE_STRING_PROLOGUES_EPILOGUES \ - ix86_tune_features[TARGET_MISALIGNED_MOVE_STRING_PROLOGUES] + ix86_tune_features[X86_TUNE_MISALIGNED_MOVE_STRING_PROLOGUES] #define TARGET_QIMODE_MATH ix86_tune_features[X86_TUNE_QIMODE_MATH] #define TARGET_HIMODE_MATH ix86_tune_features[X86_TUNE_HIMODE_MATH] #define TARGET_PROMOTE_QI_REGS ix86_tune_features[X86_TUNE_PROMOTE_QI_REGS] My fault for using too long names. I wonder if we don't want to generate those TARGET_* from .def file, too. Honza
[Bug target/58853] [4.9 regression] ICE in expand_set_or_movmem_prologue_epilogue_by_misaligned_moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853 --- Comment #10 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jan Hubicka from comment #9) What confuses me is why TARGET_MISALIGNED_MOVE_STRING_PROLOGUES seems to be true given that DEF_TUNE (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES, misaligned_move_string_prologues, m_386 | m_486 | m_CORE_ALL | m_AMD_MULTIPLE | m_GENERIC) and we tune for pentiumpro (that was intentionally left out for this purpose) I think the problem is here: Index: config/i386/i386.h === --- config/i386/i386.h (revision 204166) +++ config/i386/i386.h (working copy) @@ -353,7 +353,7 @@ extern unsigned char ix86_tune_features[ #define TARGET_FAST_PREFIX ix86_tune_features[X86_TUNE_FAST_PREFIX] #define TARGET_SINGLE_STRINGOP ix86_tune_features[X86_TUNE_SINGLE_STRINGOP] #define TARGET_MISALIGNED_MOVE_STRING_PROLOGUES_EPILOGUES \ - ix86_tune_features[TARGET_MISALIGNED_MOVE_STRING_PROLOGUES] + ix86_tune_features[X86_TUNE_MISALIGNED_MOVE_STRING_PROLOGUES] #define TARGET_QIMODE_MATH ix86_tune_features[X86_TUNE_QIMODE_MATH] #define TARGET_HIMODE_MATH ix86_tune_features[X86_TUNE_HIMODE_MATH] #define TARGET_PROMOTE_QI_REGS ix86_tune_features[X86_TUNE_PROMOTE_QI_REGS] My fault for using too long names. I wonder if we don't want to generate those TARGET_* from .def file, too. Honza I'll prepare a patch (including HJ's fix) and change option to X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES with corresponding TARGET_MISALIGNED_MOVE_STRING_PRO_EPILOGUES (and will fix some grammatical issues on the way).
[Bug target/58853] [4.9 regression] ICE in expand_set_or_movmem_prologue_epilogue_by_misaligned_moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853 --- Comment #11 from Jan Hubicka hubicka at ucw dot cz --- I'll prepare a patch (including HJ's fix) and change option to X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES with corresponding TARGET_MISALIGNED_MOVE_STRING_PRO_EPILOGUES (and will fix some grammatical issues on the way). OK, thanks a lot for working on this! Honza
[Bug bootstrap/48474] gcc fails to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48474 --- Comment #4 from Mike Stump mikestump at comcast dot net --- patches to the gcc-patches list get lost and ignored. Bugzilla is forever. Looks like I chose wisely.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #23 from Nick Maclaren nmm1 at cam dot ac.uk --- (In reply to Vincent Lefèvre from comment #21) Richard Biener's approach to the default is the one that matches the C standard and Vincent Lefèvre is mistaken. No, I'm correct. Defining it to be 'off' and not setting __STDC_IEC_559__ is very reasonable. No, this is really stupid. If the user *decides* to set the STDC FENV_ACCESS pragma to on, then the compiler must not assume that it is off (this bug is not about the default state). At least it must behave in this way if -std=c99 (or c11) has been used. Otherwise a compilation failure may be better than getting wrong results. If __STDC_IEC_559__ is unset or does not have the value 1, setting STDC FENV_ACCESS to on is undefined behaviour (see 6.10.8.3, 7.6 and Annex F), unless the implementation explicitly chooses to extend the language to support it. So the user would get what he so richly deserves. (In reply to jos...@codesourcery.com from comment #22) So a key part of actually making rounding modes and exceptions work reliably would be working out a definition of GCC's default mode that allows more or less the same optimizations as at present, while allowing users wanting the full support (and consequent optimization cost) to specify the appropriate command-line options or FENV_ACCESS pragma to enable it. Yes. That won't deal with the correctness problems of introducing IEEE 754 support into code not set up to handle it, especially C++, of course. I tried to get WG21 to take a stand on that issue, but failed :-( Working out what on earth to do in such a case is likely to be a far fouler task than merely dealing with the performance problems :-(
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #2 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #1) Tom, do you know why this would be true on OS X? Offhand I do not know. I think there are a few things that could help us find out, though. One would be to see the gdb session. This would tell us which libstdc++ is being loaded. Another would be to attach the executable to the bug, assuming it is small enough (if too large -- write a minimal reproducer and attach it). Then I could look at the DWARF. I'm also curious exactly what options were used to build the executable. This can matter sometimes.
[Bug tree-optimization/56902] Fails to SLP with mismatched +/- and negatable constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56902 Cong Hou congh at google dot com changed: What|Removed |Added CC||congh at google dot com --- Comment #1 from Cong Hou congh at google dot com --- I just made a patch which supports limited non-isomorphic operations (operations on even/odd elements are still isomorphic) for SLP. Then the three loops you listed can be vectorized using SLP by using new VEC_ADDSUB_EXPR or VEC_SUBADD_EXPR. For x86, SSE3 provides ADDSUBPD/ADDSUBPS instructions which can do the job, but I also emulated them for SSE (use mask to negate the even/odd elements and then add). I think we will need to support more general non-isomorphic operations, which is more difficult and challenging. But I think the limited support in this patch is also useful at this time. I will send the patch later.
[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049 --- Comment #9 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Author: amylaar Date: Mon Nov 11 18:57:25 2013 New Revision: 204682 URL: http://gcc.gnu.org/viewcvs?rev=204682root=gccview=rev Log: PR middle-end/59049 * expmed.c (emit_store_flag): Fail for const-const comparison. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c
[Bug tree-optimization/59050] [4.9 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:7083
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050 --- Comment #4 from congh at gcc dot gnu.org --- Author: congh Date: Mon Nov 11 19:03:39 2013 New Revision: 204683 URL: http://gcc.gnu.org/viewcvs?rev=204683root=gccview=rev Log: 2013-11-11 Cong Hou co...@google.com PR tree-optimization/59050 * tree-vect-data-refs.c (comp_dr_addr_with_seg_len_pair): Bug fix. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #6 from Harald Anlauf anlauf at gmx dot de --- (In reply to Vittorio Zecca from comment #5) I do not think SIZE should be used to detect an undefined array pointer, but a size of zero warns the code that the array is mostly unusable and that perhaps something is wrong, while a nonzero size is telling the program it is fine to use the array. No. As Steve pointed out in comment #3, a zero sized array is perfectly fine. IMO that was a good choice in Fortran, so one does not have to special-case these when writing code. Your opinion may differ. Please also have a look at the Fortran standard, e.g. 13.7.156 SIZE (ARRAY [, DIM, KIND]) Description. Size of an array or one extent. Class. Inquiry function. Arguments. ARRAYshall be an array of any type. It shall not be an unallocated allocatable variable or a pointer that is not associated. ... I agree with Dominique, I am still writing invalid code all the time, also because interactive computing makes it so easy and fast to write, compile, link and execute code. When I used punched cards in the seventies I had more time to think and reflect about my programs, also because the turnaround time was about 30 minutes as compared with 30 seconds today If the programmers did not write invalid code many people would be out of business:-) Or they would be more productive...
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 58508, which changed state. Bug 58508 Summary: [Missed-Optimization] Redundant vector load of actual loop invariant in loop body. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/58508] [Missed-Optimization] Redundant vector load of actual loop invariant in loop body.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508 Cong Hou congh at google dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Cong Hou congh at google dot com --- (In reply to congh from comment #8) Author: congh Date: Fri Nov 8 18:44:46 2013 New Revision: 204590 URL: http://gcc.gnu.org/viewcvs?rev=204590root=gccview=rev Log: 2013-11-08 Cong Hou co...@google.com PR tree-optimization/58508 * gcc.dg/vect/pr58508.c: Update. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr58508.c
[Bug c++/58752] [C++11] Bogus error: ambiguous class template instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58752 --- Comment #7 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- (In reply to Daniel Krügler from comment #6) (In reply to Richard Smith from comment #4) Richard, could you please explain what precisely you meant with: Deducing #1 from #2 gives T=const U, which results in a deduction failure because enable_if...const U...::type is not 'void'. ? U is an arbitrary dependent type here, so enable_if...const U...::type is dependent, and is not the same type as void. Partial ordering does not consider the actual types deduced for the use of the template, so we don't know that U = char.
[Bug tree-optimization/59050] [4.9 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:7083
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050 Cong Hou congh at google dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Cong Hou congh at google dot com --- (In reply to congh from comment #4) Author: congh Date: Mon Nov 11 19:03:39 2013 New Revision: 204683 URL: http://gcc.gnu.org/viewcvs?rev=204683root=gccview=rev Log: 2013-11-11 Cong Hou co...@google.com PR tree-optimization/59050 * tree-vect-data-refs.c (comp_dr_addr_with_seg_len_pair): Bug fix. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug target/58853] [4.9 regression] ICE in expand_set_or_movmem_prologue_epilogue_by_misaligned_moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853 --- Comment #12 from uros at gcc dot gnu.org --- Author: uros Date: Mon Nov 11 20:02:19 2013 New Revision: 204685 URL: http://gcc.gnu.org/viewcvs?rev=204685root=gccview=rev Log: PR target/58853 * config/i386/x86-tune.def (X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES): Rename from TARGET_MISALIGNED_MOVE_STRING_PROLOGUES. * config/i386/i386.h (TARGET_MISALIGNED_MOVE_STRING_PRO_EPILOGUES): Rename from TARGET_MISALIGNED_MOVE_STRING_PROLOGUES_EPILOGUES. Update for renamed X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES. * config/i386/i386.c (ix86_expand_set_or_movmem): Use TARGET_MISALIGNED_MOVE_STRING_PRO_EPILOGUES to calculate misaligned_prologue_used. Check that desired_aling = epilogue_size_needed. testsuite/ChangeLog: PR target/58853 * gcc.target/i386/pr58853.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr58853.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/x86-tune.def trunk/gcc/testsuite/ChangeLog
[Bug c++/57734] Returning template alias to enum class fails with invalid declarator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57734 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug target/58853] [4.9 regression] ICE in expand_set_or_movmem_prologue_epilogue_by_misaligned_moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-11/msg01205.htm ||l Resolution|--- |FIXED --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- Fixed.
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642 --- Comment #24 from Uroš Bizjak ubizjak at gmail dot com --- Fixed?
[Bug c++/59079] New: a lambda with a parameter that depends on vector::value_type typedef leads to compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59079
Bug ID: 59079
Summary: a lambda with a parameter that depends on
vector::value_type typedef leads to compiler error
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ahu at ds9a dot nl
Created attachment 31194
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31194action=edit
small test file that fails to compile
Thanks for the c++2011 support, it makes me happy! However, the following fails
to compile in g++ 4.6.3 and 4.8.3 (at least), and I think it is valid c++2011.
#include vector
#include functional
templatetypename T
void buildvect(const T vect,
std::functiondouble(typename T::value_type) yTransform)
{}
int main()
{
std::vectorint blah{1,2,3,4};
buildvect(blah, [](int a) { return 1.0*a;});
}
Delivers:
t.cc: In function ‘int main()’:
t.cc:12:45: error: no matching function for call to
‘buildvect(std::vectorint, main()::__lambda0)’
buildvect(blah, [](int a) { return 1.0*a;});
^
t.cc:12:45: note: candidate is:
t.cc:5:6: note: templateclass T void buildvect(const T,
std::functiondouble(typename T::value_type))
void buildvect(const T vect,
^
t.cc:5:6: note: template argument deduction/substitution failed:
t.cc:12:45: note: ‘main()::__lambda0’ is not derived from
‘std::functiondouble(typename T::value_type)’
buildvect(blah, [](int a) { return 1.0*a;});
^
Does compile in clang 3.3, does compile if T::value_type is replaced by int.
Thanks!
[Bug c++/59080] New: [4.9 Regression] [c++11] ICE with array of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59080
Bug ID: 59080
Summary: [4.9 Regression] [c++11] ICE with array of auto
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++11) triggers an ICE
on trunk:
==
#include initializer_list
auto foo[] = {};
==
bug.cc:3:15: internal compiler error: Segmentation fault
auto foo[] = {};
^
0xb2a93f crash_signal
../../gcc/gcc/toplev.c:334
0x5dd6f9 tree_check5
../../gcc/gcc/tree.h:2792
0x5dd6f9 unify_array_domain
../../gcc/gcc/cp/pt.c:17027
0x5d46ae unify
../../gcc/gcc/cp/pt.c:17198
0x5ddf46 unify_one_argument
../../gcc/gcc/cp/pt.c:16100
0x5d2e73 type_unification_real
../../gcc/gcc/cp/pt.c:16172
0x5e6b82 do_auto_deduction(tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/pt.c:21402
0x57846c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6162
0x6661b1 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16693
0x66791f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11107
0x64b820 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10988
0x66f2e7 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10885
0x66e008 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10771
0x66f896 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4007
0x66f896 c_parse_file()
../../gcc/gcc/cp/parser.c:31107
0x790973 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1055
Please submit a full bug report, [etc.]
The regression appeared between 4.9.0 20131012 and 4.9.0 20131019.
[Bug c++/59081] New: GCC should forbid using a private member datatype in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59081
Bug ID: 59081
Summary: GCC should forbid using a private member datatype in
template class
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at gmail dot com
Hi,
GCC should emit an error in the C class when referencing A::B in the following
code (as clang does).
class A{
private:
struct B{} _b;
};
template typename T class C{
public:
A::B* _b;
};
Cvoid c;
Tested with gcc 4.8.2 and also the latest 4.9.0 trunk:
Using built-in specs.
COLLECT_GCC=/remote/intdeliv/seidelde/local/gcc/bin/../latest/bin/g++
COLLECT_LTO_WRAPPER=/remote/intdeliv/seidelde/local/gcc/4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-sources/configure --prefix
/remote/intdeliv/seidelde/local/gcc/4.8.2
--with-gmp=/remote/intdeliv/seidelde/local/gmp/5.1.3
--with-mpfr=/remote/intdeliv/seidelde/local/mpfr/3.1.2
--with-mpc=/remote/intdeliv/seidelde/local/mpc/1.0.1 --enable-lto
--disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.8.2 (GCC)
With clang I got the expected behavior:
rgeissler@ncegcolnx273:/tmp ~seidelde/local/clang/bin/clang++ -c test.cpp
test.cpp:8:12: error: 'B' is a private member of 'A'
A::B* _b;
^
test.cpp:3:16: note: declared private here
struct B{} _b;
^
1 error generated.
Cheers,
Romain
[Bug c++/59082] New: [4.7/4.8/4.9 Regression] ICE with duplicate (virtual) base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59082
Bug ID: 59082
Summary: [4.7/4.8/4.9 Regression] ICE with duplicate (virtual)
base
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet triggers an ICE since GCC 4.2.0:
struct A {};
struct B : virtual A, A {};
A foo(const B b)
{
return b;
}
bug.cc:3:23: error: duplicate base type 'A' invalid
struct B : virtual A, A {};
^
bug.cc: In function 'A foo(const B)':
bug.cc:7:10: internal compiler error: Segmentation fault
return b;
^
0xb2a93f crash_signal
../../gcc/gcc/toplev.c:334
0x618b2d contains_struct_check
../../gcc/gcc/tree.h:2819
0x618b2d build_vfield_ref(tree_node*, tree_node*)
../../gcc/gcc/cp/class.c:639
0x61816b build_base_path(tree_code, tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/class.c:429
0x553a0c convert_like_real
../../gcc/gcc/cp/call.c:6108
0x552e1e convert_like_real
../../gcc/gcc/cp/call.c:6086
0x55491c build_over_call
../../gcc/gcc/cp/call.c:6944
0x550f3e build_new_method_call_1
../../gcc/gcc/cp/call.c:7814
0x550f3e build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7884
0x551e87 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7441
0x553223 build_temp
../../gcc/gcc/cp/call.c:5784
0x553223 convert_like_real
../../gcc/gcc/cp/call.c:6128
0x5576d9 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:9019
0x6853c3 check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:8538
0x6c4bde finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:798
0x64d726 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:10590
0x64d726 cp_parser_statement
../../gcc/gcc/cp/parser.c:9284
0x64dcb9 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9654
0x64de2e cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9608
0x6614cb cp_parser_function_body
../../gcc/gcc/cp/parser.c:18461
Please submit a full bug report, [etc.]
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com --- Bootstrap of gcc-4.9-20131110 on sparc64-linux is also broken in the same way.
[Bug tree-optimization/59025] [4.9 Regression] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025 --- Comment #5 from Pat Haugen pthaugen at gcc dot gnu.org --- Well, it looks to be an interaction amongst 3 files from the benchmark. All 3 have to be compiled with r203979 compiler for the benchmark to fail (others are compiled with r203978). I captured assembler output from both revisions of the files and compared, all 3 have differences in code gen. Some are reassociation type diffs (i.e. swapped operands), the others look like the result of RA/scheduling differences. If you truly meant that no code gen differences should be present I could attatch any/all of the 3 files. Or if there is a specific dump/info I should look at and/or attach please let me know.
[Bug tree-optimization/59025] [4.9 Regression] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- If I remember well, there was one spot where it could result in swapped order of commutative operation's operand at the tree level, plus of course if RA/scheduling is affected by SSA_NAME_VERSION of the temporaries (or, because the new SSA_NAMEs intentionally are anonymous, while previously they could still be from some original vars with underlying decls on them, it could result in slightly different SSA partitioning). But none of that sounds like a compiler bug, perhaps just 435.gromacs worked with -ffast-math on ppc previously just by accident, perhaps the test isn't prepared to handle reordering of floating point operations allowed by -ffast-math?
[Bug c++/59079] a lambda with a parameter that depends on vector::value_type typedef leads to compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59079 bert hubert ahu at ds9a dot nl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from bert hubert ahu at ds9a dot nl --- Turns out that in trunk, this issue is fixed. Apologies for not testing against trunk first.
[Bug c++/59083] New: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 Bug ID: 59083 Summary: -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin.liska at gmail dot com Hello, I've encountered a new bug that was introduced by SVN commit: 204414. Program: gimp commit 88ecd59c3436d302b644a5d25c1938c0e7b60ae0 Author: Michael Natterer mi...@gimp.org Date: Tue Feb 5 20:43:53 2013 +0100 GCC: 204414 uname -a: Linux marxinbox 3.7.4-gentoo #6 SMP Mon Sep 30 20:53:52 CEST 2013 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux Build flags: CFLAGS=-flto=9 -fno-fat-lto-objects -O2 -fprofile-generate When I added -fno-isolate-erroneous-paths the program run correctly. Stacktrace: │0x988226 windows_actions_dock_window_added+646addq $0x1,0x6a8732(%rip)# 0x1030960 __gcov0.gimp_action_group_add_actions.lto_priv.4837+64 │ │0x98822e windows_actions_dock_window_added+654addq $0x1,0x6a87d2(%rip) # 0x1030a08 __gcov0.gimp_action_group_add_actions.lto_priv.4837+232 │ │0x988236 windows_actions_dock_window_added+662callq 0x820fa0 gimp_action_group_check_unique_action.lto_priv.5831 │ │0x98823b windows_actions_dock_window_added+667test %eax,%eax │ │0x98823d windows_actions_dock_window_added+669jne0x988258 windows_actions_dock_window_added+696 │ │0x98823f windows_actions_dock_window_added+671addq $0x1,0x6a8721(%rip)# 0x1030968 __gcov0.gimp_action_group_add_actions.lto_priv.4837+72 │ │0x988247 windows_actions_dock_window_added+679addq $0x1,0x6a87b1(%rip) # 0x1030a00 __gcov0.gimp_action_group_add_actions.lto_priv.4837+224 │ │0x98824f windows_actions_dock_window_added+687jmpq 0x988100 windows_actions_dock_window_added+352 │ │0x988254 windows_actions_dock_window_added+692nopl 0x0(%rax) │ │0x988258 windows_actions_dock_window_added+696mov$0x5,%edx │ │0x98825d windows_actions_dock_window_added+701mov $0xb8b6f6,%esi │ │0x988262 windows_actions_dock_window_added+706xor %edi,%edi │ │0x988264 windows_actions_dock_window_added+708callq 0x478da0 dcgettext@plt │ │0x988269 windows_actions_dock_window_added+713ud2 │ │0x98826bnopl 0x0(%rax,%rax,1) │ │0x988270 windows_actions_update_display_accelspush %r14 │ │0x988272 windows_actions_update_display_accels+2 mov %rdi,%r14 │
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-11 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- We need a testcase for this. ud2 translates to __builtin_trap so this could be a bug in their code still.
[Bug target/59054] Powerpc -O0 -mcpu=power7 generates sub-optimal code to load 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59054 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Mon Nov 11 22:27:03 2013 New Revision: 204689 URL: http://gcc.gnu.org/viewcvs?rev=204689root=gccview=rev Log: Apply patches for PR 59054 Added: branches/ibm/gcc-4_9-meissner/gcc/testsuite/gcc.target/powerpc/pr59054.c Modified: branches/ibm/gcc-4_9-meissner/gcc/ChangeLog.meissner branches/ibm/gcc-4_9-meissner/gcc/config/rs6000/rs6000.md branches/ibm/gcc-4_9-meissner/gcc/testsuite/ChangeLog.meissner
[Bug target/59078] autoincrement feature of NEON store instructions is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59078 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Note the use of autoincrement here might actually be slower due to dependent between instructions.
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #2 from Jeffrey A. Law law at redhat dot com --- I need a compilable/complete testcase. If a program is faulting with -fisolate-erroneous-paths, then that program is faulty in one way or another. It's dereferencing a null pointer, pass a null argument in a situation where the argument must be non-null, or returning a null pointer from a function declared as returning non-null.
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #3 from Alexander Timin altimin at altimin dot ru --- Created attachment 31195 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31195action=edit compiled dwarf file
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #5 from Alexander Timin altimin at altimin dot ru --- Created attachment 31197 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31197action=edit source code
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #4 from Alexander Timin altimin at altimin dot ru --- Created attachment 31196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31196action=edit compiled executable
[Bug c++/59081] GCC should forbid using a private member datatype in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59081 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Please check whether this is a duplicate of any of the Depends on bugs for PR 59002
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #6 from Alexander Timin altimin at altimin dot ru --- (In reply to Tom Tromey from comment #2) It has been compiled only with -g option. What do you mean by see gdb session? I don't understand. What should I do?
[Bug c++/59081] GCC should forbid using a private member datatype in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59081 --- Comment #2 from Romain Geissler romain.geissler at gmail dot com --- It looks similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 but in my case I used a second class, not a function. This issue is exactly like the one reported in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 by Jason Merrill 2013-03-27 13:28:24 UTC, but not like the one you reported first.
[Bug c++/47346] access control for nested type is ignored in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||romain.geissler at gmail dot com --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 59081 has been marked as a duplicate of this bug. ***
[Bug c++/59081] GCC should forbid using a private member datatype in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59081 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- dup then *** This bug has been marked as a duplicate of bug 47346 ***
[Bug target/59078] autoincrement feature of NEON store instructions is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59078 --- Comment #2 from Povilas Kanapickas tir5c3 at yahoo dot co.uk --- This would be very surprising, as a major use case for this instruction set feature would be eliminated. Unfortunately autoincrements are not mentioned anywhere in ARM documentation. However, I think a reasonable guess would be that ARM has implemented a special 'base register cache' in the memory subsystem that hides any additional latency auto-increments might cause otherwise. Anyway, my benchmarks on Cortex-A9 confirm that breaking dependencies between subsequent vector store instructions does not improve performance.
[Bug c/59084] New: Sub-optimal vector moves in AVX2 vectorized loop for unaligned loads.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59084
Bug ID: 59084
Summary: Sub-optimal vector moves in AVX2 vectorized loop for
unaligned loads.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hendrik.greving.intel at gmail dot com
The simple test case below produces sub-optimal split load/stores (AVX1/16
bytes), apparently due to the fact that g_a, g_b, g_c are put in a common
section which doesn't guarantee alignment. Compiling with -fno-common actually
produces good code. Only affects C, due to the described alignment issue above.
This bug might be related to or be a duplicate of #41464.
Sub-optimal code:
compiled with gcc -S -O3 -march=core-avx2 foo.c -ftree-vectorizer-verbose=1 -dp
-v -da
vmovdqu(%rsi,%rax), %xmm0# 160sse2_loaddquv16qi[length = 5]
vinserti128$0x1, 16(%rsi,%rax), %ymm0, %ymm0# 161
avx_vec_concatv32qi/1[length = 8]
addl$1, %edx# 165*addsi_1/1[length = 3]
vpaddd(%r8,%rax), %ymm0, %ymm0# 162*addv8si3/2[length = 6]
vmovups%xmm0, (%rcx,%rax)# 410*movv16qi_internal/3[length =
5]
vextracti128$0x1, %ymm0, 16(%rcx,%rax)# 164
vec_extract_hi_v32qi/2[leng
Good code:
compiled with gcc -S -O3 -march=core-avx2 foo.c -ftree-vectorizer-verbose=1 -dp
-v -da -fno-common
vmovdqag_a(%rax), %ymm0# 26*movv8si_internal/2[length = 8]
vpadddg_b(%rax), %ymm0, %ymm0# 27*addv8si3/2[length = 8]
addq$32, %rax# 29*adddi_1/1[length = 4]
vmovaps%ymm0, g_c-32(%rax)# 28*movv8si_internal/3[length =
8]
Test case:
#include stdio.h
#include stdint.h
#define LENGTH 1
int g_a[LENGTH];
int g_b[LENGTH];
int g_c[LENGTH];
void
foo()
{
int i ;
for (i = 0; i LENGTH; i++) {
g_c[i] = g_a[i] + g_b[i];
}
}
