[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758 --- Comment #3 from Alexey Merzlyakov alexey.merzlyakov at samsung dot com --- Thank you very much! Reg. test - no changes. http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00195.html
[Bug target/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #22 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Mon Apr 7 06:40:18 2014 New Revision: 209175 URL: http://gcc.gnu.org/viewcvs?rev=209175root=gccview=rev Log: 2014-04-03 Dominique d'Humieres domi...@lps.ens.fr Backport from mainline 2013-09-14 Iain Sandoe ia...@gcc.gnu.org gcc: PR target/48094 * config/darwin.c (darwin_objc2_section): Note if ObjC Metadata is seen. (darwin_objc1_section): Likewise. (darwin_file_end): Emit Image Info section when required. gcc/c-family: PR target/48094 * c.opt (fgnu-runtime, fnext-runtime, fobjc-abi-version, fobjc-gc, freplace-objc-classes): Accept for LTO. gcc/objc: PR target/48094 * objc-next-runtime-abi-01.c (generate_objc_image_info): Remove. (objc_generate_v1_next_metadata): Remove generation of ImageInfo. * objc-next-runtime-abi-02.c (generate_v2_objc_image_info): Remove. (objc_generate_v2_next_metadata): Remove generation of ImageInfo. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/c-family/ChangeLog branches/gcc-4_8-branch/gcc/c-family/c.opt branches/gcc-4_8-branch/gcc/config/darwin.c branches/gcc-4_8-branch/gcc/objc/ChangeLog branches/gcc-4_8-branch/gcc/objc/objc-next-runtime-abi-01.c branches/gcc-4_8-branch/gcc/objc/objc-next-runtime-abi-02.c
[Bug target/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #23 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Mon Apr 7 08:00:55 2014 New Revision: 209176 URL: http://gcc.gnu.org/viewcvs?rev=209176root=gccview=rev Log: 2014-04-07 Dominique d'Humieres domi...@lps.ens.fr Backport from mainline 2013-09-14 Iain Sandoe ia...@gcc.gnu.org gcc: PR target/48094 * config/darwin.c (darwin_objc2_section): Note if ObjC Metadata is seen. (darwin_objc1_section): Likewise. (darwin_file_end): Emit Image Info section when required. gcc/c-family: PR target/48094 * c.opt (fgnu-runtime, fnext-runtime, fobjc-abi-version, fobjc-gc, freplace-objc-classes): Accept for LTO. gcc/objc: PR target/48094 * objc-next-runtime-abi-01.c (generate_objc_image_info): Remove. (objc_generate_v1_next_metadata): Remove generation of ImageInfo. * objc-next-runtime-abi-02.c (generate_v2_objc_image_info): Remove. (objc_generate_v2_next_metadata): Remove generation of ImageInfo. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/c-family/ChangeLog branches/gcc-4_7-branch/gcc/c-family/c.opt branches/gcc-4_7-branch/gcc/config/darwin.c branches/gcc-4_7-branch/gcc/objc/ChangeLog branches/gcc-4_7-branch/gcc/objc/objc-next-runtime-abi-01.c branches/gcc-4_7-branch/gcc/objc/objc-next-runtime-abi-02.c
[Bug c++/60750] [4.8/4.9 Regression] double free after std::move on string inside throw when compiled with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60750 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Apr 7 08:38:23 2014 New Revision: 209179 URL: http://gcc.gnu.org/viewcvs?rev=209179root=gccview=rev Log: 2014-04-07 Richard Biener rguent...@suse.de PR middle-end/60750 * tree-ssa-operands.c (maybe_add_call_vops): Also add VDEFs for noreturn calls. * tree-cfgcleanup.c (fixup_noreturn_call): Do not remove VDEFs. * g++.dg/torture/pr60750.C: New testcase. * gcc.dg/tree-ssa/20040517-1.c: Adjust. Added: trunk/gcc/testsuite/g++.dg/torture/pr60750.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/20040517-1.c trunk/gcc/tree-cfgcleanup.c trunk/gcc/tree-ssa-operands.c
[Bug c++/60750] [4.8 Regression] double free after std::move on string inside throw when compiled with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60750 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.8/4.9 Regression] double |[4.8 Regression] double |free after std::move on |free after std::move on |string inside throw when|string inside throw when |compiled with optimization |compiled with optimization Known to fail|4.9.0 | --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug lto/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Václav Zeman from comment #7) Created attachment 32422 [details] preprocessed source Works for me with GCC 4.9 on x86-64-gnu-linux with both -fuse-linker-plugin and -fno-use-linker-plugin and g++ -O3 -std=c++11 -w -r -nostdlib -flto. I haven't tried 4.8, though. [I had to replace std::size_t by unsigned long for the new operator in order to make it compile.]
[Bug ipa/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 --- Comment #14 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Mon Apr 7 09:36:10 2014 New Revision: 209180 URL: http://gcc.gnu.org/viewcvs?rev=209180root=gccview=rev Log: 2014-04-07 Martin Jambor mjam...@suse.cz PR ipa/60640 * ipa-cp.c (propagate_constants_accross_call): Do not propagate accross thunks. testsuite/ * g++.dg/ipa/pr60640-1.C: New test. * g++.dg/ipa/pr60640-2.C: Likewise. * g++.dg/ipa/pr60640-3.C: Likewise. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ipa/pr60640-1.C branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ipa/pr60640-2.C branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ipa/pr60640-3.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/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 --- Comment #15 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Mon Apr 7 09:54:55 2014 New Revision: 209181 URL: http://gcc.gnu.org/viewcvs?rev=209181root=gccview=rev Log: 2014-04-07 Martin Jambor mjam...@suse.cz PR ipa/60640 * ipa-cp.c (propagate_constants_accross_call): Do not propagate accross thunks. testsuite/ * g++.dg/ipa/pr60640-1.C: New test. * g++.dg/ipa/pr60640-2.C: Likewise. * g++.dg/ipa/pr60640-3.C: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/ipa/pr60640-1.C branches/gcc-4_7-branch/gcc/testsuite/g++.dg/ipa/pr60640-2.C branches/gcc-4_7-branch/gcc/testsuite/g++.dg/ipa/pr60640-3.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/ipa-cp.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug ipa/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Martin Jambor jamborm at gcc dot gnu.org --- Fixed everywhere.
[Bug target/60773] FAIL: gcc.dg/vect/pr60656.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorized 1 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60773 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||congh at gcc dot gnu.org --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You miss calling check_vect() from main and checking for vectorizing long support (and widening).
[Bug target/60773] [4.9 Regression] FAIL: gcc.dg/vect/pr60656.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorized 1 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60773 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target|powerpc64-*-* |powerpc64-*-*, i?86-*-* Priority|P3 |P1 Summary|FAIL: gcc.dg/vect/pr60656.c |[4.9 Regression] FAIL: |-flto -ffat-lto-objects |gcc.dg/vect/pr60656.c -flto |scan-tree-dump-times vect |-ffat-lto-objects |vectorized 1 loops 1 |scan-tree-dump-times vect ||vectorized 1 loops 1
[Bug tree-optimization/60770] disappearing clobbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Yeah, you simply need to catch this earlier ...
[Bug ipa/60727] ICE in ipcp_verify_propagated_values, at ipa-cp.c:892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60727 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- The patch causing this did not get committed, the bug it was intended to fix was fixed a by a different patch, which also adds asserts to guard against this problem: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00179.html
[Bug rtl-optimization/60769] [4.8 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60769 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Known to work||4.7.3, 4.9.0 Keywords||ra Last reconfirmed||2014-04-07 CC||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |4.8.3 Known to fail||4.8.0, 4.8.2 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug c++/60768] Excessive C++ compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60768 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Yeah, checking enabled RTL unswitching is expensive. But we really don't care as production compilers are not built that way.
[Bug tree-optimization/60766] [4.7/4.8/4.9 Regression] Wrong optimization with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-07 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-07 Target Milestone|--- |4.9.0 Summary|Names of all function |[4.9 Regression] Names of |clones in g++ are |all function clones in g++ |built-in, in both |are built-in, in both |warnings and dumps |warnings and dumps Ever confirmed|0 |1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. IMHO the C++ FE should be less strict here...
[Bug c++/60775] New: Instantiates unused class template member function and therefor reports error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60775
Bug ID: 60775
Summary: Instantiates unused class template member function and
therefor reports error
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gunther.laure at gmail dot com
g++ 4.8.2 reports following error when compiling the example code:
abstract_class.cpp:11:13: error: cannot allocate an object of abstract type
‘IfSomethingIterator’
Derived operator--(int)
^
abstract_class.cpp:17:7: note: because the following virtual functions are
pure within ‘IfSomethingIterator’:
class IfSomethingIterator : public iterator_facadeIfSomethingIterator
^
abstract_class.cpp:24:18: note: virtual void
IfSomethingIterator::DoIncrement()
virtual void DoIncrement() = 0;
The code successfully compiles with:
g++4.6.3
g++4.7.3
clang++ 3.3
/// example start
template class Derived
class iterator_facade
{
public:
Derived operator++()
{
}
Derived operator--(int)
{
}
};
class IfSomethingIterator : public iterator_facadeIfSomethingIterator
{
public:
virtual ~IfSomethingIterator()
{}
protected:
virtual void DoIncrement() = 0;
};
/// example end
[Bug tree-optimization/60766] [4.7/4.8/4.9 Regression] Wrong optimization with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 32556
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32556action=edit
patch
The issue is that tree-ssa-loop-ivopts.c:cand_value_at converts niter
((unsigned int) n_3 * 2863311531 + 4294967294) to 'int' via
static void
cand_value_at (struct loop *loop, struct iv_cand *cand, gimple at, tree niter,
aff_tree *val)
{
aff_tree step, delta, nit;
struct iv *iv = cand-iv;
tree type = TREE_TYPE (iv-base);
tree steptype = type;
if (POINTER_TYPE_P (type))
steptype = sizetype;
tree_to_aff_combination (iv-step, steptype, step);
tree_to_aff_combination (niter, TREE_TYPE (niter), nit);
aff_combination_convert (nit, steptype);
^^^
which just does
comb-type = type;
if (comb-rest !POINTER_TYPE_P (type))
comb-rest = fold_convert (type, comb-rest);
thus re-interprets everything as signed. The whole aff_combination_convert
function looks suspicious ... but at this stage the easiest thing to do is
to avoid this 2nd call to this function (the other always converts to an
unsigned type).
Unfortunately doing that:
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 209181)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -4238,8 +4238,7 @@ cand_value_at (struct loop *loop, struct
steptype = sizetype;
tree_to_aff_combination (iv-step, steptype, step);
- tree_to_aff_combination (niter, TREE_TYPE (niter), nit);
- aff_combination_convert (nit, steptype);
+ tree_to_aff_combination (fold_convert (steptype, niter), steptype, nit);
aff_combination_mult (nit, step, delta);
if (stmt_after_increment (loop, cand, at))
aff_combination_add (delta, step);
reveals the other suspicious
void
tree_to_aff_combination (tree expr, tree type, aff_tree *comb)
{
aff_tree tmp;
enum tree_code code;
tree cst, core, toffset;
HOST_WIDE_INT bitpos, bitsize;
enum machine_mode mode;
int unsignedp, volatilep;
STRIP_NOPS (expr);
which just re-introduces the exact same affine combination.
This is kind-of a mess. Either the internal affine workings is
modulo two arithmetic and thus it doesn't need to care - but then
it needs to use unsigned arithmetic only at affine-to-tree time.
Or it depends on the sign of the affine combination but then it
has to be more careful.
IIRC it is the first, thus affine-to-tree is wrong in returning
signed arithmetic and keeping a type for the affine combination
doesn't make much sense (similar issue for pointer arithmetic btw,
where we choose a random base).
But it's all kind of a mess.
Working, somewhat localized patch attached.
[Bug tree-optimization/60770] disappearing clobbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- Catching it earlier may be hard, even for these trivial examples we only have from einline (18) to esra (24) or from eh (10) to ccp1 (21) and in more complicated examples I fear the interval will be empty, but we can try... CCP looks like the most natural choice in the interval 18-21. Manuel, for the CCP thing, it looks a bit different from PR 18501. There, you had something that was either 42 or undefined, so we picked 42. Here, we have something that must be undefined, and we are still picking whatever value it might have had before becoming undefined (but the write of that old value may have already been removed because it sees the value becomes undefined later...). Not that it is necessarily easier to do anything about it.
[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Mon Apr 7 13:17:11 2014 New Revision: 209185 URL: http://gcc.gnu.org/viewcvs?rev=209185root=gccview=rev Log: Fix testcase for PR target/60657 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/pr60657.c
[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 --- Comment #6 from Sebastian Huber sebastian.hu...@embedded-brains.de --- GCC 4.9.0 20140407 with the proposed patch fixes the problem for me.
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Apr 7 13:27:45 2014 New Revision: 209187 URL: http://gcc.gnu.org/viewcvs?rev=209187root=gccview=rev Log: PR c++/60731 * lib/gcc-dg.exp (dg-build-dso): New. (gcc-dg-test-1): Handle dg-do-what dso. * lib/target-supports.exp (add_options_for_dlopen): New. (check_effective_target_dlopen): Use it. * g++.dg/dso/dlclose1.C: New. * g++.dg/dso/dlclose1-dso.cc: New. Added: trunk/gcc/testsuite/g++.dg/dso/ trunk/gcc/testsuite/g++.dg/dso/dlclose1-dso.cc trunk/gcc/testsuite/g++.dg/dso/dlclose1.C Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/gcc-dg.exp trunk/gcc/testsuite/lib/target-supports.exp
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Apr 7 13:27:39 2014 New Revision: 209186 URL: http://gcc.gnu.org/viewcvs?rev=209186root=gccview=rev Log: PR c++/60731 * common.opt (-fno-gnu-unique): Add. * config/elfos.h (USE_GNU_UNIQUE_OBJECT): Check it. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/config/elfos.h trunk/gcc/doc/invoke.texi
[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- AFAIK the code cares for reasonably fast execution, even when optimizing for size. This is because the code is for interrupt service routine (ISR) prologue. RCALL is quite slow.
[Bug target/60410] [4.7/4.8/4.9 Regression] -fshort-double ICEs x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #6 from Rainer Orth ro at gcc dot gnu.org --- I'm seeing the same ICE on i386-pc-solaris2.1[01] as of r209079. I suppose the test needs to be skipped on that combination, too. Rainer
[Bug c/60759] -Wlogical-op should perhaps warn about two-way implicit conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60759
--- Comment #3 from Giuliano Procida giuliano.procida at googlemail dot com
---
I believe the clang warning is:
foo.c:1:18: warning: use of logical '||' with constant operand
[-Wconstant-logical-operand]
static int x = 2 || 3;
^ ~
foo.c:1:18: note: use '|' for a bitwise operation
static int x = 2 || 3;
^~
|
1 warning generated.
However, changing the code to:
int two() { return 2; }
int three() { return 3; }
int main() {
int x = two() || three();
return x;
}
results in no warnings from either compiler (in either language).
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #5 from David Edelsohn dje at gcc dot gnu.org --- I can see why the proposed patch will work, but it seems a little heavy-handed. This case isn't something that simplify_gen_subreg() should handle?
[Bug tree-optimization/60766] [4.7/4.8/4.9 Regression] Wrong optimization with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Apr 7 14:03:55 2014 New Revision: 209190 URL: http://gcc.gnu.org/viewcvs?rev=209190root=gccview=rev Log: 2014-04-07 Richard Biener rguent...@suse.de PR tree-optimization/60766 * tree-ssa-loop-ivopts.c (cand_value_at): Compute in an unsigned type. (may_eliminate_iv): Convert cand_value_at result to desired type. * gcc.dg/torture/pr60766.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr60766.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug tree-optimization/60766] [4.7/4.8 Regression] Wrong optimization with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] Wrong |Wrong optimization with -O2 |optimization with -O2 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug rtl-optimization/60776] New: [4.9 Regression] FAIL gcc.dg/builtin-bswap-6.c and gcc.dg/builtin-bswap-7.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60776 Bug ID: 60776 Summary: [4.9 Regression] FAIL gcc.dg/builtin-bswap-6.c and gcc.dg/builtin-bswap-7.c Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org See http://gcc.gnu.org/ml/gcc-regression/2014-04/msg00023.html, appears between rev. 209138 vs revision 209072
[Bug rtl-optimization/60776] [4.9 Regression] FAIL gcc.dg/builtin-bswap-6.c and gcc.dg/builtin-bswap-7.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60776 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Priority|P3 |P1 Target Milestone|--- |4.9.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The bswaps are no longer combined.
[Bug rtl-optimization/60776] [4.9 Regression] FAIL gcc.dg/builtin-bswap-6.c and gcc.dg/builtin-bswap-7.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60776
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Andreas, that's very likely caused by your change to the testcase. For some
reason I see two adjacent
(insn 11 10 28 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 84 [ D.1826 ])
(reg:SI 85 [ D.1826 ])))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/builtin-bswap-6.c:37 7
{*cmpsi_1}
(expr_list:REG_UNUSED (reg:CCZ 17 flags)
(nil)))
(insn 28 11 29 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 84 [ D.1826 ])
(reg:SI 85 [ D.1826 ])))
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/builtin-bswap-6.c:39 7
{*cmpsi_1}
(expr_list:REG_DEAD (reg:SI 85 [ D.1826 ])
(expr_list:REG_DEAD (reg:SI 84 [ D.1826 ])
(nil
and thus the bswaps are no longer single-use. Eventually we relied on
if-conversion doing some magic here which the testcase change disabled?
[Bug fortran/60777] New: Fortran 2003: RECURSIVE function rejected in specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60777
Bug ID: 60777
Summary: Fortran 2003: RECURSIVE function rejected in
specification expression
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
John Harper reports on comp.lang.fortran:
! A recursive function in a specification expression
module recur
implicit none
contains
pure recursive function f(n) result(answer)
integer,intent(in) :: n
integer:: answer
if (n2) then
answer = 1
else
answer = f(n-1)*n
end if
end function f ! factorial of max(n,0)
pure function usef(n)
integer,intent(in):: n
character(f(n)) :: usef
usef = repeat('*',f(n))
end function usef
end module recur
program testspecexpr
use recur
implicit none
integer :: n
do n = 1,3
print *,usef(n)
end do
end program testspecexpr
Which gives gfortran-4.9 resspec.f90
resspec.f90:18.16:
character(f(n)) :: usef
1
Error: Specification function 'f' at (1) cannot be RECURSIVE
but Fortran 2003 and 2008 just require:
7.1.11.6 (F2008): Evaluation of a specification expression shall not directly
or indirectly cause a procedure defined by the subprogram in which it appears
to be invoked.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- (In reply to David Edelsohn from comment #5) I can see why the proposed patch will work, but it seems a little heavy-handed. This case isn't something that simplify_gen_subreg() should handle? Normally it does, but in this case the backend uses CANNOT_CHANGE_MODE_CLASS to stop it: if (from_size 8 || to_size 8) return true; But AIUI the mode change is OK in this split. We start out with a 64-bit value in which the upper 32 bits are significant, then convert it to SFmode. Maybe it'd be more obvious if the input to vsx_xscvspdpn_directmove had the DImode version of the register too, to emphasise that no mode change happens outside the patterns.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Attachment #32553|0 |1 is obsolete|| --- Comment #7 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Created attachment 32557 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32557action=edit Updated patch that also uses op0_di for the conversion Should be equivalent to the previous patch, but more correct modewise.
[Bug fortran/60777] Fortran 2003: RECURSIVE function rejected in specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60777
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: expr.c
===
--- expr.c (revision 208947)
+++ expr.c (working copy)
@@ -2733,12 +2733,10 @@ external_spec_function (gfc_expr *e)
return false;
}
- if (f-attr.recursive)
-{
- gfc_error (Specification function '%s' at %L cannot be RECURSIVE,
-f-name, e-where);
+ if (f-attr.recursive
+ !gfc_notify_std (GFC_STD_F2003, Specification function '%s'
+ at %L cannot be RECURSIVE, f-name, e-where));
return false;
-}
return restricted_args (e-value.function.actual);
}
[Bug target/60609] [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609 --- Comment #6 from yroux at gcc dot gnu.org --- Author: yroux Date: Mon Apr 7 15:07:33 2014 New Revision: 209191 URL: http://gcc.gnu.org/viewcvs?rev=209191root=gccview=rev Log: 2014-04-07 Charles Baylis charles.bay...@linaro.org PR target/60609 * config/arm/arm.h (ASM_OUTPUT_CASE_END): Remove. (LABEL_ALIGN_AFTER_BARRIER): Align barriers which occur after ADDR_DIFF_VEC. 2014-04-07 Charles Baylis charles.bay...@linaro.org PR target/60609 * g++.dg/torture/pr60609.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr60609.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.h trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937 --- Comment #17 from Yury Gribov y.gribov at samsung dot com --- This should be fully resolved once https://github.com/llvm-mirror/compiler-rt/commit/d6535ea4c4d49078a93735b315b8518fb692a592 is merged into gcc trunk. BTW it no longer reproduces on trunk because newer versions of libstdc++ silently call __asan_init from __cxa_atexit in some constructor: #1 0x76f45a09 in __asan::InitializeAsanInterceptors() () at /home/ygribov/src/gcc-master/libsanitizer/asan/asan_interceptors.cc:710 #2 0x76f5b71f in __asan_init_v3 () from /home/ygribov/install/gcc-master/lib64/libasan.so #3 0x76f24462 in __interceptor___cxa_atexit () at /home/ygribov/src/gcc-master/libsanitizer/asan/asan_interceptors.cc:671 #4 0x762bfa32 in std::future_category() () at /home/ygribov/src/gcc-master/libstdc++-v3/src/c++11/future.cc:63 #5 0x76265c79 in _GLOBAL__sub_I_compatibility_thread_c__0x.cc () at /home/ygribov/src/gcc-master/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:49 #6 0x77de9306 in call_init (l=optimized out, argc=1, argv=0x7fffdeb8, env=0x7fffdec8) at dl-init.c:85 #7 0x77de93df in call_init (env=optimized out, argv=optimized out, argc=optimized out, l=optimized out) at dl-init.c:52 #8 _dl_init (main_map=0x77ffe2c8, argc=1, argv=0x7fffdeb8, env=0x7fffdec8) at dl-init.c:134 #9 0x77ddb6ea in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
[Bug target/60778] New: shift not folded into shift on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60778
Bug ID: 60778
Summary: shift not folded into shift on x86-64
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sunfish at mozilla dot com
On this C code:
double mem[4096];
double foo(long x) {
return mem[x3];
}
GCC emits this x86-64 code:
sarq$3, %rdi
movsd mem(,%rdi,8), %xmm0
The following x86-64 code would be preferrable:
andq$-8, %rdi
movsd mem(%rdi), %xmm0
since it has smaller code size, and avoids using a scaled index which costs an
extra micro-op on some microarchitectures.
The same situation arrises on 32-bit x86 also.
This was observed on all GCC versions currently on the GCC Explorer website
[0], with the latest at this time being 4.9.0 20130909.
[0] http://gcc.godbolt.org/
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|amacleod at redhat dot com |jason at gcc dot gnu.org
[Bug c++/60779] New: -fcx-fortran-rules ignored when using -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60779
Bug ID: 60779
Summary: -fcx-fortran-rules ignored when using -flto
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dturnbull at gmail dot com
Using the following test code on g++-4.9 (GCC) 4.9.0 20140330
if (isnan((complexfloat(1,0) / complexfloat(0,0)).real())) {
cout Fortran rules: \n;
} else {
cout ISO rules: \n;
}
The -fcx-fortran-rules option behaves as expected. The test code indicates
Fortran rules are being used and performance indicates the NaN checking is
indeed disabled.
When enabling both -fcx-fortran-rules and -flto the test code indicates ISO
rules are being used and performance is identical to compiling without
-fcx-fortran-rules.
This happens in both the C and C++ compilers.
[Bug c++/60779] -fcx-fortran-rules ignored when using -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60779 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Can you provide the extra command line you used?
[Bug c++/60779] -fcx-fortran-rules ignored when using -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60779 David Turnbull dturnbull at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from David Turnbull dturnbull at gmail dot com --- Sorry. My bad. Closing. Makefile bug :(
[Bug fortran/60780] New: Equivalence statements in nested modules results in fast growing duplicate statements in module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 Bug ID: 60780 Summary: Equivalence statements in nested modules results in fast growing duplicate statements in module files Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: russelldub at gmail dot com Created attachment 32558 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32558action=edit Code to reproduce issue. Equivalence statements in equivalence statements results in quickly growing number of duplicated statements in nested module files. The attached file shows the issue. Compiled with gfortran equiv_mod.f90 Resulting module files grow from 3.1 kb to 128 kb. (This issue is somewhat mitigated by compressing modules in latest gfortran, but duplicate statements still exist). The fortran interface to HDF5 is affected by this. In code that uses HDF5 in nested fashion module files can grow to multiple GB in size resulting in ICE when memory is exhausted. May be related to pr 38171. Reproduced in 4.4.7, 4.6.1, 4.8.2 and recent git clone.
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #1 from russelldub at gmail dot com --- Equivalence statements in equivalence statements Should read Equivalence statements in modules. Apologies.
[Bug fortran/60781] New: cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 Bug ID: 60781 Summary: cannot match namelist object name Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: lauraelcomeau at yahoo dot co.uk Created attachment 32559 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32559action=edit namelist Hi I am trying to compile code using gfortran on a mac which I have previously successfully compiled and run on a PC. I get the following error: At line 171 of file ./code/INPUT.f90 (unit = 5, file = 'stdin') Fortran runtime error: Cannot match namelist object name ‘met_04270_62_65.txt’ The namelist is attached. I see there are similar errors reported but can't find out whether there is a fix for this or not. Any help would be greatly appreciated - even if it is a workaround. Thanks Laura
[Bug fortran/56203] gfortran.dg/minlocval_3.f90 times out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Target|sparc*-*-solaris2.* |sparc*-*-solaris2.* ||hppa*-*-hpux* CC||danglin at gcc dot gnu.org Host|sparc*-*-solaris2.* |sparc*-*-solaris2.* ||hppa*-*-hpux* Build|sparc*-*-solaris2.* |sparc*-*-solaris2.* ||hppa*-*-hpux* --- Comment #2 from John David Anglin danglin at gcc dot gnu.org --- Also marginal on slower hppa machines.
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Laura C from comment #0) Created attachment 32559 [details] namelist Hi I am trying to compile code using gfortran on a mac which I have previously successfully compiled and run on a PC. I get the following error: At line 171 of file ./code/INPUT.f90 (unit = 5, file = 'stdin') Fortran runtime error: Cannot match namelist object name ‘met_04270_62_65.txt’ The namelist is attached. I see there are similar errors reported but can't find out whether there is a fix for this or not. We'll need the Fortran code. It looks like you're trying to read from stdin. Is this correct? What gfortran command line and how did you execute the program?
[Bug testsuite/60773] [4.9 Regression] FAIL: gcc.dg/vect/pr60656.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorized 1 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60773
Cong Hou congh at google dot com changed:
What|Removed |Added
CC||congh at google dot com
--- Comment #2 from Cong Hou congh at google dot com ---
This is my bad. I have created a new patch as below to fix this issue. Another
email is sent to gcc-patches also.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 414a745..ea860e7 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2014-04-07 Cong Hou co...@google.com
+
+PR testsuite/60773
+* testsuite/lib/target-supports.exp:
+Add check_effective_target_vect_widen_mult_si_to_di_pattern.
+* gcc.dg/vect/pr60656.c: Update the test by checking if the targets
+vect_widen_mult_si_to_di_pattern and vect_long are supported.
+
2014-03-28 Cong Hou co...@google.com
PR tree-optimization/60656
diff --git a/gcc/testsuite/gcc.dg/vect/pr60656.c
b/gcc/testsuite/gcc.dg/vect/pr60656.c
index ebaab62..b80e008 100644
--- a/gcc/testsuite/gcc.dg/vect/pr60656.c
+++ b/gcc/testsuite/gcc.dg/vect/pr60656.c
@@ -1,5 +1,7 @@
/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_long } */
+#include stdarg.h
#include tree-vect.h
__attribute__ ((noinline)) long
@@ -12,7 +14,7 @@ foo ()
for(i = 0; i 4; ++i)
{
long P = v[i];
- s += P*P*P;
+ s += P * P * P;
}
return s;
}
@@ -27,7 +29,7 @@ bar ()
for(i = 0; i 4; ++i)
{
long P = v[i];
- s += P*P*P;
+ s += P * P * P;
__asm__ volatile ();
}
return s;
@@ -35,11 +37,12 @@ bar ()
int main()
{
+ check_vect ();
+
if (foo () != bar ())
abort ();
return 0;
}
-/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect } } */
+/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect { target
vect_widen_mult_si_to_di_pattern } } } */
/* { dg-final { cleanup-tree-dump vect } } */
-
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index bee8471..6d9d689 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3732,6 +3732,27 @@ proc
check_effective_target_vect_widen_mult_hi_to_si_pattern { } {
}
# Return 1 if the target plus current options supports a vector
+# widening multiplication of *int* args into *long* result, 0 otherwise.
+#
+# This won't change for different subtargets so cache the result.
+
+proc check_effective_target_vect_widen_mult_si_to_di_pattern { } {
+global et_vect_widen_mult_si_to_di_pattern
+
+if [info exists et_vect_widen_mult_si_to_di_pattern_saved] {
+verbose check_effective_target_vect_widen_mult_si_to_di_pattern:
using cached result 2
+} else {
+if {[istarget ia64-*-*]
+ || [istarget i?86-*-*]
+ || [istarget x86_64-*-*] } {
+set et_vect_widen_mult_si_to_di_pattern_saved 1
+}
+}
+verbose check_effective_target_vect_widen_mult_si_to_di_pattern:
returning $et_vect_widen_mult_si_to_di_pattern_saved 2
+return $et_vect_widen_mult_si_to_di_pattern_saved
+}
+
+# Return 1 if the target plus current options supports a vector
# widening shift, 0 otherwise.
#
# This won't change for different subtargets so cache the result.
[Bug c++/60775] Instantiates unused class template member function and therefor reports error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60775 --- Comment #1 from Gunther Laure gunther.laure at gmail dot com --- Created attachment 32560 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32560action=edit Testcase
[Bug debug/60782] New: DWARF does not represent _Atomic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60782 Bug ID: 60782 Summary: DWARF does not represent _Atomic Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org C11 has the _Atomic qualifier, but it isn't emitted in DWARF. I found this thread referencing the problem, but no corresponding GCC bug report: http://gcc.gnu.org/ml/gcc/2013-11/msg00139.html The DWARF bug report is here: http://www.dwarfstd.org/ShowIssue.php?issue=131112.1 This should be available in DWARF 5.
[Bug c++/60775] Instantiates unused class template member function and reports error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60775 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- See the last item of http://gcc.gnu.org/gcc-4.9/porting_to.html
[Bug c++/60775] Instantiates unused class template member function and reports error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60775 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Invalid as mentioned.
[Bug other/60783] New: unexpected address variation when taking address of reference, const reference, etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60783
Bug ID: 60783
Summary: unexpected address variation when taking address of
reference, const reference, etc.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: parke.nexus at gmail dot com
I am comparing passing pointers versus references into a function. I
encountered unexpected variations when taking the address of passed in
references.
Perhaps most notably, if
f is declared as: int* const f
h is declared as: const int* const h
then
f is not equal to h
Below is:
1) test code that reproduces the issue
2) output when compiled with g++ 4.8.2 on Ubuntu 14.04 on x68_64
3) output when compiled with g++ 4.7.3 on Ubuntu 13.04 on i686
I in the output, I expect e through l to be identical.
In 2, e f g and l are identical.
h to k are identical to each other, but different from e f g and l.
In 3, e f g and l are identical. h to k are each unique.
Here is code to reproduce the issue:
#include stdio.h
void foo_ab ( int* a, int b ) {
printf ( a %p\n, a );
printf ( b %p\n, b ); }
void foo_cd ( void** c, void* d ) {
printf ( c %p\n, c );
printf ( d %p\n, d ); }
void foo_ef ( int** e, int* const f ) {
printf ( e %p\n, e );
printf ( f %p\n, f ); }
void foo_gh ( int** g, const int* const h ) {
printf ( g %p\n, g );
printf ( h %p\n, h ); }
void foo_i ( const void* const i ) { printf ( i %p\n, i ); }
void foo_j ( const int* const j ) { printf ( j %p\n, j ); }
void foo_k ( void* const k ) { printf ( k %p\n, k ); }
void foo_l ( int* const l ) { printf ( l %p\n, l ); }
int main () {
int n = 5;
int* p = n;
printf ( \n );
foo_ab ( n, n );
// foo_cd ( p, p );// causes compile time error
printf ( \n );
foo_ef ( p, p );
printf ( \n );
foo_gh ( p, p );
printf ( \n );
foo_i ( p );
foo_i ( p );
printf ( \n );
foo_j ( p );
foo_j ( p );
printf ( \n );
foo_k ( p );
foo_k ( p );
printf ( \n );
foo_l ( p );
foo_l ( p );
return 0; }
$ ./a.out
a 0x7fff3a1e669c
b 0x7fff3a1e669c
e 0x7fff3a1e66a0
f 0x7fff3a1e66a0
g 0x7fff3a1e66a0
h 0x7fff3a1e66a8
i 0x7fff3a1e66a8
i 0x7fff3a1e66a8
j 0x7fff3a1e66a8
j 0x7fff3a1e66a8
k 0x7fff3a1e66a8
k 0x7fff3a1e66a8
l 0x7fff3a1e66a0
l 0x7fff3a1e66a0
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
$ ./a.out
a 0xbfc74a3c
b 0xbfc74a3c
e 0xbfc74a40
f 0xbfc74a40
g 0xbfc74a40
h 0xbfc74a44
i 0xbfc74a48
i 0xbfc74a4c
j 0xbfc74a50
j 0xbfc74a54
k 0xbfc74a58
k 0xbfc74a5c
l 0xbfc74a40
l 0xbfc74a40
$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --enable-targets=all --with-cloog
--enable-cloog-backend=ppl --disable-cloog-version-check
--disable-ppl-version-check
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #8 from Michael Meissner meissner at gcc dot gnu.org --- Richard's analysis agrees with mine. The problem is with adding the check for REG_CANNOT_CHANGE_MODE_P, it breaks the direct moves between GPRs and VSX registers for SF. Because internally within the PowerPC, SFmode is stored as DFmode, CANNOT_CHANGE_MODE_CLASS returns true. The original direct mvoe code should not have generated a (SUBREG:DI (REG:SF ...)) in this case, since that is illegal.
[Bug other/60783] unexpected address variation when taking address of reference, const reference, etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60783 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I don't see why this is a bug, g and h should be different. Here is the reason, const int* const cannot lvalue bind to int *, it can lvalue bind to const int* or int* const. So there is a lvalue to rvalue and then a conversion from int * to const int* and then a rvalue to const lvalue reference binding to const int* const . This is true for i, j, and k. For l, int* const can be lvalue bind to int*.
[Bug other/60783] unexpected address variation when taking address of reference, const reference, etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60783 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Parke from comment #0) I in the output, I expect e through l to be identical. Your expectation is wrong. The functions that produce a different values from what you expect are binding a reference of some type X to an object that is not reference-compatible with X, which requires the creation of a temporary of type X. The temporary has a different address from the original object. Any conforming C++ compiler will produce similar results.
[Bug other/60783] unexpected address variation when taking address of reference, const reference, etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60783 --- Comment #3 from Parke parke.nexus at gmail dot com --- Thanks, I thought it might be something like the creation of temporaries, but could not find it discussed anywhere, and was surprised that I got different behavior from 4.7.3 (many temporaries) and 4.8.2 (apparently only one temporary).
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #9 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #7) Created attachment 32557 [details] Updated patch that also uses op0_di for the conversion Should be equivalent to the previous patch, but more correct modewise. I tried this patch on a --with-cpu=power8 bootstrap and it now builds fine.
[Bug other/60783] unexpected address variation when taking address of reference, const reference, etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60783 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Parke from comment #3) Thanks, I thought it might be something like the creation of temporaries, but could not find it discussed anywhere, and was surprised that I got different behavior from 4.7.3 (many temporaries) and 4.8.2 (apparently only one temporary). Well 4.8 is better at coalescing the temporaries as there was a fix to the front-end to produce a CLOBBER after the statement has ended.
[Bug target/60504] [4.9 regression] many Ada testsuite regressions on ARM/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Mon Apr 7 21:31:29 2014 New Revision: 209201 URL: http://gcc.gnu.org/viewcvs?rev=209201root=gccview=rev Log: PR target/60504 * config/arm/arm.h (ASM_PREFERRED_EH_DATA_FORMAT): Expose from ARM_TARGET2_DWARF_FORMAT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gnat.dg/test_raise_from_pure.adb
[Bug target/60504] [4.9 regression] many Ada testsuite regressions on ARM/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Patch applied.
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 --- Comment #2 from Laura C lauraelcomeau at yahoo dot co.uk --- Created attachment 32561 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32561action=edit Input.f90 file
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 --- Comment #3 from Laura C lauraelcomeau at yahoo dot co.uk --- Created attachment 32562 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32562action=edit shell script The code is a series of f90 files compiled in a shell script - as attached. I've also attached the INPUT.f90 file where there is the error reading from the namelist, there is no individual 'stdin' file which is why it was hard to understand the error. Thank you Laura
[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- While the improved predicates make the first IN_RANGE tests unneeded, IMHO it should still verify what the second IN_RANGE tests did, i.e. that operands[2] is not 0 and at most 32 - third operand. I think the combiner just blindly tries to match and simplify, all the verification is performed through trying to recog the insn.
[Bug c/60784] New: Spurious -Wmissing-field-initializers warning for anonymous structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60784
Bug ID: 60784
Summary: Spurious -Wmissing-field-initializers warning for
anonymous structure
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at lekensteyn dot nl
When an anonymous structure gets initialized, gcc always starts complaining
about the last field:
//
gcc -Wextra warn.c -o /dev/null
//
struct foo {
struct {
char a;
char b;
};
};
int main(void) {
struct foo test = {
.a = 1,
.b = 2,
};
return test.a == 1;
}
///
Output:
warn.c: In function ‘main’:
warn.c:12:9: warning: missing initializer for field ‘b’ of ‘struct anonymous’
[-Wmissing-field-initializers]
.b = 2,
^
warn.c:5:14: note: ‘b’ declared here
char b;
^
It gets even worse when adding more fields. For fun, add char c; between
char a; and char b;. The first warning mentions c, but the line
thereafter points to b:
warn.c: In function ‘main’:
warn.c:13:9: warning: missing initializer for field ‘c’ of ‘struct anonymous’
[-Wmissing-field-initializers]
.b = 2,
^
warn.c:5:14: note: ‘c’ declared here
char c;
^
Expected result: no warnings for the first case.
This is gcc-multilib 4.8.2-8 on Arch Linux x86_64.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-4.8-20140206/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-cloog-version-check --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--enable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.2 20140206 (prerelease) (GCC)
[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657 --- Comment #13 from Jeffrey A. Law law at redhat dot com --- The new predicates make the predicate test match the constraint test. It looks like your patch exposes a relationship between the operands, and, yes, the only way to handle that would be in the insn's condition. I'm not ARM savvy enough to know if that's the right condition or not though. jeff
[Bug c++/59115] [4.7/4.8/4.9 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59115 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-08 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #10 from David Edelsohn dje at gcc dot gnu.org --- I'm not questioning the analysis, I'm questioning the solution. Directly generating a register and jamming in the REGNO in this pattern seems sort of crude. gen_rtx_REG (DImode, REGNO (op0)); I don't doubt that this is the RTL that eventually is produced, I am surprised that there is no existing wrapper function in simplify-rtx.c or rtlanal.c that can be used. If this is the necessary implementation, I think it deserves some, brief comment.
[Bug fortran/60781] cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60781 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Mon, Apr 07, 2014 at 10:09:11PM +, lauraelcomeau at yahoo dot co.uk wrote: The code is a series of f90 files compiled in a shell script - as attached. I've also attached the INPUT.f90 file where there is the error reading from the namelist, there is no individual 'stdin' file which is why it was hard to understand the error. Thanks for the file although by itself it is not sufficient to reproduce the problem. I will however speculate. Your code contains ... namelist /grids/ dem_file,vegf_file,vegh_file,wind_file,Nsmax,Nsoil,sx,sy ... read(5, grids) where I find no OPEN statement for unit=5. This means that you are reading from stdin. So, if you are executing the binary JIM_exe, you need to redirect the file with the namelist. You something like % JIM_exe file_with_namelist_data for csh or tcsh. How do you run the resulting JIM_exe?
[Bug tree-optimization/59817] ICE in extract_affine_chrec with -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817
Arseny Solokha asolokha at gmx dot com changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2 from Arseny Solokha asolokha at gmx dot com ---
The following testcase is another way to trigger this segfault:
int kd;
void
n2(void)
{
static int so;
static short int i5;
int wj;
int *il;
int *nk = so;
for (wj = 0; wj 2; ++wj)
*nk = ((i5 += *il) || kd );
}
I can reproduce it on x86_64 w/ 4.8.2 and 4.9.0-alpha20140406.
[Bug tree-optimization/55459] Firefox 17: internal compiler error: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55459
Arseny Solokha asolokha at gmx dot com changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #6 from Arseny Solokha asolokha at gmx dot com ---
The bug is reproducible w/ the following reduced testcase:
void
de(void)
{
static int ey;
static int ux;
short int mb;
int al;
int vx;
int *gs = al;
int *dp = ux;
for (ey = 0; ey 2; ++ey)
*dp = (mb += *gs) || vx;
}
% gcc-4.7.3 -c -O2 -ftree-loop-linear 6b94b1d3.c
6b94b1d3.c: In function 'de':
6b94b1d3.c:2:1: internal compiler error: in scan_tree_for_params_right_scev, at
graphite-sese-to-poly.c:633
gcc 4.8 and 4.9 are not affected. However, they segfault on quite a similar
code from 59817#c2.
[Bug libstdc++/60594] std::function of a type with a declared (but not defined) return type fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60594
Mitsuru Kariya kariya_mitsuru at hotmail dot com changed:
What|Removed |Added
CC||kariya_mitsuru at hotmail dot
com
--- Comment #5 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
FYI, the BUG2 above is compiled successfully by gcc 4.7.3.
cf. http://melpon.org/wandbox/permlink/UZdP4fovs2ATM2iZ
Additionally, the sample code below cannot be compiled by gcc HEAD.
#include functional
struct S {
std::functionS() f;
};
int main()
{
S l{ []{ return S{nullptr}; } };
}
cf. http://melpon.org/wandbox/permlink/HAZ7i5JE94KSQhM7
It is also compiled successfully by gcc 4.7.3.
And I think that struct S is not incomplete type (at least, at the point where
it is used).
[Bug other/60785] New: ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60785
Bug ID: 60785
Summary: ICE in gsi_for_stmt w/ -O2 -ftree-loop-linear
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
gcc-4.9.0-alpha20140406 segfaults on x86_64 when compiling the following code
w/ -O2 -ftree-loop-linear:
static int
aqc(void)
{
return 1;
}
void
gkd(void)
{
int wu0;
static int b1y;
static int gw2;
static int *ydw = gw2;
static int **m3l = ydw;
**m3l = 0;
for (b1y = 0; b1y 1; ++b1y)
{
int *cpj = gw2;
if (*ydw |= aqc())
{
*cpj = 0;
*ydw = wu0;
}
}
}
Stack trace from cc1 is not fully usable, but here are top 5 frames anyway:
#0 0x0072c22c in gsi_for_stmt(gimple_statement_base*) ()
#1 0x00ce708b in ?? ()
#2 0x00ce780f in ?? ()
#3 0x00ceed3e in build_poly_scop(scop*) ()
#4 0x00cd8417 in graphite_transform_loops() ()
This is a regression from previous branches, 4.7.3 and 4.8.2 don't fail here.
[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Attachment #32554|0 |1 is obsolete|| --- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 32563 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32563action=edit possible fix added one missing else: the new version of the patch passes all x86_64 tests now. ARM boot-strap and testing still running and will take a few days.
