[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 --- Author: yroux Date: Wed Sep 3 07:23:01 2014 New Revision: 214847 URL: https://gcc.gnu.org/viewcvs?rev=214847&root=gcc&view=rev Log: gcc/ 2014-09-03 Yvan Roux Backport from trunk r214526. 2014-08-26 Joseph Myers 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 Backport from trunk r214526. 2014-08-26 Joseph Myers 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 --- Author: yroux Date: Wed Sep 3 07:23:01 2014 New Revision: 214847 URL: https://gcc.gnu.org/viewcvs?rev=214847&root=gcc&view=rev Log: gcc/ 2014-09-03 Yvan Roux Backport from trunk r214526. 2014-08-26 Joseph Myers 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 Backport from trunk r214526. 2014-08-26 Joseph Myers 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 --- 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 --- (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 --- 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 --- (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 ---
Author: krebbel
Date: Wed Sep 3 08:06:09 2014
New Revision: 214850
URL: https://gcc.gnu.org/viewcvs?rev=214850&root=gcc&view=rev
Log:
2014-09-03 Andreas Krebbel
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
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 changed: What|Removed |Added URL||https://gcc.gnu.org/ml/fort ||ran/2014-09/msg00016.html --- Comment #2 from Joost VandeVondele --- 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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Andreas Krebbel --- 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 changed: What|Removed |Added Known to fail|4.10.0 |5.0 --- Comment #12 from Martin Jambor --- 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 --- 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 --- 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 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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- 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 changed: What|Removed |Added CC||doug.gilmore at imgtec dot com --- Comment #15 from Richard Biener --- *** 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 --- 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 ---
(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 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 --- 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 changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- 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 --- (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 changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #8 from bin.cheng --- 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 --- 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 --- > (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 --- 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 --- 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 --- Author: mpolacek Date: Wed Sep 3 11:16:29 2014 New Revision: 214871 URL: https://gcc.gnu.org/viewcvs?rev=214871&root=gcc&view=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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- 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 changed: What|Removed |Added Target Milestone|--- |5.0 --- Comment #8 from Jonathan Wakely --- 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 --- 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=33441&action=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 --- 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 changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment #1 from Ulrich Weigand ---
Indeed, when running a simple test program:
#include
#include
struct twoints {
int a;
int b;
};
int main(void) {
printf("%d\n", __alignof__ (twoints));
printf("%d\n", __alignof__ (std::atomic));
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
#include
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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski --- (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 changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #69 from Andrew Pinski --- *** 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 --- Author: mpolacek Date: Wed Sep 3 12:54:06 2014 New Revision: 214874 URL: https://gcc.gnu.org/viewcvs?rev=214874&root=gcc&view=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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- 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 --- Created attachment 33442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33442&action=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 --- Created attachment 33443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33443&action=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 --- Created attachment 33444 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33444&action=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 --- Created attachment 33445 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33445&action=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 --- 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 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 --- 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 --- Author: mpolacek Date: Wed Sep 3 13:20:43 2014 New Revision: 214876 URL: https://gcc.gnu.org/viewcvs?rev=214876&root=gcc&view=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é --- Thanks. E.
[Bug other/63155] [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
Richard Biener 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 ---
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:
:
# _1(ab) = PHI <_1902(3), _2(ab)(5)>
_1905 = _setjmp (_1(ab));
if (_1905 == 0)
goto ;
else
goto ;
# _2(ab) = PHI <_1895(D), single gigantic PHI
-O0:
:
# _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 ;
else
goto ;
# _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 --- 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 --- 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 : /* 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 --- 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 --- Author: jamborm Date: Wed Sep 3 14:16:54 2014 New Revision: 214877 URL: https://gcc.gnu.org/viewcvs?rev=214877&root=gcc&view=rev Log: 2014-09-03 Martin Jambor 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 --- So the issue is that the setjmp argument needs two temporaries: D.2832 = Unity.CurrentAbortFrame; D.2833 = &Unity.AbortFrame[D.2832]; : 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 --- Author: jamborm Date: Wed Sep 3 14:26:38 2014 New Revision: 214878 URL: https://gcc.gnu.org/viewcvs?rev=214878&root=gcc&view=rev Log: 2014-09-03 Martin Jambor 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 changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #3 from Paolo Carlini --- ... 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 --- 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 ---
(In reply to saugustine from comment #0)
> My uneducated guess is that the template at :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
> 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 --- Author: mpolacek Date: Wed Sep 3 16:04:27 2014 New Revision: 214881 URL: https://gcc.gnu.org/viewcvs?rev=214881&root=gcc&view=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 ---
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 changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #4 from Andrew Macleod --- 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 --- Author: jamborm Date: Wed Sep 3 16:13:03 2014 New Revision: 214882 URL: https://gcc.gnu.org/viewcvs?rev=214882&root=gcc&view=rev Log: 2014-09-03 Martin Jambor 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 --- Author: jamborm Date: Wed Sep 3 16:16:28 2014 New Revision: 214883 URL: https://gcc.gnu.org/viewcvs?rev=214883&root=gcc&view=rev Log: 2014-09-03 Martin Jambor 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 --- Author: jamborm Date: Wed Sep 3 16:33:10 2014 New Revision: 214884 URL: https://gcc.gnu.org/viewcvs?rev=214884&root=gcc&view=rev Log: 2014-09-03 Martin Jambor 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 changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- 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 --- Author: jamborm Date: Wed Sep 3 16:36:06 2014 New Revision: 214885 URL: https://gcc.gnu.org/viewcvs?rev=214885&root=gcc&view=rev Log: 2014-09-03 Martin Jambor 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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Jambor --- 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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Jambor --- 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 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 --- (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: : _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 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 --- 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 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 --- Confirmed.
[Bug fortran/62270] -Wlogical-not-parentheses warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Wed Sep 3 17:25:45 2014 New Revision: 214887 URL: https://gcc.gnu.org/viewcvs?rev=214887&root=gcc&view=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 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
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_type::type *p = (test_type::type*) b;
p->seq_no = 6;
// case 4: will not abort; may_alias prevented strict aliasing optimizations
// test_type::type &r = * (test_type::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 4446 && e->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 --- Author: burnus Date: Wed Sep 3 18:50:27 2014 New Revision: 214891 URL: https://gcc.gnu.org/viewcvs?rev=214891&root=gcc&view=rev Log: 2014-09-03 Fritz Reese PR fortran/62174 * decl.c (variable_decl): Don't overwrite typespecs of Cray * pointees when matching a component declaration. 2014-09-02 Fritz Reese 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 changed: What|Removed |Added Keywords||rejects-valid Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Tobias Burnus --- 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 changed: What|Removed |Added CC||vlovich at gmail dot com --- Comment #11 from Vitali --- 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 --- 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 --- (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 --- Actually, found a better workaround for lapacke. Adding #include #define lapack_complex_float std::complex #define lapack_complex_double std::complex before I include 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 --- (In reply to Vitali from comment #14) > Actually, found a better workaround for lapacke. Good. > #include Please save one character and include 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 changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #2 from Pat Haugen --- 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 --- 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 --- (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 --- 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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Roland Schulz --- 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 --- *** 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 changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Steven Bosscher --- 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 --- ../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 changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #2 from Doug Gilmore --- 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?
[Bug rtl-optimization/63156] web can't handle AUTOINC correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156
--- Comment #4 from Carrot ---
In function df_uses_record, we have:
...
case PRE_DEC:
case POST_DEC:
case PRE_INC:
case POST_INC:
case PRE_MODIFY:
case POST_MODIFY:
gcc_assert (!DEBUG_INSN_P (insn_info->insn));
/* Catch the def of the register being modified. */
df_ref_record (DF_REF_REGULAR, collection_rec, XEXP (x, 0), &XEXP (x, 0),
bb, insn_info,
DF_REF_REG_DEF,
flags | DF_REF_READ_WRITE | DF_REF_PRE_POST_MODIFY);
/* ... Fall through to handle uses ... */
default:
break;
}
/* Recursively scan the operands of this expression. */
{
const char *fmt = GET_RTX_FORMAT (code);
int i;
for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--)
{
if (fmt[i] == 'e')
{
/* Tail recursive case: save a function call level. */
if (i == 0)
{
loc = &XEXP (x, 0);
goto retry;
}
df_uses_record (collection_rec, &XEXP (x, i), ref_type,
bb, insn_info, flags);
}
...
For a AUTOINC rtl expression, we create two refs, one def and one use, but only
the def gets the flag DF_REF_READ_WRITE, the use doesn't have this flag.
While in web_main, it checks only use refs, but the use ref doesn't have the
flag DF_REF_READ_WRITE, so it can't actually catch the AUTOINC cases, and does
wrong renaming.
[Bug tree-optimization/61943] tree-ssa-loop-ivopts.c:4148 signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61943 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #1 from amker at gcc dot gnu.org --- Could you please provide detailed command line for both compilation and gcc configuration? I can't reproduce it on trunk/gcc-4_9-branch.
[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 #16 from Vitali --- Yup - I caught that on a self code-review.
[Bug tree-optimization/61943] tree-ssa-loop-ivopts.c:4148 signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61943 --- Comment #2 from Vittorio Zecca --- gcc was compiled with -fsanitize=undefined option. Call it gcc-sanitized. Then I did gcc-sanitized -S gccerr13.c -O where gccerr13.c is the sample C code I sent bugzilla The option -O is necessary to reproduce the bug. Error message from the sanitizer ../../gcc-4.9.1/gcc/tree-ssa-loop-ivopts.c:4148:24: runtime error: signed integer overflow: 4 * 4611686018427387903 cannot be represented in type 'long int'
