[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #12 from Marc Glisse --- Created attachment 32586 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32586&action=edit Richard's small patch I regtested it (patch from comment #9 plus a testcase) on x86_64-linux-gnu and it passed. I think we should go with this in the short term. Would you care to handle it? Or should I post it for review by Joseph/Jason? The array-based expansion (for later) would require the same may_alias treatment. may_alias morally belongs to TYPE_QUALS (like const/volatile, it is safe to add, not to remove) and it is logical to propagate it in the same place.
[Bug target/60821] gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821 --- Comment #4 from a.h.jaffe at gmail dot com --- (In reply to Marek Polacek from comment #3) > Whoops, sorry. I better let Darwin folks look at it. Ah, but in fact *I* misunderstood. There's a difference between the FSF and Apple versions: "FSF GCC on Darwin does not create “fat” object files; it creates an object file for the single architecture that GCC was built to target" So I still think there's at least a "misfeature" in the sense that there should be a more graceful failure here, but in some sense the docs are right. However, a more general question: WHY doesn't FSF gcc have this capability?
[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #13 from rguenther at suse dot de --- On April 12, 2014 10:30:31 AM CEST, "glisse at gcc dot gnu.org" wrote: >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 > >--- Comment #12 from Marc Glisse --- >Created attachment 32586 > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32586&action=edit >Richard's small patch > >I regtested it (patch from comment #9 plus a testcase) on >x86_64-linux-gnu and >it passed. I think we should go with this in the short term. Would you >care to >handle it? Or should I post it for review by Joseph/Jason? I'll handle it. Plus i'll look into the expansion issue. >The array-based expansion (for later) would require the same may_alias >treatment. may_alias morally belongs to TYPE_QUALS (like >const/volatile, it is >safe to add, not to remove) and it is logical to propagate it in the >same >place.
[Bug c/50459] alignof doesn't work on plain old constant, works with expressions containing it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50459 Marc Glisse changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-12 Target Milestone|--- |4.10.0 Ever confirmed|0 |1 Known to fail||4.9.0
[Bug other/60828] Compile time speedups when using tcmalloc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60828 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Markus Trippelsdorf --- In the case of clang, that uses heap allocations a lot more than gcc, the speedup is almost doubled: Firefox -O3 (clang): glibc malloc: 2305.72s user 60.49s system 331% cpu 11:54.73 total0% speedup tcmalloc: 2201.04s user 78.25s system 355% cpu 10:41.27 total 10.3% speedup jemalloc: 2231.16s user 102.52s system 342% cpu 11:21.12 total 4.7% speedup I will close this issue, because it really should be moved to the glibc bugzilla.
[Bug target/60822] Index register overwritten on m68k/coldfire
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60822 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- Created attachment 32587 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32587&action=edit self-contained test case in C Doesn't need C++, this C version reproduces the wrong-code on m68k-linux with -mcpu=68010, but not with -mcpu=68020 or higher. Occurs with gcc 4.9-20140406 and 4.7-20140308 (haven't checked other versions yet).
[Bug target/60822] Index register overwritten on m68k/coldfire
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60822 --- Comment #2 from Mikael Pettersson --- All versions from current 4.10/trunk down to and including 4.4.7 have the bug, but 4.3.6 does not. The code from 4.3.6 is similar to the one from 4.4.7, but due to a subtle ordering difference 4.3.6 works while 4.4.7 does not.
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #13 from Kirill Yukhin --- Author: kyukhin Date: Sat Apr 12 17:57:15 2014 New Revision: 209336 URL: http://gcc.gnu.org/viewcvs?rev=209336&root=gcc&view=rev Log: gcc/c/ PR middle-end/60469 * c-array-notation.c (fix_builtin_array_notation_fn): Use create_tmp_var instead build_decl for creating temps. (build_array_notation_expr): Likewise. (fix_conditional_array_notations_1): Likewise. (fix_array_notation_expr): Likewise. (fix_array_notation_call_expr): Likewise. gcc/testsuite/ PR middle-end/60469 * c-c++-common/cilk-plus/CK/pr60469.c: New test. Added: trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr60469.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-array-notation.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/60467] ICE with -fcilkplus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60467 --- Comment #3 from Kirill Yukhin --- Author: kyukhin Date: Sat Apr 12 17:59:29 2014 New Revision: 209337 URL: http://gcc.gnu.org/viewcvs?rev=209337&root=gcc&view=rev Log: gcc/c-family/ PR middle-end/60467 * cilk.c (cilk_set_spawn_marker): Remove FUNCTION_DECL as possible argument for Cilk_spawn. gcc/testsuite/ PR middle-end/60467 * c-c++-common/cilk-plus/CK/invalid_spawns.c: Add new invalid case to check. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/cilk.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/invalid_spawns.c
[Bug fortran/60810] [4.7/4.8/4.9/4.10 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 --- Comment #9 from Jerry DeLisle --- Author: jvdelisle Date: Sat Apr 12 18:42:15 2014 New Revision: 209338 URL: http://gcc.gnu.org/viewcvs?rev=209338&root=gcc&view=rev Log: 2014-04-12 Jerry DeLisle PR libfortran/60810 io/unit.c (is_trim_ok): If internal unit is array, do not trim. Modified: branches/gcc-4_9-branch/libgfortran/ChangeLog branches/gcc-4_9-branch/libgfortran/io/unit.c
[Bug fortran/60810] [4.7/4.8/4.9/4.10 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 --- Comment #10 from Jerry DeLisle --- Author: jvdelisle Date: Sat Apr 12 18:50:53 2014 New Revision: 209339 URL: http://gcc.gnu.org/viewcvs?rev=209339&root=gcc&view=rev Log: 2014-04-12 Jerry DeLisle PR libfortran/60810 gfortran.dg/arrayio_13.f90: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/arrayio_13.f90 Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/60822] Index register overwritten on m68k/coldfire
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60822 --- Comment #3 from Mikael Pettersson --- Started with r140275: 2008-09-11 Andreas Schwab * config/m68k/m68k.h (IRA_COVER_CLASSES): Define. which seems to enable IRA for M68K. The code generation difference for the C test case at this revision is: --- pr60822-r140274.s 2014-04-12 20:50:32.324607341 +0200 +++ pr60822-r140275.s 2014-04-12 20:46:21.835089754 +0200 @@ -9,10 +9,10 @@ link.w %fp,#0 move.l %d2,-(%sp) move.l 8(%fp),%a0 - move.l #80,%d1 - move.l #174,%d0 - move.l (%a0,%d1.l),%d1 - add.l (%a0,%d0.l),%d1 + move.l #80,%d0 + move.l #174,%d1 + move.l (%a0,%d0.l),%d1 + add.l (%a0,%d1.l),%d1 smi %d0 ext.w %d0 ext.l %d0 I assume this revision merely exposed a pre-existing latent problem.
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #14 from Jakub Jelinek --- Please don't forget to backport the Cilk+ bugfixes to 4.9 branch after 4.9.0 is released, as long as they are small and non-risky.
[Bug c++/60463] Lambda function can call a non-const member function with const this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60463
Momchil Velikov changed:
What|Removed |Added
CC||momchil.velikov at gmail dot
com
--- Comment #1 from Momchil Velikov ---
Just stumbled upon essentially the same problem with
c++ (GCC) 4.10.0 20140412 (experimental) [master revision
094da06:e25c6c8:855372a3d3c40b76fed8ff368d37b77d14a488eb]
#include
struct S {
void foo() const;
void bar();
int x = 0;
};
void S::foo() const {
auto f = [&]() { bar(); };
f();
std::cout << x << std::endl;
}
void S::bar() { ++x; }
int main() {
S s;
s.foo();
return 0;
}
[Bug c++/60755] lambda capturing `this` doesn't honor const qualifier of the enclosing member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60755 Momchil Velikov changed: What|Removed |Added CC||momchil.velikov at gmail dot com --- Comment #2 from Momchil Velikov --- Possible duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60463
[Bug sanitizer/59758] [4.9/4.10 Regression] bootstrap failure in libsanitizer/asan on sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758 Aaro Koskinen changed: What|Removed |Added CC||aaro.koskinen at iki dot fi --- Comment #5 from Aaro Koskinen --- The bug is still present in gcc-4.9.0-RC-20140411.
[Bug target/60821] gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821 Iain Sandoe changed: What|Removed |Added Target||*-darwin* Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-12 CC||iains at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #5 from Iain Sandoe --- (In reply to a.h.jaffe from comment #4) > (In reply to Marek Polacek from comment #3) > > "FSF GCC on Darwin does not create “fat” object files; it creates an object > file for the single architecture that GCC was built to target" indeed - see below. > So I still think there's at least a "misfeature" in the sense that there > should be a more graceful failure here, but in some sense the docs are right. Hmm .. not sure how much leeway we have here (the general behaviour of the driver is to allow multiple instances of flags [e.g. -O2 -O0] and take the last one found). If we issued an error for multiple "-arch" it would be inconsistent. > However, a more general question: WHY doesn't FSF gcc have this capability? 1. The behaviour of the *underlying* GCC on Apple's installs is the same as FSF-gcc - each version of the compiler generates output for one kind of target/multilib combination and only one binary/invocation. 2. The "Apple GCC" is, in fact, an additional driver layer (you can find it as driverdriver.c in thier sources). This 'driverdriver' invokes the underlying compiler for each mentioned value of "arch" and then combines the outputs using 'lipo' to make a FAT files. 3. There is nothing to stop a distro (like macports or fink) from making a similar provision; sometimes in the past, I built the "driverdriver" for my own use. However, note that significant updating would be needed to deal with recent versions of FSF-GCC. 4. Darwin support resources are very slim for FSF (we're all volunteers) - and although it's a "nice to have" (definitely!!) I regret not high on the priority list compared with bug fixes. 5. We do accept -arch on x86: -arch i386 gets mapped => -m32 and -arch x86_64 -> -m64. The last one you place on the c/l will be in force (and there's NO support for the ppc equivalent at present). SO… … re-filing this as an enhancement request. Patches welcome!
[Bug fortran/60810] [4.7/4.8/4.9/4.10 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 --- Comment #11 from Jerry DeLisle --- Author: jvdelisle Date: Sat Apr 12 22:52:10 2014 New Revision: 209340 URL: http://gcc.gnu.org/viewcvs?rev=209340&root=gcc&view=rev Log: 2014-04-12 Jerry DeLisle Backport from mainline PR libfortran/60810 io/unit.c (is_trim_ok): If internal unit is array, do not trim. Backport from mainline PR libfortran/60810 gfortran.dg/arrayio_13.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/arrayio_13.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/unit.c
[Bug fortran/60810] [4.7/4.8/4.9/4.10 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 --- Comment #12 from Jerry DeLisle --- Author: jvdelisle Date: Sun Apr 13 02:05:02 2014 New Revision: 209345 URL: http://gcc.gnu.org/viewcvs?rev=209345&root=gcc&view=rev Log: 2014-04-12 Jerry DeLisle Backport from mainline PR libfortran/60810 gfortran.dg/arrayio_13.f90: New test. PR libfortran/60810 io/unit.c (is_trim_ok): If internal unit is array, do not trim. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/arrayio_13.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/unit.c
