[Bug target/62308] A bug with aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308 Yvan Roux yroux at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org, ||yroux at gcc dot gnu.org --- Comment #4 from Yvan Roux yroux at gcc dot gnu.org --- yes, and there is no issue when we use reload instead of LRA (flag -mno-lra).
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
Zhenqiang Chen zhenqiang.chen at arm dot com changed:
What|Removed |Added
CC||zhenqiang.chen at arm dot com
--- Comment #20 from Zhenqiang Chen zhenqiang.chen at arm dot com ---
Here is a small case to show lra introduces one more register copy (tested with
trunk and 4.9).
int isascii (int c)
{
return c = 0 c 128;
}
With options: -Os -mthumb -mcpu=cortex-m0, I got
isascii:
movr3, #0
movr2, #127
movr1, r3 //???
cmpr2, r0
adcr1, r1, r3
movr0, r1
bxlr
With options: -Os -mthumb -mcpu=cortex-m0 -mno-lra, I got
isascii:
movr2, #127
movr3, #0
cmpr2, r0
adcr3, r3, r3
movr0, r3
bxlr
[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409 --- Comment #7 from Freddie Chopin freddie_chopin at op dot pl --- Great (; Do you have some timeline? I'm not trying to rush you - I'm just working on a project in which this feature would be beneficial, so I'm wondering whether I should wait a bit (this particular requirement is not top-priority) or maybe just implement the allocator the old way for now. Thanks in advance!
[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 --- Comment #8 from Andrey Ryabinin ryabinin.a.a at gmail dot com --- Hi, may I ask what's the status of this? Besides of section mismatches in linux kernel it also breaks kernel's modules. Variable __this_module doesn't get into section .gnu.linkonce.this_module, therefore module refuses to load.
[Bug fortran/61881] ICE in gfc_conv_intrinsic_to_class with assumed-rank CLASS(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61881 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Sep 3 06:41:37 2014 New Revision: 214843 URL: https://gcc.gnu.org/viewcvs?rev=214843root=gccview=rev Log: Missed that file in r213079 of 2014-07-26 2014-09-03 Tobias Burnus bur...@net-b.de PR fortran/61881 PR fortran/61888 PR fortran/57305 * gfortran.dg/sizeof_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/sizeof_4.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/61888] Wrong results with SIZEOF and assumed-rank arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61888 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Sep 3 06:41:37 2014 New Revision: 214843 URL: https://gcc.gnu.org/viewcvs?rev=214843root=gccview=rev Log: Missed that file in r213079 of 2014-07-26 2014-09-03 Tobias Burnus bur...@net-b.de PR fortran/61881 PR fortran/61888 PR fortran/57305 * gfortran.dg/sizeof_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/sizeof_4.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Sep 3 06:41:37 2014 New Revision: 214843 URL: https://gcc.gnu.org/viewcvs?rev=214843root=gccview=rev Log: Missed that file in r213079 of 2014-07-26 2014-09-03 Tobias Burnus bur...@net-b.de PR fortran/61881 PR fortran/61888 PR fortran/57305 * gfortran.dg/sizeof_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/sizeof_4.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/62663] m68k / coldfire : compiling with -msep-data breaks the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62663 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- Then this is most likely a linker bug, not setting up the GOT correctly.
[Bug fortran/63152] New: needless initialization of local pointer arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Bug ID: 63152
Summary: needless initialization of local pointer arrays.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
I've noticed that for this code:
SUBROUTINE S1()
INTEGER, POINTER, DIMENSION(:) :: v
INTERFACE
SUBROUTINE foo(v)
INTEGER, POINTER, DIMENSION(:) :: v
END SUBROUTINE
END INTERFACE
CALL foo(v)
END SUBROUTINE S1
gfortran initializes the pointer (to zero) even if '-fno-init-local-zero' :
s1 ()
{
struct array1_integer(kind=4) v;
v.data = 0B;
foo (v);
}
I don't think this is mandated (other compilers don't)
I'm working on a patch.
[Bug fortran/63152] needless initialization of local pointer arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-03 CC||Joost.VandeVondele at mat dot ethz ||.ch Assignee|unassigned at gcc dot gnu.org |Joost.VandeVondele at mat dot ethz ||.ch Ever confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- working on a patch.
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Here's a small testcase:
markus@x4 tmp % cat cppcodemodelinspectordialog.ii
namespace CppTools
{
class A
{
public:
virtual void headerPaths () = 0;
};
namespace Internal
{
class CppModelManager : CppTools::A
{
void
headerPaths ()
{
ensureUpdated ();
}
void ensureUpdated ();
};
}
}
CppTools::A *a;
void
fn1 ()
{
a-headerPaths ();
}
(before r214208)
markus@x4 tmp % g++ -Wl,--no-undefined -shared -fPIC -O2
cppcodemodelinspectordialog.ii
markus@x4 tmp %
(after r214208)
markus@x4 tmp % g++ -Wl,--no-undefined -shared -fPIC -O2
cppcodemodelinspectordialog.ii
/tmp/ccMZQE0g.o:cppcodemodelinspectordialog.ii:function fn1(): error: undefined
reference to 'CppTools::Internal::CppModelManager::ensureUpdated()'
/tmp/ccMZQE0g.o:cppcodemodelinspectordialog.ii:function
CppTools::Internal::CppModelManager::headerPaths(): error: undefined reference
to 'CppTools::Internal::CppModelManager::ensureUpdated()'
collect2: error: ld returned 1 exit status
(one can use -fno-devirtualize-speculatively as a workaround)
markus@x4 tmp % g++ -Wl,--no-undefined -fno-devirtualize-speculatively -shared
-fPIC -O2 cppcodemodelinspectordialog.ii
markus@x4 tmp %
[Bug fortran/63153] New: pointers are not nullified with -finit-local-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63153
Bug ID: 63153
Summary: pointers are not nullified with -finit-local-zero
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
scalar pointers are not nullified with -finit-local-zero . After the fix for
PR63152, also arrays with the pointer attribute might need this.
cat bug.f90
SUBROUTINE S1()
INTEGER, POINTER :: w
IF (ASSOCIATED(w)) CALL ABORT()
END SUBROUTINE S1
gfortran -fdump-tree-original -finit-local-zero -g -c bug.f90
cat bug.f90.003t.original
s1 ()
{
integer(kind=4) * w;
if (w != 0B)
{
_gfortran_abort ();
}
L.1:;
}
[Bug target/61330] [5 Regression] Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330 --- Comment #9 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Wed Sep 3 07:23:01 2014 New Revision: 214847 URL: https://gcc.gnu.org/viewcvs?rev=214847root=gccview=rev Log: gcc/ 2014-09-03 Yvan Roux yvan.r...@linaro.org Backport from trunk r214526. 2014-08-26 Joseph Myers jos...@codesourcery.com PR target/60606 PR target/61330 * varasm.c (make_decl_rtl): Clear DECL_ASSEMBLER_NAME and DECL_HARD_REGISTER and return for invalid register specifications. * cfgexpand.c (expand_one_var): If expand_one_hard_reg_var clears DECL_HARD_REGISTER, call expand_one_error_var. * config/arm/arm.c (arm_hard_regno_mode_ok): Do not allow CC_REGNUM with non-MODE_CC modes. (arm_regno_class): Return NO_REGS for PC_REGNUM. gcc/testsuite/ 2014-09-03 Yvan Roux yvan.r...@linaro.org Backport from trunk r214526. 2014-08-26 Joseph Myers jos...@codesourcery.com PR target/60606 PR target/61330 * gcc.dg/torture/pr60606-1.c, gcc.target/arm/pr60606-2.c, gcc.target/arm/pr60606-3.c, gcc.target/arm/pr60606-4.c: New tests. Added: branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr60606-1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-2.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-3.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-4.c Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/cfgexpand.c branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.c branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/varasm.c
[Bug target/60606] [ARM] ICE with asm (mov ..., pc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606 --- Comment #9 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Wed Sep 3 07:23:01 2014 New Revision: 214847 URL: https://gcc.gnu.org/viewcvs?rev=214847root=gccview=rev Log: gcc/ 2014-09-03 Yvan Roux yvan.r...@linaro.org Backport from trunk r214526. 2014-08-26 Joseph Myers jos...@codesourcery.com PR target/60606 PR target/61330 * varasm.c (make_decl_rtl): Clear DECL_ASSEMBLER_NAME and DECL_HARD_REGISTER and return for invalid register specifications. * cfgexpand.c (expand_one_var): If expand_one_hard_reg_var clears DECL_HARD_REGISTER, call expand_one_error_var. * config/arm/arm.c (arm_hard_regno_mode_ok): Do not allow CC_REGNUM with non-MODE_CC modes. (arm_regno_class): Return NO_REGS for PC_REGNUM. gcc/testsuite/ 2014-09-03 Yvan Roux yvan.r...@linaro.org Backport from trunk r214526. 2014-08-26 Joseph Myers jos...@codesourcery.com PR target/60606 PR target/61330 * gcc.dg/torture/pr60606-1.c, gcc.target/arm/pr60606-2.c, gcc.target/arm/pr60606-3.c, gcc.target/arm/pr60606-4.c: New tests. Added: branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr60606-1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-2.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-3.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-4.c Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/cfgexpand.c branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.c branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/varasm.c
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224 --- Comment #12 from Chris Clayton chris2553 at googlemail dot com --- Sorry, you'll have to stick with me here while a figure out what that means. I think you are saying that prior to r214208, the symbols definedMacros() and headerPaths() were present but effectively no-ops. Post r214208 they now contain operations including calls to ensureUpdated(). Given that the symbol for ensureUpdated() appears to be present in libCppTools.so (along with the symbols for its two post-r214208 callers), does that suggest a problem with the linker, which is /usr/bin/ld from the latest version (2.24) of binutils? Or could it be anything to do with my system being a 32bit userspace on a 64bit kernel? I usually build packages as rpms and have the rpm binary wrapped in a script which uses prefixes the call to the actual rpm binary with setarch i386. I've been careful whilst investigated this problem to make sure that I prefix calls to qmake and make with setarch i386. I've built loads and loads of packages with this setup (including gcc). I'm just trying to figure out the next port of call with this problem. I note that the Debian folks have a bug logged but seem to be waiting on resolution via this bug report - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759862.
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224 --- Comment #13 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Chris Clayton from comment #12) Sorry, you'll have to stick with me here while a figure out what that means. I think you are saying that prior to r214208, the symbols definedMacros() and headerPaths() were present but effectively no-ops. Post r214208 they now contain operations including calls to ensureUpdated(). Given that the symbol for ensureUpdated() appears to be present in libCppTools.so (along with the symbols for its two post-r214208 callers), does that suggest a problem with the linker, which is /usr/bin/ld from the latest version (2.24) of binutils? No. This has nothing to do with libCppTools.so. As I wrote before the build system of qt-creator must be changed to provide the missing symbol by simply adding cppmodelmanager.o to the libCppEditor.so link command.
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 --- Comment #21 from Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com --- I filed this previously, maybe its duplicate Bug 61578 - Code size increase for ARM thumb compared to 4.8.x when compiling with -Os BR Fredrik
[Bug target/62662] [4.9/5 Regression] Miscompilation of Qt on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62662 --- Comment #5 from Andreas Krebbel krebbel at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) I agree that this is something we need to fix in the back-end. I was just curious about when this surfaced first and keep that info for the records.
[Bug bootstrap/61078] [5 Regression] ESA mode bootstrap failure since r209897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61078 --- Comment #8 from Andreas Krebbel krebbel at gcc dot gnu.org --- Author: krebbel Date: Wed Sep 3 08:06:09 2014 New Revision: 214850 URL: https://gcc.gnu.org/viewcvs?rev=214850root=gccview=rev Log: 2014-09-03 Andreas Krebbel andreas.kreb...@de.ibm.com PR target/61078 * config/s390/s390.md (*negdi2_31): Add s390_split_ok_p check and add a second splitter to handle the remaining cases. 2014-09-03 Andreas Krebbel andreas.kreb...@de.ibm.com PR target/61078 * gcc.target/s390/pr61078.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/s390/pr61078.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/63152] needless initialization of local pointer arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added URL||https://gcc.gnu.org/ml/fort ||ran/2014-09/msg00016.html --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- WIP patch at URL
[Bug bootstrap/61078] [5 Regression] ESA mode bootstrap failure since r209897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61078 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Andreas Krebbel krebbel at gcc dot gnu.org --- Fixed per comment 8
[Bug middle-end/61654] [4.9/5 Regression] ICE in release_function_body, at cgraph.c:1699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61654 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Known to fail|4.10.0 |5.0 --- Comment #12 from Martin Jambor jamborm at gcc dot gnu.org --- I have proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00207.html
[Bug ipa/61986] ICE on valid code at -O3 on x86_64-linux-gnu indecide_about_value, at ipa-cp.c:3480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- I have proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00209.html
[Bug ipa/62015] [4.8/4.9/5 Regression] ipa-cp-clone uses a clone that is too specialized for the call context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- I have proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00210.html
[Bug regression/63150] [4.9/5 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.3 Target Milestone|--- |4.9.2 Summary|[4.9 regression] FAIL: |[4.9/5 regression] FAIL: |gcc.target/powerpc/pr53199. |gcc.target/powerpc/pr53199. |c scan-assembler-times *|c scan-assembler-times *
[Bug tree-optimization/63148] r187042 causes auto-vectorization failure for X86 for -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63148 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- This has been fixed on the 4.8 branch already, I think this is a duplicate of PR60276. *** This bug has been marked as a duplicate of bug 60276 ***
[Bug tree-optimization/60276] [4.7 Regression] -O3 autovectorizer breaks on a particular loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||doug.gilmore at imgtec dot com --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 63148 has been marked as a duplicate of this bug. ***
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- You might want to try -fsanitize=undefined and/or -fno-strict-overflow as it sounds like you may be invoking undefined behavior.
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224
--- Comment #14 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #13)
(In reply to Chris Clayton from comment #12)
Sorry, you'll have to stick with me here while a figure out what that means.
I think you are saying that prior to r214208, the symbols definedMacros()
and headerPaths() were present but effectively no-ops. Post r214208 they now
contain operations including calls to ensureUpdated().
Given that the symbol for ensureUpdated() appears to be present in
libCppTools.so (along with the symbols for its two post-r214208 callers),
does that suggest a problem with the linker, which is /usr/bin/ld from the
latest version (2.24) of binutils?
No. This has nothing to do with libCppTools.so. As I wrote before the
build system of qt-creator must be changed to provide the missing symbol
by simply adding cppmodelmanager.o to the libCppEditor.so link command.
Out of curiosity, I have downloaded and tried to build qt-creator-3.2.0.
The build failed exactly as you described in commment 0.
The fix is simple, just add __attribute__ ((visibility (default))) to
CppModelManager::ensureUpdated() in src/plugins/cpptools/cppmodelmanager.cpp:
294 __attribute__ ((visibility (default)))
295 void CppModelManager::ensureUpdated()
296 {
This will make _ZN8CppTools8Internal15CppModelManager13ensureUpdatedEv external
for libCppTools.so and everything is fine.
[Bug testsuite/53155] Not parallel: test for -j fails with new make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-03 CC||Joost.VandeVondele at mat dot ethz ||.ch Ever confirmed|0 |1 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- still fails. Honestly, this made contributing my first patches much slower, as testing took ages to complete.
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Or -fno-aggressive-loop-optimizations. From your description it is hard to figure what exactly to look for in the assembly, so e.g. bisecting compiler where it stopped working is not easy.
[Bug tree-optimization/55334] [4.8/4.9/5 Regression] mgrid regression (ipa-cp disables vectorization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #39 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Vidya Praveen from comment #38) Until we fix this issue, could we have workaround posted by Martin Jambor (comment #29) applied again on 4.9 and trunk? No, not on trunk please. As I said on IRC yesterday. Before we even consider this for the 4.9 branch, please verify that inlining does not cause the same problems with the benchmark (on the particular architecture you care for). It is certainly capable of doing that and we certainly do not want to switch inlining off :-)
[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49444 bin.cheng amker.cheng at gmail dot com changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #8 from bin.cheng amker.cheng at gmail dot com --- This should be fixed on trunk now. At least for r211210 and r214864. For Andrew's test, the generated mips assmbly for kernel loop is as below. $L3: lwl$5,1($16) lwl$4,5($16) lwl$3,9($16) lwr$5,4($16) lwr$4,8($16) lwr$3,12($16) lw$2,%gp_rel(ss)($28) addiu$16,$16,13 sw$5,0($2) sw$4,4($2) jalg sw$3,8($2) bne$16,$17,$L3 move$2,$0 For Richard's case (with an explicit conversion when calling foo), the generated mips assembly is as below. foo: .frame$sp,0,$31# vars= 0, regs= 0/0, args= 0, gp= 0 .mask0x,0 .fmask0x,0 .setnoreorder .setnomacro lwl$2,0($4) nop lwr$2,3($4) j$31 nop .setmacro .setreorder .endfoo .sizefoo, .-foo Apparently, lwl/lwr are generated for unalgned memory access. Thanks, bin
[Bug tree-optimization/55334] [4.8/4.9/5 Regression] mgrid regression (ipa-cp disables vectorization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #40 from rguenther at suse dot de rguenther at suse dot de --- nOn Wed, 3 Sep 2014, jamborm at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #39 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Vidya Praveen from comment #38) Until we fix this issue, could we have workaround posted by Martin Jambor (comment #29) applied again on 4.9 and trunk? No, not on trunk please. As I said on IRC yesterday. Before we even consider this for the 4.9 branch, please verify that inlining does not cause the same problems with the benchmark (on the particular architecture you care for). It is certainly capable of doing that and we certainly do not want to switch inlining off :-) Inlining will certainly cause the same problem.
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #5 from Ralf Hoffmann gcc at boomerangsworld dot de --- Thanks for the feedback, I am also suspecting I have some problem in my code regarding undefined behavior. What I do for testing is to compile my tool Worker (http://www.boomerangsworld.de/cms/worker/index.html, version 3.5.0) with make clean LDFLAGS=-fsanitize=undefined CPPFLAGS=-fsanitize=undefined ./configure make and then start the program (src/worker), click on top left A button for the about dialog and click on the down arrow to scroll down the option list. It then either works, or the process hangs in the endless loop. I tried to use -fsanitize=undefined and it actually makes a difference. There is no compiler output pointing out some problem and also no runtime output when reaching the test point mentioned above. But with this option, it behaves normally and the endless loop does not occur. When using the options -fno-strict-overflow or -fno-aggressive-loop-optimizations the problem still occurs. I would like to help bisecting the compiler if you could give me a hint where to start. As far as I see, there is no git repo which would make it easier.
[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49444 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Thus dup of PR61320?
[Bug c/62024] __atomic_always_lock_free is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Sep 3 11:16:29 2014 New Revision: 214871 URL: https://gcc.gnu.org/viewcvs?rev=214871root=gccview=rev Log: PR c/62024 * c-parser.c (c_parser_static_assert_declaration_no_semi): Strip no-op conversions. * g++.dg/cpp0x/pr62024.C: New test. * gcc.dg/pr62024.c: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr62024.C trunk/gcc/testsuite/gcc.dg/pr62024.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/testsuite/ChangeLog
[Bug c/62024] __atomic_always_lock_free is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be fixed.
[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- It will be done for the GCC 5.0 release.
[Bug lto/62026] [4.9/5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org --- I'm sorry but I cannot reproduce the problem with the attached testcase. I will try the libxul link.
[Bug other/63155] New: [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 Bug ID: 63155 Summary: [4.9/5 Regression] memory hog Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 33441 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33441action=edit preprocessed source [forwarded from https://bugs.debian.org/759683] compiling the attached test case with the 4.9 branch r214759 and trunk r213954 takes about 90sec on x86_64 and 10GB of memory. succeeds with the 4.8 branch in less than a second. $ gcc -std=c99 -c testunity_Runner.i from the Debian issue: Notice that replacing _setjmp (Unity.AbortFrame[Unity.CurrentAbortFrame]) in main function by _setjmp (Unity.AbortFrame[0]), make gcc works normaly. After few tests it seems that gcc does not like having a variable in here. I don't see the crash reported in the Debian issue.
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- There is a git mirror of the svn repo. Anyway, -fsanitize=undefined enables -fno-delete-null-pointer-checks, perhaps you could try that option alone if it makes a difference.
[Bug libstdc++/62259] atomic class doesn't enforce required alignment on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259
Ulrich Weigand uweigand at gcc dot gnu.org changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment #1 from Ulrich Weigand uweigand at gcc dot gnu.org ---
Indeed, when running a simple test program:
#include atomic
#include stdio.h
struct twoints {
int a;
int b;
};
int main(void) {
printf(%d\n, __alignof__ (twoints));
printf(%d\n, __alignof__ (std::atomictwoints));
return 0;
}
we see that the GCC only requires 4 bytes of alignment for the atomic type.
However, with the equivalent C11 code using the _Atomic keyword
#include stdatomic.h
#include stdio.h
struct twoints {
int a;
int b;
};
int main() {
printf(%d\n, __alignof__ (struct twoints));
printf(%d\n, __alignof__ (_Atomic (struct twoints)));
return 0;
}
we get an alignment requirement of 8 bytes for the atomic type.
In the C case, this is done by the compiler front-end where it implements the
_Atomic keyword. In the C++ case, it seems the compiler doesn't really get
involved, as it's all done in plain C++ in standard library code ...
I suspect the intent was that for C++, we likewise ought to have an increased
alignment requirement for the type, but I'm not sure how to implement this in
the library. Need some of the library experts to comment here.
[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49444 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Richard Biener from comment #9) Thus dup of PR61320? Yes. *** This bug has been marked as a duplicate of bug 61320 ***
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #69 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 49444 has been marked as a duplicate of this bug. ***
[Bug c/62294] [4.9 Regression] Missing passing argument [...] from incompatible pointer type warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Sep 3 12:54:06 2014 New Revision: 214874 URL: https://gcc.gnu.org/viewcvs?rev=214874root=gccview=rev Log: PR c/62294 * c-typeck.c (convert_arguments): Get location of a parameter. Change error and warning calls to error_at and warning_at. Pass location of a parameter to it. (convert_for_assignment): Add parameter to WARN_FOR_ASSIGNMENT and WARN_FOR_QUALIFIERS. Pass expr_loc to those. * gcc.dg/pr56724-1.c: New test. * gcc.dg/pr56724-2.c: New test. * gcc.dg/pr62294.c: New test. * gcc.dg/pr62294.h: New file. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr56724-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr56724-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr62294.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr62294.h Modified: branches/gcc-4_9-branch/gcc/c/ChangeLog branches/gcc-4_9-branch/gcc/c/c-typeck.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c/62294] [4.9 Regression] Missing passing argument [...] from incompatible pointer type warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed. I'll add the new test to trunk as well.
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #7 from Ralf Hoffmann gcc at boomerangsworld dot de --- Created attachment 33442 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33442action=edit simplified example file 1 simple example containing the code piece which triggers the behavior
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #8 from Ralf Hoffmann gcc at boomerangsworld dot de --- Created attachment 33443 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33443action=edit aguixtest.cc file with helper functions, not related to the problem, but required to execute
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #9 from Ralf Hoffmann gcc at boomerangsworld dot de --- Created attachment 33444 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33444action=edit aguixtest.hh file with helper functions, not related to the problem, but required to execute
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #10 from Ralf Hoffmann gcc at boomerangsworld dot de --- Created attachment 33445 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33445action=edit build build script used to create executable test program
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #11 from Ralf Hoffmann gcc at boomerangsworld dot de --- I managed to create a standalone test program. Attachment aguix.cc contains the stripped down critical code segments. The two other files aguixtest.cc and aguixtest.hh are just to make a runnable binary. The attached script build can be used to create the binary. The expected output is: wait4mess2 called waittime2: 5 Worker: msg lock element lost! Worker: msg lock element lost! wait4mess2 called (this is what the binary does with gcc 4.8.1) while with gcc 4.9.1 it will loop forever: wait4mess2 called waittime2: 5 waittime2: 5 waittime2: 5 waittime2: 5 Compiled with -O1 instead of -O2 the example program crashes. Adding -fsanitize=undefined on the other hand will make it work again regardless of O1 or O2.
[Bug libstdc++/62259] atomic class doesn't enforce required alignment on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-03 CC||dje at gcc dot gnu.org, ||redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug c/62294] [4.9 Regression] Missing passing argument [...] from incompatible pointer type warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Sep 3 13:20:43 2014 New Revision: 214876 URL: https://gcc.gnu.org/viewcvs?rev=214876root=gccview=rev Log: PR c/62294 * gcc.dg/pr62294.c: New test. * gcc.dg/pr62294.h: New file. Added: trunk/gcc/testsuite/gcc.dg/pr62294.c trunk/gcc/testsuite/gcc.dg/pr62294.h Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/62294] [4.9 Regression] Missing passing argument [...] from incompatible pointer type warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294 --- Comment #6 from Emmanuel Thomé Emmanuel.Thome at inria dot fr --- Thanks. E.
[Bug other/63155] [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-03
Target Milestone|--- |4.9.2
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Clearly caused by the correctness fix for setjmp to wire abnormal edges.
For me it is out-of-ssa which uses too much memory while building
the conflict graph.
We have gigantic PHI nodes here:
_10263(ab) = PHI _109925(D)(ab)(2),, _10592(ab)(1489)
it's fast when optimizing.
At -O0 we have a _lot_ more anonymous SSA names.
-O1:
bb 4:
# _1(ab) = PHI _1902(3), _2(ab)(5)
_1905 = _setjmp (_1(ab));
if (_1905 == 0)
goto bb 6;
else
goto bb 8;
bb 5
# _2(ab) = PHI _1895(D), single gigantic PHI
-O0:
bb 4:
# _1(ab) = PHI _398164(3), _2(ab)(5)
# _632(ab) = PHI _397532(D)(ab)(3), _633(ab)(5)
# _1263(ab) = PHI _397533(D)(ab)(3), _1264(ab)(5)
# _1894(ab) = PHI _397534(D)(ab)(3), _1895(ab)(5)
# _2525(ab) = PHI _397535(D)(ab)(3), _2526(ab)(5)
...
# _396900(ab) = PHI _398160(D)(ab)(3), _396901(ab)(5)
_398165 = _setjmp (_1(ab));
if (_398165 == 0)
goto bb 6;
else
goto bb 8;
bb 5
# _2(ab) = PHI _397531(D)(ab)(2)...
# _396901(ab) = PHI _398160(D)(ab)(2), _3...
gazillion of gigantic PHIs. And very many PHIs in every block.
It's into-SSA that introduces the difference for the PHI nodes
but already GIMPLIFICATION that introduces very many more
temporaries which is the underlying issue (lookup_tmp_var
!optimize check).
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 214810)
+++ gcc/gimplify.c (working copy)
@@ -476,7 +476,7 @@ lookup_tmp_var (tree val, bool is_formal
block, which means it will go into memory, causing much extra
work in reload and final and poorer code generation, outweighing
the extra memory allocation here. */
- if (!optimize || !is_formal || TREE_SIDE_EFFECTS (val))
+ if (!is_formal || TREE_SIDE_EFFECTS (val))
ret = create_tmp_from_val (val);
else
{
fixes it (but it means that changing the testcase to use more distinct
user variables would produce the same issue even when optimizing).
[Bug tree-optimization/58526] Inlining looses restrict qualifier and leads to loop versioned vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58526 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- See also RFC patch at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00232.html
[Bug other/63155] [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I wonder why we need to explicitely represent abnormal PHIs in the dispatcher. All incoming edges are abnormal and all SSA names have to be coalesced anyway. Thus we could instead have bb 5: /* Not: # _2(ab) = PHI _17(D)(ab)(2), _1(ab)(6), _1(ab)(7), _3(ab)(11), _3(ab)(12), _4(ab)(15), _4(ab)(16), _5(ab)(20), _5(ab)(21), _5(ab)(22) */ ABNORMAL_DISPATCHER (0); _2(ab) = D.12345; or simply rewrite all must-coalesce vars out-of-SSA? (or not into SSA in the first place) The question is whether accesses to them should be loads/stores (I think so) and if that will cause other similar issues. We'd have to factor abnormal edges into a block to a separate forwarder of course, with a load of all abnormal vars. Anyway, not sure why the gimplify code is disabled for -O0 (or why we don't re-use formal temps more aggressively as they become anonymous SSA names later anyway).
[Bug tree-optimization/55334] [4.8/4.9/5 Regression] mgrid regression (ipa-cp disables vectorization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #41 from Richard Biener rguenth at gcc dot gnu.org --- New attempt: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00232.html
[Bug ipa/61986] ICE on valid code at -O3 on x86_64-linux-gnu indecide_about_value, at ipa-cp.c:3480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Wed Sep 3 14:16:54 2014 New Revision: 214877 URL: https://gcc.gnu.org/viewcvs?rev=214877root=gccview=rev Log: 2014-09-03 Martin Jambor mjam...@suse.cz PR ipa/61986 * ipa-cp.c (find_aggregate_values_for_callers_subset): Chain created replacements in ascending order of offsets. (known_aggs_to_agg_replacement_list): Likewise. gcc/testsuite/ * gcc.dg/ipa/pr61986.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr61986.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug other/63155] [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- So the issue is that the setjmp argument needs two temporaries: D.2832 = Unity.CurrentAbortFrame; D.2833 = Unity.AbortFrame[D.2832]; bb 18: D.2834 = _setjmp (D.2833); and the EH edge going into the _setjmp call has to merge those through the abnormal dispatcher. And that way it receives all of them. Hmm. Huh. Without the abnormal dispatcher they should just get default defs everywhere (but still many PHI nodes). Maybe that would be more light-weight.
[Bug ipa/62015] [4.8/4.9/5 Regression] ipa-cp-clone uses a clone that is too specialized for the call context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Wed Sep 3 14:26:38 2014 New Revision: 214878 URL: https://gcc.gnu.org/viewcvs?rev=214878root=gccview=rev Log: 2014-09-03 Martin Jambor mjam...@suse.cz PR ipa/62015 * ipa-cp.c (intersect_aggregates_with_edge): Handle impermissible pass-trough jump functions correctly. testsuite/ * g++.dg/ipa/pr62015.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr62015.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- ... but we ICE with the testcase adjusted too.
[Bug ipa/61986] ICE on valid code at -O3 on x86_64-linux-gnu indecide_about_value, at ipa-cp.c:3480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- I can reproduce the bug on the 4.9 branch too and the code is the same in 4.8 as well (although the bug does not manifest form me there), so please keep this bug opened until I commit the same fix to the two branches, which will happen right after my bootstrap and testing finishes.
[Bug libstdc++/62259] atomic class doesn't enforce required alignment on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to saugustine from comment #0)
My uneducated guess is that the template at atomic:189 should either use
_M_i in calls to __atomic_is_lock_free (instead of nullptr) or should add
alignment as necessary. Not sure how that is intended to be done. If I fix
atomic to pass the pointer, then gcc chooses to call out to an atomic
library function, which gcc doesn't provide.
GCC does provide it, in libatomic, so -latomic should work.
But I just tried your suggested change and saw no effect: I didn't need
libatomic and I still got a bus error.
I suppose what we want is the equivalent of this, but the _Atomic keyword isn't
valid in C++:
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -161,7 +161,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct atomic
{
private:
- _Tp _M_i;
+ alignas(alignof(_Atomic _Tp)) _Tp _M_i;
// TODO: static_assert(is_trivially_copyable_Tp::value, );
[Bug fortran/62270] -Wlogical-not-parentheses warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Sep 3 16:04:27 2014 New Revision: 214881 URL: https://gcc.gnu.org/viewcvs?rev=214881root=gccview=rev Log: PR fortran/62270 * interface.c (compare_parameter): Fix condition. * trans-expr.c (gfc_conv_procedure_call): Likewise. * gfortran.dg/pointer_intent_7.f90: Adjust dg-error. Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/interface.c branches/gcc-4_9-branch/gcc/fortran/trans-expr.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pointer_intent_7.f90
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
The code in cxx_eval_bit_field_ref needs some work, doesn't handle CONSTRUCTORs
inside CONSTRUCTORs. This is a reduced testcase:
struct BitsOrderCheck
{
struct Data
{
const unsigned char set:1;
constexpr Data() : set{1} {}
};
constexpr bool IsLsbBottom() const
{
return 1 == data_.set;
}
const Datadata_;
};
static_assert(BitsOrderCheck().IsLsbBottom(), blah);
[Bug libstdc++/62259] atomic class doesn't enforce required alignment on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259 Andrew Macleod amacleod at redhat dot com changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #4 from Andrew Macleod amacleod at redhat dot com --- Yeah... up until now, CRIS was the only port that this was an issue for. The original C11 work had an extension __attribute__(atomic) which would do the same thing the _Atomic keyword does for non C11 compilation, and the type in the libstdc++ atomic classes would be given this attribute. When jsm took over the C11 integration, this attribute code added extra testing and code paths that were beyond the scope of what he was doing with C11, so it was left behind. my original mothballing note was https://gcc.gnu.org/ml/gcc/2013-09/msg00240.html we could probably track down the parts he didn't integrate from the branch if someone wanted to work with them and get them up to snuff.
[Bug ipa/61986] ICE on valid code at -O3 on x86_64-linux-gnu indecide_about_value, at ipa-cp.c:3480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Wed Sep 3 16:13:03 2014 New Revision: 214882 URL: https://gcc.gnu.org/viewcvs?rev=214882root=gccview=rev Log: 2014-09-03 Martin Jambor mjam...@suse.cz PR ipa/61986 * ipa-cp.c (find_aggregate_values_for_callers_subset): Chain created replacements in ascending order of offsets. (known_aggs_to_agg_replacement_list): Likewise. gcc/testsuite/ * gcc.dg/ipa/pr61986.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/ipa/pr61986.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa-cp.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug ipa/62015] [4.8/4.9/5 Regression] ipa-cp-clone uses a clone that is too specialized for the call context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Wed Sep 3 16:16:28 2014 New Revision: 214883 URL: https://gcc.gnu.org/viewcvs?rev=214883root=gccview=rev Log: 2014-09-03 Martin Jambor mjam...@suse.cz PR ipa/62015 * ipa-cp.c (intersect_aggregates_with_edge): Handle impermissible pass-trough jump functions correctly. testsuite/ * g++.dg/ipa/pr62015.C: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr62015.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa-cp.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug ipa/61986] ICE on valid code at -O3 on x86_64-linux-gnu indecide_about_value, at ipa-cp.c:3480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Wed Sep 3 16:33:10 2014 New Revision: 214884 URL: https://gcc.gnu.org/viewcvs?rev=214884root=gccview=rev Log: 2014-09-03 Martin Jambor mjam...@suse.cz PR ipa/61986 * ipa-cp.c (find_aggregate_values_for_callers_subset): Chain created replacements in ascending order of offsets. (known_aggs_to_agg_replacement_list): Likewise. gcc/testsuite/ * gcc.dg/ipa/pr61986.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/ipa/pr61986.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/ipa-cp.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- With that reduced testcase, I've bisected it to r208831, before inlining pass there are no differences, and starting with r208831 the inliner changes 3 calls to __builtin_unreachable - __dynamic_cast, AWindow2::isParent and fwrite. Haven't yet looked why the inliner considers those unreachable, if there is some undefined behavior that makes those unreachable, or something else. Honza?
[Bug ipa/62015] [4.8/4.9/5 Regression] ipa-cp-clone uses a clone that is too specialized for the call context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Wed Sep 3 16:36:06 2014 New Revision: 214885 URL: https://gcc.gnu.org/viewcvs?rev=214885root=gccview=rev Log: 2014-09-03 Martin Jambor mjam...@suse.cz PR ipa/62015 * ipa-cp.c (intersect_aggregates_with_edge): Handle impermissible pass-trough jump functions correctly. testsuite/ * g++.dg/ipa/pr62015.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ipa/pr62015.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/ipa-cp.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug ipa/61986] ICE on valid code at -O3 on x86_64-linux-gnu indecide_about_value, at ipa-cp.c:3480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61986 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- Fixed.
[Bug ipa/62015] [4.8/4.9/5 Regression] ipa-cp-clone uses a clone that is too specialized for the call context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- Fixed.
[Bug rtl-optimization/63156] New: web can't handle AUTOINC correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156
Bug ID: 63156
Summary: web can't handle AUTOINC correctly
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Check out the latest trunk, apply the following patch to move web before IRA
Index: passes.def
===
--- passes.def(revision 214881)
+++ passes.def(working copy)
@@ -364,7 +364,6 @@
NEXT_PASS (pass_rtl_loop_done);
TERMINATE_PASS_LIST ()
POP_INSERT_PASSES ()
- NEXT_PASS (pass_web);
NEXT_PASS (pass_rtl_cprop);
NEXT_PASS (pass_cse2);
NEXT_PASS (pass_rtl_dse1);
@@ -385,6 +384,7 @@
NEXT_PASS (pass_sms);
NEXT_PASS (pass_live_range_shrinkage);
NEXT_PASS (pass_sched);
+ NEXT_PASS (pass_web);
NEXT_PASS (pass_ira);
NEXT_PASS (pass_reload);
NEXT_PASS (pass_postreload);
Build an arm gcc, run following test
make check-gcc RUNTESTFLAGS=--target_board=arm-sim/arch=armv5te/thumb
execute.exp=2422-1.c
You can see all tests pass. But if I enable the web pass,
make check-gcc RUNTESTFLAGS=--target_board=arm-sim/arch=armv5te/thumb/-fweb
execute.exp=2422-1.c
I got one run time failure. The problem is web renamed the operand of post_inc
in following insn, which should not occurred.
(insn 34 122 36 2 (set (reg:SI 137 [ D.4191 ])
(mem/c:SI (post_inc:SI (reg/f:SI 156)) [2 num+0 S4 A32]))
/usr/local/google/home/carrot/ssd/trunk3/gcc/testsuite/gcc.c-torture/execute/2422-1.c:17
740 {*thumb1_movsi_insn}
(expr_list:REG_INC (reg/f:SI 156)
(expr_list:REG_EQUAL (mem/c:SI (symbol_ref:SI (*.LANCHOR0) [flags
0x182]) [2 num+0 S4 A32])
(nil
[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-03 CC||rguenth at gcc dot gnu.org Component|rtl-optimization|tree-optimization Ever confirmed|0 |1 --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Eric Botcazou from comment #4) I guess the transformations should accept MEMs instead of just REGs but, no, I'm not particularly interested in quirks of CISC architectures, I have enough to do with those of RISC architectures. The problem is that with both function arguments in memory, combine simplifies sequence of bswaps with memory argument ( == movbe) in foo7 to: Failed to match this instruction: (set (reg:SI 84 [ D.2318 ]) (xor:SI (mem/c:SI (plus:SI (reg/f:SI 16 argp) (const_int 4 [0x4])) [2 b+0 S4 A32]) (mem/c:SI (reg/f:SI 16 argp) [2 a+0 S4 A32]))) This is invalid RTX, where both input arguments are in memory. The optimized tree dump for foo7 is: bb 2: _2 = __builtin_bswap32 (a_1(D)); _4 = __builtin_bswap32 (b_3(D)); _5 = _4 ^ _2; _6 = __builtin_bswap32 (_5); [tail call] return _6; It looks to me that the optimization has to be re-implemented as tree optimization (probably by extending fold_builtin_bswap in builtins.c). This generic optimization will also benefit targets without bswap RTX pattern, e.g. plain i386, as observed in Comment #2. I'm recategorizing the PR as a tree-optimization.
[Bug regression/63150] [4.9/5 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-03 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool segher at gcc dot gnu.org --- Confirmed. Happens with -m32 -mno-lra only. bswapdi2_32bit only allows Z for memory operands; reload decides to use a register.
[Bug rtl-optimization/63156] web can't handle AUTOINC correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-03 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug fortran/62270] -Wlogical-not-parentheses warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Sep 3 17:25:45 2014 New Revision: 214887 URL: https://gcc.gnu.org/viewcvs?rev=214887root=gccview=rev Log: PR fortran/62270 * interface.c (compare_parameter): Fix condition. * gfortran.dg/pointer_intent_7.f90: Adjust dg-error. Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/interface.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/pointer_intent_7.f90
[Bug rtl-optimization/63156] web can't handle AUTOINC correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |steven at gcc dot gnu.org
[Bug c++/63157] New: may_alias doesn't work as expected in template nested types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63157
Bug ID: 63157
Summary: may_alias doesn't work as expected in template nested
types
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haynberg at sig dot com
Basically, I want to build with strict aliasing enabled however I'd like a way
to *programmatically* prevent strict aliasing optimizations if needed. I
believe may_alias is the only way one can do this (please let me know if there
are others).
Here's an example where I know two different-typed pointers may alias. I
wanted a helper class that I could a reuse. Note: this is only for structs
which are POD (as you can't inherit from built-in types; I have another utility
for that).
In the example, may_alias works in the non-template case (case 2) and in the
template case if you use a reference (case 4); but not if you use a pointer
(case 3). Do you know why?
$ cat t.cpp
extern C void abort();
struct msg {
long seq_no;
};
struct msg_alias : msg {} __attribute__((may_alias));
template typename T
struct test_type {
struct type : T {} __attribute__((may_alias));
};
void check(short *a, msg *b)
{
*a = 5;
// case 1: will abort
// b-seq_no = 6;
// case 2: will not abort; may_alias prevented strict aliasing optimizations
// msg_alias *p = (msg_alias*) b;
// p-seq_no = 6;
// case 3: will abort (but should be the same as case 2)
test_typemsg::type *p = (test_typemsg::type*) b;
p-seq_no = 6;
// case 4: will not abort; may_alias prevented strict aliasing optimizations
// test_typemsg::type r = * (test_typemsg::type*) b;
// r.seq_no = 6;
if (*a == 5)
abort();
}
int main()
{
msg m[1];
check((short *) m, m);
}
$ g++ -O3 t.cpp a.out
Aborted
$ g++ -v
gcc version 4.9.0 (GCC)
$ uname -irs
Linux 3.0.38-0.5-default x86_64
[Bug fortran/63158] New: Possible wrong code with absend optional BT_CLASS - optional BT_DERIVED dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63158 Bug ID: 63158 Summary: Possible wrong code with absend optional BT_CLASS - optional BT_DERIVED dummy argument Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Follow up to PR 62270 comment 3. The following code adds conditionally a check whether a var == NULL check should be added. I fear that some extra check for BT_CLASS might be needed, e.g. when passing a BT_CLASS optional argument to a BT_DERIVED optional argument (same declared type). Namely, in the case the actual argument is NULL. trans-expr.c:gfc_conv_procedure_call 4445 if (fsym-attr.optional 4446e-expr_type == EXPR_VARIABLE 4447(!e-ref 4448 || (e-ref-type == REF_ARRAY 4449!e-ref-u.ar.type != AR_FULL))
[Bug fortran/62174] Component declarations overwrite types of Cray Pointee variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62174 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Sep 3 18:50:27 2014 New Revision: 214891 URL: https://gcc.gnu.org/viewcvs?rev=214891root=gccview=rev Log: 2014-09-03 Fritz Reese reese-fr...@zai.com PR fortran/62174 * decl.c (variable_decl): Don't overwrite typespecs of Cray * pointees when matching a component declaration. 2014-09-02 Fritz Reese reese-fr...@zai.com PR fortran/62174 * gfortran.dg/cray_pointers_11.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/cray_pointers_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/62174] Component declarations overwrite types of Cray Pointee variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62174 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED on the trunk (i.e. GCC 5). Thanks for the report, test case and patch!
[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087 Vitali vlovich at gmail dot com changed: What|Removed |Added CC||vlovich at gmail dot com --- Comment #11 from Vitali vlovich at gmail dot com --- I ran into this problem as I included lapacke.h indirectly, via including boost/exception/all.hpp picked up boost's iterator_facade.hpp. All of this is out of my control to resolve. lapacke correctly includes complex.h (since it is C code). iterator_facade correctly uses I as the name for a template argument (just as easily could have been used as a variable name). The combination results in code that doesn't work. I had to #undef I. I'm not sure if that's a GCC bug as opposed to something the standard needs to resolve.
[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087 --- Comment #12 from Vitali vlovich at gmail dot com --- Actually, http://en.cppreference.com/w/cpp/header seems to indicate that when compiling as C++, complex.h should be equal to including ccomplex in a global namespace. It seems like the inclusion of C99 complex.h is a GNU extension should only be done if GNU extensions are enabled.
[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087 --- Comment #13 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Vitali from comment #12) It seems like the inclusion of C99 complex.h is a GNU extension should only be done if GNU extensions are enabled. That would be a possibility, but do you think your lapack header will appreciate it if the complex.h it includes suddenly doesn't contain what it expects at all? It will break even worse. C++ code has 0 reason to include complex.h, only C code does, and thus it makes sense if it contains what C says. We do #undef complex but only because we are forced to do it. As for boost, reusing the name of a standard C macro is not the best idea for interoperability. If you report it to them, I hope they would be fine with replacing all 'I' with 'It'.
[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087 --- Comment #14 from Vitali vlovich at gmail dot com --- Actually, found a better workaround for lapacke. Adding #include ccomplex #define lapack_complex_float std::complexfloat #define lapack_complex_double std::complexdouble before I include lapacke.h causes lapacke.h to avoid including complex.h this is the officially supported mechanism for lapacke. It's strange that they don't just do that automatically.
[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087 --- Comment #15 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Vitali from comment #14) Actually, found a better workaround for lapacke. Good. #include ccomplex Please save one character and include complex instead.
[Bug regression/63150] [4.9/5 regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #2 from Pat Haugen pthaugen at gcc dot gnu.org --- Alan posted a patch here: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01487.html, but thread seems to have went stale.
[Bug c++/62306] [4.9/5 Regression?] Change in the comdat used for constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- So, yeah. When we were originally developing the ABI, we wanted to allow implementations to make all of the symbols entry points to the same function. But this didn't end up being reflected in the ABI document, which doesn't currently allow for sharing a COMDAT group at all: Implicitly-defined or inline user-defined constructors and destructors are emitted where referenced, each in its own COMDAT group identified by the constructor or destructor name. I started a discussion about this on the ABI list in 2009 but it didn't conclude. It sounds like most other compilers still put the destructors in different groups. clang avoids creating two identical clones by just omitting the complete-object clone (and putting the base clone in the vtable), which also seems nonconformant. Apparently HP puts all the constructors in a C3 group but uses separate groups for the destructors. So we're already incompatible with everyone else on this, though it's pretty harmless because the worst that can happen is a bit of extra bloat. So we don't need to consider compatibility with other vendors in this decision and can just do what's right for us. I think I'm sympathetic to Rafael's argument that we should stick with the 4.7 behavior since that's what most deployed GCCs currently do.
[Bug c++/62306] [4.9/5 Regression?] Change in the comdat used for constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Jason Merrill from comment #8) I think I'm sympathetic to Rafael's argument that we should stick with the 4.7 behavior since that's what most deployed GCCs currently do. 4.5+4.6+4.9 is more released compilers than 4.7/4.8 though, and 4.9 is already widely deployed too, IMHO it is worse to change this again mid-release.
[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #5 from Roland Schulz roland at rschulz dot eu --- This seems to me to be a duplicate of 49001.
[Bug target/61730] Cygwin AVX __m256i return value misaligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61730 Roland Schulz roland at rschulz dot eu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Roland Schulz roland at rschulz dot eu --- Duplicate *** This bug has been marked as a duplicate of bug 49001 ***
[Bug target/49001] GCC uses VMOVAPS/PD AVX instructions to access stack variables that are not 32-byte aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001 --- Comment #4 from Roland Schulz roland at rschulz dot eu --- *** Bug 61730 has been marked as a duplicate of this bug. ***
[Bug other/63159] New: Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63159 Bug ID: 63159 Summary: Demangler crash Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: cas43 at cs dot stanford.edu The demangler crashes when given this symbol: _ZN7PhysBAM11HETERO_DIFFmlINS_6VECTORIfLi3EEENS0_10MAT_HOLDERINS_16SYMMETRIC_MATRIXIfLi3EEENS0_7VEC_ENDENS0_7MAT_ENDENS0_7HESSIANIT_DTclsrNS0_9MAT_MAP_1INS0_3MULINS0_3ARGILi0EEENSE_ILi1ENS0_9VEC_MAP_1ISH_4TypecvT0__EcvNSB_6SCALARE_ESM_RKNSA_ISB_SL_EE See https://sourceware.org/bugzilla/show_bug.cgi?id=17043
[Bug rtl-optimization/63156] web can't handle AUTOINC correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org --- I am unable to reproduce this: Test Run By stevenb on Wed Sep 3 14:56:17 2014 Target is arm-unknown-eabi Host is powerpc64-unknown-linux-gnu === gcc tests === Schedule of variations: arm-sim/-march=armv5te/-mthumb/-fweb Running target arm-sim/-march=armv5te/-mthumb/-fweb Running /home/stevenb/devel/combined/gcc/testsuite/gcc.c-torture/execute/execute.exp ... PASS: gcc.c-torture/execute/2422-1.c -O0 (test for excess errors) PASS: gcc.c-torture/execute/2422-1.c -O0 execution test PASS: gcc.c-torture/execute/2422-1.c -O1 (test for excess errors) PASS: gcc.c-torture/execute/2422-1.c -O1 execution test PASS: gcc.c-torture/execute/2422-1.c -O2 (test for excess errors) PASS: gcc.c-torture/execute/2422-1.c -O2 execution test PASS: gcc.c-torture/execute/2422-1.c -O3 -fomit-frame-pointer (test for excess errors) PASS: gcc.c-torture/execute/2422-1.c -O3 -fomit-frame-pointer execution test PASS: gcc.c-torture/execute/2422-1.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) PASS: gcc.c-torture/execute/2422-1.c -O3 -fomit-frame-pointer -funroll-loops execution test PASS: gcc.c-torture/execute/2422-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) PASS: gcc.c-torture/execute/2422-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test PASS: gcc.c-torture/execute/2422-1.c -O3 -g (test for excess errors) PASS: gcc.c-torture/execute/2422-1.c -O3 -g execution test PASS: gcc.c-torture/execute/2422-1.c -Os (test for excess errors) PASS: gcc.c-torture/execute/2422-1.c -Os execution test === gcc Summary === # of expected passes16 /home/stevenb/devel/build-arm/gcc/xgcc version 5.0.0 20140903 (experimental) [trunk revision 214887] (GCC) What is your command line for configure?
[Bug rtl-optimization/63156] web can't handle AUTOINC correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156 --- Comment #3 from Carrot carrot at google dot com --- ../trunk3/configure '--build=x86_64-build_unknown-linux-gnu' '--host=x86_64-build_unknown-linux-gnu' '--target=arm-unknown-linux-gnueabi' '--prefix=/usr/local/google/home/carrot/x-tools/arm-unknown-linux-gnueabi' '--with-sysroot=/usr/local/google/home/carrot/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot' '--with-float=soft' '--with-pkgversion=crosstool-NG 1.19.0' '--disable-sjlj-exceptions' '--enable-__cxa_atexit' '--disable-libmudflap' '--disable-libgomp' '--disable-libssp' '--disable-libquadmath' '--disable-libquadmath-support' '--with-gmp=/usr/local/google/home/carrot/crosstool-ng/work1/.build/arm-unknown-linux-gnueabi/buildtools' '--with-mpfr=/usr/local/google/home/carrot/crosstool-ng/work1/.build/arm-unknown-linux-gnueabi/buildtools' '--with-mpc=/usr/local/google/home/carrot/crosstool-ng/work1/.build/arm-unknown-linux-gnueabi/buildtools' '--with-ppl=no' '--with-isl=no' '--with-cloog=no' '--with-libelf=no' '--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' '--enable-threads=posix' '--enable-target-optspace' '--disable-nls' '--disable-multilib' '--with-local-prefix=/usr/local/google/home/carrot/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot' '--enable-c99' '--enable-long-long' '--disable-libitm' 'build_alias=x86_64-build_unknown-linux-gnu' 'host_alias=x86_64-build_unknown-linux-gnu' 'target_alias=arm-unknown-linux-gnueabi' '--disable-libasan' '--disable-libsanitizer' '--enable-languages=c,c++,lto'
[Bug tree-optimization/63148] r187042 causes auto-vectorization failure for X86 for -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63148 Doug Gilmore doug.gilmore at imgtec dot com changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #2 from Doug Gilmore doug.gilmore at imgtec dot com --- I still see the test failure at -m32 using the TIP of gcc-4_8-branch and ToT. Richard: when you have the chance, could double check your test results?
