[Bug tree-optimization/57331] [4.9 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57331 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-20 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|ICE: tree check: expected |[4.9 Regression] ICE: tree |integer_type or |check: expected |enumeral_type or|integer_type or |boolean_type or real_type |enumeral_type or |or fixed_point_type, have |boolean_type or real_type |pointer_type in |or fixed_point_type, have |int_fits_type_p, at |pointer_type in |tree.c:8437 |int_fits_type_p, at ||tree.c:8437 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r198582
[Bug target/57333] Wrong detection of LZCNT instruction, -mno-lzcnt has no effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57333 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||tmsriram at google dot com Target Milestone|--- |4.7.4 Severity|major |normal --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- LZCNT insn is part of ABM abi, and is enabled with -mabm. Does LZCNT insn really cause SIGILL on your target? The issue with -mno-lzcnt will be fixed as part of patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01054.html
[Bug tree-optimization/57331] [4.9 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57331
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase without missing return:
int
foo (int x)
{
void *p = x ? (void *) 1 : (void *) 0;
__INTPTR_TYPE__ b = (__INTPTR_TYPE__) p;
if (b)
return 0;
return 1;
}
The problem is that int_fits_type_p doesn't handle POINTER_TYPE_P on rhs.
range_fits_type_p should already ensure that innerop is INTEGER_TYPE_P or
POINTER_TYPE_P. So, either we can give up for POINTER_TYPE_P (TREE_TYPE
(innerop)) always, or we could handle just the most important pointer constant
(NULL), instead of the unconditional int_fits_type_p do something like
(POINTER_TYPE_P (TREE_TYPE (innerop))
? integer_zerop (op1)
: int_fits_type_p (op1, TREE_TYPE (innerop
(0 will fit in any pointer type), or we'd need to write larger code to do
essentially what int_fits_type_p does, but using lower_bound_in_type and
upper_bound_in_type instead of TYPE_{MIN,MAX}_VALUE. I'd say the last one
would be overkill.
[Bug rtl-optimization/57300] [4.8/4.9 Regression] statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri May 17 15:22:24 2013 New Revision: 199018 URL: http://gcc.gnu.org/viewcvs?rev=199018root=gccview=rev Log: PR rtl-optimization/57281 PR rtl-optimization/57300 * config/i386/i386.md (extendsidi2_1 dead reg splitter): Remove. (extendsidi2_1 peephole2s): Add instead 2 new peephole2s, that undo what the other splitter did if the registers are dead. * gcc.dg/pr57300.c: New test. * gcc.c-torture/execute/pr57281.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57281.c trunk/gcc/testsuite/gcc.dg/pr57300.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog Author: jakub Date: Fri May 17 15:32:50 2013 New Revision: 199021 URL: http://gcc.gnu.org/viewcvs?rev=199021root=gccview=rev Log: PR rtl-optimization/57281 PR rtl-optimization/57300 * config/i386/i386.md (extendsidi2_1 dead reg splitter): Remove. (extendsidi2_1 peephole2s): Add instead 2 new peephole2s, that undo what the other splitter did if the registers are dead. * gcc.dg/pr57300.c: New test. * gcc.c-torture/execute/pr57281.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57281.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr57300.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/57281] [4.9 Regression] x86_64-linux loop fails to terminate at -O3 -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri May 17 15:22:24 2013 New Revision: 199018 URL: http://gcc.gnu.org/viewcvs?rev=199018root=gccview=rev Log: PR rtl-optimization/57281 PR rtl-optimization/57300 * config/i386/i386.md (extendsidi2_1 dead reg splitter): Remove. (extendsidi2_1 peephole2s): Add instead 2 new peephole2s, that undo what the other splitter did if the registers are dead. * gcc.dg/pr57300.c: New test. * gcc.c-torture/execute/pr57281.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57281.c trunk/gcc/testsuite/gcc.dg/pr57300.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog Author: jakub Date: Fri May 17 15:32:50 2013 New Revision: 199021 URL: http://gcc.gnu.org/viewcvs?rev=199021root=gccview=rev Log: PR rtl-optimization/57281 PR rtl-optimization/57300 * config/i386/i386.md (extendsidi2_1 dead reg splitter): Remove. (extendsidi2_1 peephole2s): Add instead 2 new peephole2s, that undo what the other splitter did if the registers are dead. * gcc.dg/pr57300.c: New test. * gcc.c-torture/execute/pr57281.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57281.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr57300.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/57175] NRVO and alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57175 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- r199093 | glisse | 2013-05-20 09:50:54 +0200 (Mon, 20 May 2013) | 10 lines 2013-05-20 Marc Glisse marc.gli...@inria.fr PR c++/57175 gcc/cp/ * typeck.c (check_return_expr): Reverse the alignment comparison. gcc/testsuite/ * g++.dg/pr57175.C: New testcase.
[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- I don't think the warning is bogus. At phiprop we have: long unsigned int _3; size_t _6; size_t _7; long unsigned int _8; bb 2: _6 = MEM[(const struct InlinedVector *)this_1(D)].size_; _3 = _6 + 1; ... _7 = MEM[(const struct InlinedVector *)this_1(D)].size_; if (_3 _7) goto bb 3; else goto bb 6; bb 3: _8 = _7 - _3; and fre2 turns this into: _6 = MEM[(const struct InlinedVector *)this_1(D)].size_; _3 = _6 + 1; ... _7 = _6; if (_3 _7) goto bb 3; else goto bb 6; bb 3: _8 = 18446744073709551615; i.e. it can't prove the following loop that uses _8 as upper bound is dead, but the loop has at that point constant bounds and triggers undefined behavior in it if executed. The loop can be only executed if foo_.size() is (size_t) -1, but if you call it with this value, you'll surely hit the undefined behavior the warning is complaining about.
[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org --- FYI: Ian Hardy has some fancy examples uses character(:) in DT at the bottom of the thread http://software.intel.com/en-us/forums/topic/326077 (attached files)
[Bug target/57333] Wrong detection of LZCNT instruction, -mno-lzcnt has no effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57333 --- Comment #3 from bernhard.hartleb at gmail dot com --- (In reply to Uroš Bizjak from comment #2) LZCNT insn is part of ABM abi, and is enabled with -mabm. Does LZCNT insn really cause SIGILL on your target? No sorry, this was an error on my part, because I did not know about -mabm before. The compilation of (libQtGui.so.4.8.4) with -march=k8 finished only after reporting this bug and it still produced the illegal instruction. There is no problem with LZCNT, other than -mno-lzcnt not working. My issue is somewhere with LTO, since the build works percectly with LTO disabled. But this will be a different bug report.
[Bug c++/10207] Empty structure initialization fails under C++ (but works under C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10207 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/57327] 'derived' is an ambiguous base class of 'base' diagnostic is backwards
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57327 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/23885] incorrect template two-stage name-lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23885 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com --- Closing.
[Bug lto/57267] [4.9 regression] -flto-partition=none : symbol is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57267 --- Comment #3 from Dmitry G. Dyachenko dimhen at gmail dot com --- testcase fixed in 198917 is this PR duplicate of lto/57038 ? and how it's related to lto/47375 ? Sounds like PR number mismatch...
[Bug c++/57335] New: internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335
Bug ID: 57335
Summary: internal compiler error: in cxx_eval_bit_field_ref, at
cp/semantics.c:6977
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chet.simpson at gmail dot com
This error appears to be caused though the static_assert on a constexpr
containing a union.
prog.cpp: In function ‘int main()’:
prog.cpp:29:48: in constexpr expansion of
‘BitsOrderCheck().BitsOrderCheck::IsLsbBottom()’
prog.cpp:29:58: internal compiler error: in cxx_eval_bit_field_ref, at
cp/semantics.c:6977
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /home/nUBliJ/ccd38zvW.out file, please attach
this to your bugreport.
#include stdint.h
#include iostream
struct BitsOrderCheck
{
union Data
{
struct Bitfield
{
const unsigned char clear:7;
const unsigned char set:1;
};
const unsigned char byte;
const Bitfieldbits;
constexpr Data() : byte(1) {}
};
constexpr BitsOrderCheck() {}
constexpr bool IsLsbBottom() const
{
return 1 == data_.bits.set;
}
const Datadata_;
};
int main()
{
static_assert(BitsOrderCheck().IsLsbBottom(), blah);
std::cout LSB: BitsOrderCheck().IsLsbBottom() std::endl;
return 0;
}
[Bug libstdc++/57336] New: [4.8/4.9 Regression] Cannot INVOKE a reference_wrapper around an abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57336
Bug ID: 57336
Summary: [4.8/4.9 Regression] Cannot INVOKE a reference_wrapper
around an abstract type
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: redi at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
This C++11 example no longer compiles:
#include functional
struct ABC
{
virtual bool operator()() const = 0;
};
struct Concrete : ABC
{
virtual bool operator()() const { return true; }
};
Concrete c;
ABC abc = c;
auto b = std::cref(abc)();
I think we're just missing an rvalue-ref on the function argument and in the
result_of argument in the first overload of __invoke, which is also necessary
to get the right answer when invoking function objects with ref-qualified
function call operators (something I plan to finish support for asap)
[Bug libstdc++/57336] [4.8/4.9 Regression] Cannot INVOKE a reference_wrapper around an abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57336 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.3, 4.8.0 Known to fail||4.8.1, 4.9.0 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I should be able to fix this on trunk later today.
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-20 Blocks||55004 Ever confirmed|0 |1
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Note: all the other compilers I have at hand reject the snippet with an error message about the static_assert expression not being constant (which behavior, in case the analysis shows it's correct, would be easy to obtain with GCC too)
[Bug c++/20724] function overload resolution fails when any template is declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org, | |kjd at duda dot org| Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed long time ago.
[Bug c++/23608] constant propagation (CCP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23608 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- This seems fixed in 4.8: we warn only for line #8. Manu could you please double check we can close this? (thanks a lot again)
[Bug c++/23608] constant propagation (CCP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23608 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- (Nit: the location is off by 2 chars, I think I can easily fix this separately: build_new_op_1 isn't propagating loc to cp_build_binary_op)
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Paolo Carlini from comment #1) I agree that the code should be rejected, because the created BitsOrderCheck object initializes the member 'byte' of the union and later attempts to read the member 'bits', thus causing the exclusion case of core constant expressions: an lvalue-to-rvalue conversion (4.1) or modification (5.17, 5.2.6, 5.3.2) that is applied to a glvalue that refers to a non-active member of a union or a subobject thereof;
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-05-20 Ever confirmed|0 |1 --- Comment #21 from Jan Hubicka hubicka at gcc dot gnu.org --- I submitted the patch to fix weakrefs. Where we are with the compilation now?
[Bug lto/57267] [4.9 regression] -flto-partition=none : symbol is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57267 --- Comment #4 from Jan Hubicka hubicka at ucw dot cz --- is this PR duplicate of lto/57038 ? You are right, I meant lto/57038. This PR is not exactly dup of lto/57038, but while fixing lto/57038 I constructed artificial testcase similar to yours and thus the problem should be fixed by 2013-05-15 Jan Hubicka j...@suse.cz PR lto/57038 PR lto/47375 * lto-symtab.c (lto_symtab_symbol_p): Add external symbol; weakrefs are not external. (lto_symtab_merge_decls): Fix thinko when dealing with non-lto_symtab decls. (lto_symtab_merge_cgraph_nodes): Use lto_symtab_symbol_p. (lto_symtab_prevailing_decl): Get int sync with lto_symtab_symbol_p. * varpool.c (dump_varpool_node): Dump more flags. * lto-partition.c (get_symbol_class): Fix weakrefs. (lto_balanced_map): Fix weakrefs. (privatize_symbol_name): Remove unnecesary label. (rename_statics): Handle weakrefs as statics.
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
The inlining is failed in ipa-inline.c, around line 294:
/* TM pure functions should not be inlined into non-TM_pure
functions. */
else if (is_tm_pure (callee-symbol.decl)
!is_tm_pure (e-caller-symbol.decl))
{
e-inline_failed = CIF_UNSPECIFIED;
inlinable = false;
}
Instead of CIF_UNSPECIFIED we should have warning/error for this case.
Jakub, what should be the behaviour when !tm_pure always_inline
is called from tm_pure function?
Honza
[Bug lto/57267] [4.9 regression] -flto-partition=none : symbol is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57267 Dmitry G. Dyachenko dimhen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Dmitry G. Dyachenko dimhen at gmail dot com --- fixed in r198917 *** This bug has been marked as a duplicate of bug 57038 ***
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 Dmitry G. Dyachenko dimhen at gmail dot com changed: What|Removed |Added CC||dimhen at gmail dot com --- Comment #22 from Dmitry G. Dyachenko dimhen at gmail dot com --- *** Bug 57267 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rth at gcc dot gnu.org, ||torvald at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- I know next to nothing about tm_pure, CCing those that do know.
[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950
--- Comment #5 from Steven Bosscher steven at gcc dot gnu.org ---
This patch makes the ICE go away, but it doesn't really solve the bug.
The scheduler inserts (in this case) notes between basic blocks in the
sched1 pass, which runs in cfglayout mode. But between basic blocks
in cfglayout mode means nothing: such things belong in BB_HEADER and
BB_FOOTER.
But that happens before and after this patch, so the patch merely puts
things back to the status ante quo. So be solved properly later...
Index: haifa-sched.c
===
--- haifa-sched.c (revision 199028)
+++ haifa-sched.c (working copy)
@@ -7442,11 +7442,12 @@ sched_extend_bb (void)
if (NEXT_INSN (insn) == 0
|| (!NOTE_P (insn)
!LABEL_P (insn)
+ !DEBUG_INSN_P (insn)
/* Don't emit a NOTE if it would end up before a BARRIER. */
!BARRIER_P (NEXT_INSN (insn
{
rtx note = emit_note_after (NOTE_INSN_DELETED, insn);
- /* Make insn appear outside BB. */
+ /* Make note appear outside BB. */
set_block_for_insn (note, NULL);
BB_END (EXIT_BLOCK_PTR-prev_bb) = insn;
}
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 Bug 38470 depends on bug 23608, which changed state. Bug 23608 Summary: constant propagation (CCP) would improve -Wsign-compare http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23608 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/23608] constant propagation (CCP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23608 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Location fixed for 4.9.0. If we have reasons to believe the bogus warning is now suppressed only be chance, let's re-open the bug (or move the discussion to 38470?)
[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- That still doesn't look safe -fcompare-debug wise. I mean, if BB ends in a DEBUG_INSN (or more), it could be preceeded by note, label, or some other insns. So shouldn't that be instead rtx insn2 = DEBUG_INSN_P (insn) ? prev_nondebug_insn (insn2) : insn; (I'd hope there shouldn't be DEBUG_INSN only bb's, because then with -g0 insn ought to be NULL and NEXT_INSN (insn) should crash), and use this in the !NOTE_P and !LABEL_P tests? When NEXT_INSN (insn) is used, it should keep using the BB_END insn, even if it is a DEBUG_INSN, we are looking at what comes afterwards.
[Bug c++/57319] [4.8/4.9] Regression: bogus defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-20 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Paul Pluzhnikov from comment #0) However, this particular case *isn't* the problematic case, because (a) this sample code should not trigger the definition of C's move assignment operator, and True, the warning is given at declaration time; it would be possible to move the warning to when the move assignment is used, but that might mean design errors don't get caught until later. (b) there is only one inheritance path from C to B, so it won't be move-assigned multiple times, and True, the warning is given at the point of first virtual derivation rather than when it appears in a diamond-shaped hierarchy. But the purpose of virtual derivation is to support diamond-shaped hierarchies, so again it seems appropriate to warn sooner rather than later. (c) the issue isn't with *non-trivial* move assignments, it's with *user-provided* move-assignments (for the virtual base or any of its subobjects), which B does not have. Agreed, it would definitely be better for the warning to check that none of the subobjects of B have user-provided move-assignments.
[Bug tree-optimization/57337] New: 416.gamess ICE on x86 after r199048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337 Bug ID: 57337 Summary: 416.gamess ICE on x86 after r199048 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: izamyatin at gmail dot com CC: eraman at google dot com Target: x86 gfortran -c -o mp2ddi.fppized.o -O2 -ffast-math -ffixed-form mp2ddi.fppized.f mp2ddi.fppized.f: In function 'pmp2chk': mp2ddi.fppized.f:5365:0: error: definition in block 11 follows the use SUBROUTINE PMP2CHK ^ for SSA_NAME: _314 in statement: _319 = _314 + _320; mp2ddi.fppized.f:5365:0: internal compiler error: verify_ssa failed 0xaf0aa4 verify_ssa(bool) ../../gcc/tree-ssa.c:1046 0x8c3e72 execute_function_todo ../../gcc/passes.c:1970 0x8c47cd execute_todo ../../gcc/passes.c:2002 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. specmake: *** [mp2ddi.fppized.o] Error 1
[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950
--- Comment #7 from Steven Bosscher steven at gcc dot gnu.org ---
Index: haifa-sched.c
===
--- haifa-sched.c (revision 199028)
+++ haifa-sched.c (working copy)
@@ -7435,20 +7435,19 @@ find_fallthru_edge_from (basic_block pre
static void
sched_extend_bb (void)
{
- rtx insn;
-
/* The following is done to keep current_sched_info-next_tail non null. */
- insn = BB_END (EXIT_BLOCK_PTR-prev_bb);
+ rtx end = BB_END (EXIT_BLOCK_PTR-prev_bb);
+ rtx insn = DEBUG_INSN_P (end) ? prev_nondebug_insn (end) : end;
if (NEXT_INSN (insn) == 0
|| (!NOTE_P (insn)
!LABEL_P (insn)
/* Don't emit a NOTE if it would end up before a BARRIER. */
!BARRIER_P (NEXT_INSN (insn
{
- rtx note = emit_note_after (NOTE_INSN_DELETED, insn);
- /* Make insn appear outside BB. */
+ rtx note = emit_note_after (NOTE_INSN_DELETED, end);
+ /* Make note appear outside BB. */
set_block_for_insn (note, NULL);
- BB_END (EXIT_BLOCK_PTR-prev_bb) = insn;
+ BB_END (EXIT_BLOCK_PTR-prev_bb) = end;
}
}
[Bug fortran/57338] New: ICE with assumed rank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57338 Bug ID: 57338 Summary: ICE with assumed rank Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com This function produces ICE with gcc-4.8 from 20130509: function avg(a) integer :: avg integer,intent(in) :: a(..) avg = sum(a)/size(a) end function gfortran -c ice9.f90 ice9.f90: In function ‘avg’: ice9.f90:5:0: internal compiler error: in conv_array_index_offset, at fortran/trans-array.c:2913 avg = sum(a)/size(a) ^ 0x5e8f6b conv_array_index_offset ../../gcc-4.8-20130509/gcc/fortran/trans-array.c:2913 0x5e9304 gfc_conv_scalarized_array_ref ../../gcc-4.8-20130509/gcc/fortran/trans-array.c:3044 0x5e9c39 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_symbol*, locus*) ../../gcc-4.8-20130509/gcc/fortran/trans-array.c:3172 0x60cd8f gfc_conv_variable ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:1809 0x609e5a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:6266 0x60c573 gfc_conv_expr_val(gfc_se*, gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:6311 0x61b266 gfc_conv_intrinsic_arith ../../gcc-4.8-20130509/gcc/fortran/trans-intrinsic.c:2747 0x61d6b7 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/trans-intrinsic.c:6840 0x6098e2 gfc_conv_function_expr ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:5547 0x609dca gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:6258 0x609f3a gfc_conv_expr_op ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:2476 0x609f3a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:6254 0x60f3a6 gfc_trans_assignment_1 ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:7739 0x5e3975 trans_code ../../gcc-4.8-20130509/gcc/fortran/trans.c:1422 0x600c92 gfc_generate_function_code(gfc_namespace*) ../../gcc-4.8-20130509/gcc/fortran/trans-decl.c:5397 0x5a49d0 translate_all_program_units ../../gcc-4.8-20130509/gcc/fortran/parse.c:4474 0x5a49d0 gfc_parse_file() ../../gcc-4.8-20130509/gcc/fortran/parse.c:4688 0x5dfd15 gfc_be_parse_file ../../gcc-4.8-20130509/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950 --- Comment #8 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com --- --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- That still doesn't look safe -fcompare-debug wise. I mean, if BB ends in a DEBUG_INSN (or more), it could be preceeded by note, label, or some other insns. So shouldn't that be instead rtx insn2 = DEBUG_INSN_P (insn) ? prev_nondebug_insn (insn2) : insn; I suppose so, yes. (I'd hope there shouldn't be DEBUG_INSN only bb's, because then with -g0 insn ought to be NULL and NEXT_INSN (insn) should crash), and use this in the !NOTE_P and !LABEL_P tests? This block is a DEBUG_INSN-only block, but insn is never NULL: BB_END will be the basic block note.
[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Steven Bosscher from comment #7)
Index: haifa-sched.c
===
--- haifa-sched.c (revision 199028)
+++ haifa-sched.c (working copy)
@@ -7435,20 +7435,19 @@ find_fallthru_edge_from (basic_block pre
static void
sched_extend_bb (void)
{
- rtx insn;
-
/* The following is done to keep current_sched_info-next_tail non null.
*/
- insn = BB_END (EXIT_BLOCK_PTR-prev_bb);
+ rtx end = BB_END (EXIT_BLOCK_PTR-prev_bb);
+ rtx insn = DEBUG_INSN_P (end) ? prev_nondebug_insn (end) : end;
if (NEXT_INSN (insn) == 0
This should be NEXT_INSN (end) == 0
|| (!NOTE_P (insn)
!LABEL_P (insn)
/* Don't emit a NOTE if it would end up before a BARRIER. */
!BARRIER_P (NEXT_INSN (insn
and this !BARRIER_P (NEXT_INSN (end
{
- rtx note = emit_note_after (NOTE_INSN_DELETED, insn);
- /* Make insn appear outside BB. */
+ rtx note = emit_note_after (NOTE_INSN_DELETED, end);
+ /* Make note appear outside BB. */
set_block_for_insn (note, NULL);
- BB_END (EXIT_BLOCK_PTR-prev_bb) = insn;
+ BB_END (EXIT_BLOCK_PTR-prev_bb) = end;
}
}
[Bug tree-optimization/57337] 416.gamess ICE on x86 after r199048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337 --- Comment #1 from Easwaran Raman eraman at google dot com --- Could you please attach the preprocessed file? Thanks.
[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199 --- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Jakub Jelinek from comment #3) it can't prove the following loop that uses _8 as upper bound is dead, ... Do we need a separate may invoke undefined behavior warning? In our codebase of 100+ million lines of C++, we've found ~20 instances of real invokes undefined behavior (so we don't want to turn the -Waggressive-loop-optimizations off). But we also have ~5 instances where the warning is bogus, and there is no easy way to turn them off, short of sprinkling -Wno-aggresive-loop-optimizations over our BUILD files.
[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
But this isn't any form of the may invoke, the loop certainly unconditionally
invokes undefined behavior, just the whole loop is very unlikely to be ever
executed (in this case if size is supposed to represent the length of an array
with elements bigger than 1, then already the size would need to be invalid,
but that is something the compiler can't understand, for it the size_t field is
likely any other field, and there is no guarantee it won't be -1).
It is in principle no different from say:
void
foo (size_t x)
{
if (x == (size_t) -1)
{
unsigned int a[128];
int i;
for (i = 0; i 128; ++i) /* { dg-message note: containing loop }
*/
a[i] = i * 0x0201; /* { dg-warning invokes undefined
behavior } */
bar (a);
}
}
where you know you are never going to call foo with (size_t) -1, but the
compiler doesn't know. How is the above different from say:
void
bar (void)
{
unsigned int a[128];
int i;
for (i = 0; i 128; ++i) /* { dg-message note: containing loop } */
a[i] = i * 0x0201; /* { dg-warning invokes undefined behavior }
*/
bar (a);
}
...
/* in another CU */
void
baz (size_t x)
{
if (x == (size_t) -1)
bar ();
}
In your original testcase, you wouldn't get the warning if size was a signed
integer instead of unsigned one, then the compiler would know it is undefined
behavior if the size wraps and would just optimize the loop away altogether.
Or perhaps some __builtin_unreachable assert that size isn't (size_t) -1?
[Bug c++/12288] unintelligible error message for constructor declaration with misspelled type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12288
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|
Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle
dot com
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
Given that Comment#2 is now fine, I think that the only remaining issue here is
that for Comment#1 we also give (additionally to the sane error message)
12288_1.C:4:27: error: ISO C++ forbids declaration of ‘parameter’ with no type
[-fpermissive]
explicit S (const X::T) {}
Should be easy to avoid, because there is already a mechanism for that in
grokdeclarator (type_was_error_mark_node)
[Bug target/57339] New: [SH] Wrong ISR FPU register save/restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57339
Bug ID: 57339
Summary: [SH] Wrong ISR FPU register save/restore
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
CC: kkojima at gcc dot gnu.org
Target: sh*-*-*
The following test case
extern void foo (void);
#pragma interrupt
#pragma nosave_low_regs
void
isr (void)
{
foo ();
}
with -O2 -m4 -ml compiles to:
isr:
fmov.sfr0,@-r15
fmov.sfr1,@-r15
fmov.sfr2,@-r15
fmov.sfr3,@-r15
fmov.sfr4,@-r15
fmov.sfr5,@-r15
fmov.sfr6,@-r15
fmov.sfr7,@-r15
fmov.sfr8,@-r15
fmov.sfr9,@-r15
fmov.sfr10,@-r15
fmov.sfr11,@-r15
sts.lmach,@-r15
sts.lmacl,@-r15
sts.lfpul,@-r15
sts.lfpscr,@-r15
sts.lpr,@-r15
mov.l.L3,r1
lds.l@r1+,fpscr ! 57fpu_switch/2[length = 2]
mov.l.L4,r1
jsr@r1
nop
lds.l@r15+,pr
lds.l@r15+,fpscr ! 38fpu_switch/2[length = 2]
lds.l@r15+,fpul
lds.l@r15+,macl
lds.l@r15+,mach
fmov.s@r15+,fr11
fmov.s@r15+,fr10
fmov.s@r15+,fr9
fmov.s@r15+,fr8
fmov.s@r15+,fr7
fmov.s@r15+,fr6
fmov.s@r15+,fr5
fmov.s@r15+,fr4
fmov.s@r15+,fr3
fmov.s@r15+,fr2
fmov.s@r15+,fr1
rte
fmov.s@r15+,fr0
The FPU register save/restore insns in the ISR epilogue and prologue are wrong
since they refer to the FPSCR setting at the point of the interruption, but the
FPSCR setting is not known at ISR function entry.
For example, if the interrupted context's FPSCR has FPSCR.SZ = 1 (64 bit fmov)
the code above will not work properly and is most likely going to result in an
address error.
A better way would be to do something like...
isr:
! FPSCR.SZ, FPSCR.PR, FPSCR.FR of interrupted
! context is not known.
mov r15,r0
or #7,r0
xor #7,r0
mov r0,r15 ! r15 = 64 bit aligned stack ptr
mova .Lvariables,r0
sts.l fpscr,@-r15 ! push FPSCR of interrupted context
add #-4,r15 ! keep r15 64 bit aligned
lds.l @r0+,fpscr ! FPSCR.SZ = 1, FPSCR.PR = 0, FPSCR.FR = 0
! if FPSCR.FR was 1 we have now switched the
! FP reg banks and will be saving XF regs.
! that's OK if the ISR code does not switch
! FPSCR.FR.
fmov.d dr0,@-r15
fmov.d dr2,@-r15
fmov.d dr4,@-r15
fmov.d dr6,@-r15
fmov.d dr8,@-r15
fmov.d dr10,@-r15
sts.lfpscr,@-r15 ! push FPSCR setting for restoring FP regs
! before ISR returns.
lds.l @r0+,fpscr ! default FPSCR setting for ISRs
! FPSCR.PR must be kept = 0
sts.l fpul,@-r15
sts.l mach,@-r15
sts.l macl,@-r15
sts.l pr,@-r15
...
ISR code
...
lds.l @r15+,pr
lds.l @r15+,macl
lds.l @r15+,mach
lds.l @r15+,fpul
lds.l @r15+,fpscr ! pop FPSCR setting for FP reg restore
! FPSCR.SZ = 1, FPSCR.PR = 0, FPSCR.FR = 0
fmov.d @r15+,dr10
fmov.d @r15+,dr8
fmov.d @r15+,dr6
fmov.d @r15+,dr4
fmov.d @r15+,dr2
fmov.d @r15+,dr0
add #4,r15
rte
lds.l @r15+,fpscr ! restore FPSCR of interrupted context
! this potentially switches FPSCR.FR
.align 2
.Lvariables:
.long 1 20 ! FPSCR.SZ = 1, FPSCR.PR = 0, FPSCR.FR = 0
.long default FPSCR value for ISR ! FPSCR.FR must be = 0
Some remarks:
-
This insn:
add #-4,r15 ! keep r15 64 bit aligned
can be replaced with one of the push insns that follow the fmov.d pushes.
-
The above won't work for SH2E and SH3E. Those need their own sequence.
-
The stack alignment can be omitted if it has been aligned already somehow else,
e.g. by specifying 'sp_switch' function attribute. On SH3* and SH4* the ISR
vectors are grouped, so there is always some common code that is executed
before it invokes the actual ISR. That code might as well align the stack.
-
An alternative stack alignment sequence could be:
mova .Lvariables,r0
mov.l
[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com --- perhaps some __builtin_unreachable assert that size isn't (size_t) -1? That works. Thanks for the suggestion.
[Bug c++/57317] [4.8/4.9] Regression bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57317 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.8.1 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed the false positive for 4.8.1.
[Bug tree-optimization/57303] [4.7/4.8/4.9 Regression] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303
--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org ---
I wonder if, in addition to fixing the sink pass, we should add an optimization
like the following (it passes bootstrap+testsuite, but I am not so sure where
it should go and what it should look like exactly).
--- gimple-fold.c(revision 199093)
+++ gimple-fold.c(working copy)
@@ -1174,20 +1174,27 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
if ((commutative_tree_code (subcode)
|| commutative_ternary_tree_code (subcode))
tree_swap_operands_p (gimple_assign_rhs1 (stmt),
gimple_assign_rhs2 (stmt), false))
{
tree tem = gimple_assign_rhs1 (stmt);
gimple_assign_set_rhs1 (stmt, gimple_assign_rhs2 (stmt));
gimple_assign_set_rhs2 (stmt, tem);
changed = true;
}
+/* Remove *p = *p. */
+if (!inplace TREE_CODE_CLASS (subcode) == tcc_reference
+ operand_equal_p (lhs, gimple_assign_rhs1 (stmt), 0))
+ {
+gsi_remove (gsi, true);
+return true;
+ }
new_rhs = fold_gimple_assign (gsi);
if (new_rhs
!useless_type_conversion_p (TREE_TYPE (lhs),
TREE_TYPE (new_rhs)))
new_rhs = fold_convert (TREE_TYPE (lhs), new_rhs);
if (new_rhs
(!inplace
|| get_gimple_rhs_num_ops (TREE_CODE (new_rhs)) old_num_ops))
{
gimple_assign_set_rhs_from_tree (gsi, new_rhs);
[Bug tree-optimization/56547] [SH] missed opportunity for fmac with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org --- Fixed for SH on 4.9: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=199110 gcc/ChangeLog: PR target/56547 * config/sh/sh.md (fmasf4): Remove empty constraints strings. (*fmasf4, *fmasf4_media): New insns. gcc/testsuite/ChangeLog: PR target/56547 * gcc.target/sh/pr56547-1.c: New. * gcc.target/sh/pr56547-2.c: New.
[Bug c++/57325] [4.7/4.8/4.9 Regression] ICE in strip_typedefs, at cp/tree.c:1306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57325 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.7.4 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.7.4/4.8.1/4.9.
[Bug c++/57319] [4.8 Regression]: bogus defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Summary|[4.8/4.9] Regression: bogus |[4.8 Regression]: bogus |defaulted move assignment |defaulted move assignment |for ... calls a non-trivial |for ... calls a non-trivial |move assignment operator|move assignment operator |for virtual base ... |for virtual base ... --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.9 for now.
[Bug fortran/57035] TS29113's C535b: Wrongly accept DIMENSION(..) to TRANSFER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57035 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Should be fixed by the - pending - patch: http://gcc.gnu.org/ml/fortran/2013-04/msg00206.html
[Bug fortran/57338] ICE with assumed rank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57338 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- I think that has been fixed by my patch for PR57035, which I seemingly have never committed: http://gcc.gnu.org/ml/fortran/2013-04/msg00206.html
[Bug c++/12288] unintelligible error message for constructor declaration with misspelled type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12288 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Spurious error message avoided for 4.9.0.
[Bug web/54651] Bugzilla sending broken emails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54651 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- This seems to have been fixed around May 8th (or for some reason I am not affected anymore).
[Bug c++/12288] unintelligible error message for constructor declaration with misspelled type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12288 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Excellent, thanks!
[Bug c++/36486] g++ accepts code with ambiguous overloading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org|jason at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Current ICC and Clang accept this, like GCC. Jason, can you double check that we are already doing the right thing?
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org|fabien at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- PR14258 is fixed and this is still rejected. Maybe Fabien wants to have a look?!?
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #3 from Paul H. Hargrove PHHargrove at lbl dot gov --- (In reply to Kostya Serebryany from comment #1) Sorry for the breakages, but we are unable to monitor build failures on old kernels unless someone sets up a regular testing (build bot) with such kernels for upstream code. This error is from a private build bot I've now got set up to perform daily builds of the gupc branch in SVN (see http://gcc.gnu.org/projects/gupc.html). As changes are merged from the trunk to that branch I will notice any build failures and I report them to the GCC Bugzilla if/when I can reproduce them in the trunk or recent snapshot (eg bug 55989) or in a release (as with this bug). Otherwise they are reported to the GUPC team. I am configuring with --disable-libsanitizer right now, but will remove that when/if this bug is resolved such that I can build again. (In reply to Jakub Jelinek from comment #2) If you don't have __NR_exit_group, your kernel very likely doesn't have the rest of NPTL support either (so e.g. __NR_futex), so I'm surprised this is the only error. This is an old Red Hat 2.4.21-60.ELsmp kernel that contains various bits that Red Hat backported. So, the unistd.h has __NR_fuxtex but not __NR_exit_group. I can't say for sure that futex works, however, as there is no NPTL version of libpthread on the system. For my own purposes, there is no need to make libsanitizer work on this platform. So, if that is not possible I'd like to see configure probe for each of the syscall numbers (and prctl constants as in bug 55989) and then automatically disable building the sanitizer code if any are missing. I don't like current the build-is-broken-by-default situation.
[Bug c++/36486] g++ accepts code with ambiguous overloading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- N3281 changed the rules such that g++ is now correct.
[Bug c++/36486] g++ accepts code with ambiguous overloading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|jason at gcc dot gnu.org | --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Ah, great, thanks!
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #23 from Martin Liška marxin.liska at gmail dot com --- The patch fixed weakrefs problems. Compilation goes further and some undefined stuff in libreoffice is met: https://bugs.freedesktop.org/show_bug.cgi?id=61627 I think this gcc bug could be closed.
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon May 20 20:03:48 2013 New Revision: 199118 URL: http://gcc.gnu.org/viewcvs?rev=199118root=gccview=rev Log: 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 * decl.c (gfc_match_bind_c_stmt): Add gfc_notify_std. * match.c (gfc_match_common): Don't add commons to gsym. * resolve.c (resolve_common_blocks): Add to gsym and add checks. (resolve_bind_c_comms): Remove. (resolve_types): Remove call to the latter. * trans-common.c (gfc_common_ns): Remove static var. (gfc_map_of_all_commons): Add static var. (build_common_decl): Correctly handle binding label. 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 * gfortran.dg/test_common_binding_labels.f03: Update dg-error. * gfortran.dg/test_common_binding_labels_2_main.f03: Ditto. * gfortran.dg/test_common_binding_labels_3_main.f03: Ditto. * gfortran.dg/common_18.f90: New. * gfortran.dg/common_19.f90: New. * gfortran.dg/common_20.f90: New. * gfortran.dg/common_21.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/common_18.f90 trunk/gcc/testsuite/gfortran.dg/common_19.f90 trunk/gcc/testsuite/gfortran.dg/common_20.f90 trunk/gcc/testsuite/gfortran.dg/common_21.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-common.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/test_common_binding_labels.f03 trunk/gcc/testsuite/gfortran.dg/test_common_binding_labels_2_main.f03 trunk/gcc/testsuite/gfortran.dg/test_common_binding_labels_3_main.f03
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon May 20 20:05:40 2013 New Revision: 199119 URL: http://gcc.gnu.org/viewcvs?rev=199119root=gccview=rev Log: 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 * decl.c (add_global_entry): Use nonbinding name only for F2003 or if no binding label exists. (gfc_match_entry): Update calls. * parse.c (gfc_global_used): Improve error message. (add_global_procedure): Use nonbinding name only for F2003 or if no binding label exists. (gfc_parse_file): Update call. * resolve.c (resolve_global_procedure): Use binding name when available. * trans-decl.c (gfc_get_extern_function_decl): Ditto. 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 * gfortran.dg/binding_label_tests_17.f90: New. * gfortran.dg/binding_label_tests_18.f90: New. * gfortran.dg/binding_label_tests_19.f90: New. * gfortran.dg/binding_label_tests_20.f90: New. * gfortran.dg/binding_label_tests_21.f90: New. * gfortran.dg/binding_label_tests_22.f90: New. * gfortran.dg/binding_label_tests_23.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/binding_label_tests_17.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_18.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_19.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_20.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_21.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_22.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_23.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 --- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon May 20 20:08:05 2013 New Revision: 199120 URL: http://gcc.gnu.org/viewcvs?rev=199120root=gccview=rev Log: 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 PR fortran/55465 * decl.c (add_global_entry): Add sym_name. * parse.c (add_global_procedure): Ditto. * resolve.c (resolve_bind_c_derived_types): Handle multiple decl for a procedure. (resolve_global_procedure): Handle gsym-ns pointing to a module. * trans-decl.c (gfc_get_extern_function_decl): Ditto. 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 PR fortran/55465 * gfortran.dg/binding_label_tests_10_main.f03: Update dg-error. * gfortran.dg/binding_label_tests_11_main.f03: Ditto. * gfortran.dg/binding_label_tests_13_main.f03: Ditto. * gfortran.dg/binding_label_tests_3.f03: Ditto. * gfortran.dg/binding_label_tests_4.f03: Ditto. * gfortran.dg/binding_label_tests_5.f03: Ditto. * gfortran.dg/binding_label_tests_6.f03: Ditto. * gfortran.dg/binding_label_tests_7.f03: Ditto. * gfortran.dg/binding_label_tests_8.f03: Ditto. * gfortran.dg/c_loc_tests_12.f03: Fix test case. * gfortran.dg/binding_label_tests_24.f90: New. * gfortran.dg/binding_label_tests_25.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/binding_label_tests_24.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_25.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/binding_label_tests_10_main.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_11_main.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_13_main.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_3.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_4.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_5.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_6.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_7.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_8.f03 trunk/gcc/testsuite/gfortran.dg/c_loc_tests_12.f03
[Bug tree-optimization/57337] 416.gamess ICE on x86 after r199048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #2 from Pat Haugen pthaugen at gcc dot gnu.org --- Created attachment 30149 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30149action=edit Reduced testcase Happens on PowerPC also, reduced src attatched. [pthaugen@igoo ~]$ /home/pthaugen/install/gcc/trunk/bin/gfortran -c -m64 -O2 -ffast-math gamess.f gamess.f: In function ‘pmp2chk’: gamess.f:1:0: error: definition in block 11 follows the use SUBROUTINE PMP2CHK ^ for SSA_NAME: _314 in statement: _319 = _314 + _320; gamess.f:1:0: internal compiler error: verify_ssa failed 0x10892d87 verify_ssa(bool) /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa.c:1046 0x105ddcdb execute_function_todo /home/pthaugen/src/gcc/trunk/gcc/gcc/passes.c:1970 0x105de7bf do_per_function /home/pthaugen/src/gcc/trunk/gcc/gcc/passes.c:1707 0x105de9db execute_todo /home/pthaugen/src/gcc/trunk/gcc/gcc/passes.c:2002 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org --- All issues of this PR should be now FIXED (on the 4.9 trunk). The commit in comment 14 ensures that for COMMON, the binding label is all what matters. The commit in comment 15 ensures the same for procedures. And the commit in comment 16 permits multiple INTERFACE declarations - especially if they are the same! - for the same binding label. Thanks for the report and the patience. (I am still not sure whether the code in comment 0 is valid or not, but the commit of comment 16 permits it.)
[Bug fortran/53478] gfortran segfaults when module name clashes with C binding name of procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53478 Bug 53478 depends on bug 48858, which changed state. Bug 48858 Summary: Incorrect error for same binding label on two generic interface specifics http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 Bug 55465 depends on bug 48858, which changed state. Bug 48858 Summary: Incorrect error for same binding label on two generic interface specifics http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon May 20 20:08:05 2013 New Revision: 199120 URL: http://gcc.gnu.org/viewcvs?rev=199120root=gccview=rev Log: 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 PR fortran/55465 * decl.c (add_global_entry): Add sym_name. * parse.c (add_global_procedure): Ditto. * resolve.c (resolve_bind_c_derived_types): Handle multiple decl for a procedure. (resolve_global_procedure): Handle gsym-ns pointing to a module. * trans-decl.c (gfc_get_extern_function_decl): Ditto. 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 PR fortran/55465 * gfortran.dg/binding_label_tests_10_main.f03: Update dg-error. * gfortran.dg/binding_label_tests_11_main.f03: Ditto. * gfortran.dg/binding_label_tests_13_main.f03: Ditto. * gfortran.dg/binding_label_tests_3.f03: Ditto. * gfortran.dg/binding_label_tests_4.f03: Ditto. * gfortran.dg/binding_label_tests_5.f03: Ditto. * gfortran.dg/binding_label_tests_6.f03: Ditto. * gfortran.dg/binding_label_tests_7.f03: Ditto. * gfortran.dg/binding_label_tests_8.f03: Ditto. * gfortran.dg/c_loc_tests_12.f03: Fix test case. * gfortran.dg/binding_label_tests_24.f90: New. * gfortran.dg/binding_label_tests_25.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/binding_label_tests_24.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_25.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/binding_label_tests_10_main.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_11_main.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_13_main.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_3.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_4.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_5.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_6.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_7.f03 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_8.f03 trunk/gcc/testsuite/gfortran.dg/c_loc_tests_12.f03
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org --- Close as FIXED (on the 4.9 trunk). The example of comment 3 is now accepted. (I am still not sure whether it is valid, but gfortran does not try to enforce that the interface matches the C one by ensuring consistency between difference INTERFACE declarations. Before, it also rejected identical INTERFACE declarations (with different Fortran name or in different scoping units), which was definitely a bug.)
[Bug bootstrap/57340] New: [4.9 regression] stage2 miscompiles build/genconditions on armv5tel-linux-gnueabi breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57340 Bug ID: 57340 Summary: [4.9 regression] stage2 miscompiles build/genconditions on armv5tel-linux-gnueabi breaking bootstrap Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpe at it dot uu.se Attempting to bootstrap gcc-4.9-20130519 on armv5tel-linux-gnueabi fails with: /mnt/scratch/objdir49/./prev-gcc/xg++ -B/mnt/scratch/objdir49/./prev-gcc/ -B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/ -nostdinc++ -B/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -B/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi -I/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include -I/mnt/scratch/gcc-4.9-20130519/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -L/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/mnt/scratch/gcc-4.9-20130519/gcc -I/mnt/scratch/gcc-4.9-20130519/gcc/build -I/mnt/scratch/gcc-4.9-20130519/gcc/../include -I/mnt/scratch/gcc-4.9-20130519/gcc/../libcpp/include -I/mnt/scratch/gcc-4.9-20130519/gcc/../libdecnumber -I/mnt/scratch/gcc-4.9-20130519/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/scratch/gcc-4.9-20130519/gcc/../libbacktrace\ -o build/genconditions.o /mnt/scratch/gcc-4.9-20130519/gcc/genconditions.c /mnt/scratch/objdir49/./prev-gcc/xg++ -B/mnt/scratch/objdir49/./prev-gcc/ -B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/ -nostdinc++ -B/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -B/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi -I/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include -I/mnt/scratch/gcc-4.9-20130519/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -L/mnt/scratch/objdir49/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/genconditions \ build/genconditions.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/read-md.o build/errors.o .././libiberty/libiberty.a build/genconditions /mnt/scratch/gcc-4.9-20130519/gcc/config/arm/arm.md tmp-condmd.c /bin/sh: line 1: 4055 Segmentation fault build/genconditions /mnt/scratch/gcc-4.9-20130519/gcc/config/arm/arm.md tmp-condmd.c make[3]: *** [s-conditions] Error 139 make[3]: Leaving directory `/mnt/scratch/objdir49/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir49' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir49' make: *** [bootstrap] Error 2 Running it in gdb it seems to have followed a NULL function pointer or code label: cd gcc gdb build/genconditions ... (gdb) run /mnt/scratch/gcc-4.9-20130519/gcc/config/arm/arm.md tmp-condmd.c Starting program: /mnt/scratch/objdir49/gcc/build/genconditions /mnt/scratch/gcc-4.9-20130519/gcc/config/arm/arm.md tmp-condmd.c Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x000101b8 in init_rtx_reader_args_cb(int, char**, bool (*)(char const*)) () #2 0x8ec4 in main () This is a regression from gcc-4.9-20130512 which bootstrapped fine on the same system. And build/genconditions was built earlier during stage1 by the system compiler, and that binary didn't SEGV.
[Bug target/57341] New: wrong code on x86_64-linux at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
Bug ID: 57341
Summary: wrong code on x86_64-linux at -O3 in 32-bit mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled on gcc trunk and 4.8 branch on
x86_64-linux-gnu, at -O3 optimization level, in 32-bit mode, resulting in
output of 0 rather than 1. It is compiled correctly at all optimization levels
with gcc 4.7.
$ gcc-trunk -v
gcc version 4.9.0 20130520 (experimental) [trunk revision 199099] (GCC)
$ gcc-trunk -O2 -m32 wrong.c
$ ./a.out
1
$ gcc-trunk -O3 -m64 wrong.c
$ ./a.out
1
$ gcc-4.7 -O3 -m32 wrong.c
$ ./a.out
1
$ gcc-trunk -O3 -m32 wrong.c
$ ./a.out
0
---
int printf(const char *, ...);
int a, d;
int *b = a, **c;
int main ()
{
int e;
{
int f[4];
for (d = 0; d 4; d++)
f[d] = 1;
e = f[1];
}
int *g[28] = { };
*b = e;
c = g[0];
printf (%d\n, a);
return 0;
}
[Bug tree-optimization/57330] ICE: verify_gimple failed -O3 [tree-cfg.c:4792]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57330 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-20 CC||mjambor at suse dot cz, ||mpolacek at gcc dot gnu.org Known to work||4.7.3 Target Milestone|--- |4.8.1 Ever confirmed|0 |1 Known to fail||4.8.0, 4.9.0 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. Started with http://gcc.gnu.org/r176424
[Bug c++/57342] New: [C++11] Warning for narrowing conversion has ugly formatting for floating point number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57342
Bug ID: 57342
Summary: [C++11] Warning for narrowing conversion has ugly
formatting for floating point number
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: austern at google dot com
When I compile the following code
void foo() {
int pi{3.14};
};
I get the following output:
[isolde:tmp]$ ~/root/bin/g++ -c -std=c++11 foo.cc
foo.cc: In function ‘void foo()’:
foo.cc:2:14: warning: narrowing conversion of ‘3.1401e+0’ from
‘double’ to ‘int’ inside { } [-Wnarrowing]
int pi{3.14};
^
The warning is of course correct. (Arguably it ought to be an error instead of
just a warning, but I won't quibble. The standard requires a diagnostic and
we're getting a diagnostic.) I'm filing this bug because I expect to see
narrowing conversion of ‘3.14' from 'double' to 'int', as opposed to
narrowing conversion of ‘3.1401e+0' from 'double' to 'int'. Yes,
I'm sure the two forms are equivalent within the precision we're using, but one
form is human-friendly and the other isn't.
Configuration:
[isolde:tmp]$ ~/root/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/google/home/austern/root/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/google/home/austern/root/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/google/home/austern/root
--enable-languages=c++
Thread model: posix
gcc version 4.9.0 20130520 (experimental) (GCC)
[isolde:tmp]$
[Bug rtl-optimization/57343] New: wrong code on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
Bug ID: 57343
Summary: wrong code on x86_64-linux at -Os and above
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled on x86_64-linux at -Os and above with gcc
trunk and at -O2 and above with gcc 4.8. It outputs 0 rather than 4 as it
should. It works correctly with gcc 4.7.
$ gcc-trunk -v
gcc version 4.9.0 20130520 (experimental) [trunk revision 199099] (GCC)
$ gcc-trunk -O1 wrong.c
$ ./a.out
4
$ gcc-4.7 -Os wrong.c
$ ./a.out
4
$ gcc-trunk -Os wrong.c
$ ./a.out
0
$
--
int printf (const char *, ...);
int a[6];
int b, c, d, e;
int f[10] = { 0, 0, 0, 0, 0, 1075L };
int *g = f[5];
char h;
unsigned i;
void
fn1 (int p1)
{
b = a[p1];
}
int
main ()
{
for (; e 6; e++)
a[e] = e;
i = -14;
for (; i = 8; i++)
{
d = --c;
h = d * 100L;
if (h);
else
{
*g = 0;
break;
}
}
fn1 (f[5] 8 15);
printf (%d\n, b);
return 0;
}
[Bug c++/57342] [C++11] Warning for narrowing conversion has ugly formatting for floating point number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57342
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
GCC should not try to pretty print input expressions, but it should try hard to
point to the correct location.
Clang by comparison:
test.cc:2:10: error: type 'double' cannot be narrowed to 'int' in initializer
list [-Wc++11-narrowing]
int pi{3.14};
^~~~
test.cc:2:10: note: override this message by inserting an explicit cast
int pi{3.14};
^~~~
static_castint( )
test.cc:2:10: warning: implicit conversion from 'double' to 'int' changes value
from 3.14 to 3 [-Wliteral-conversion]
int pi{3.14};
~^~~~
1 warning and 1 error generated.
There is already a bug open about this issue somewhere.
[Bug c++/57016] [4.9 Regression] [C++0x] ICE: unexpected expression '__is_final(hashint)' of kind trait_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57016 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/57102] [4.9 Regression] ICE: SIGSEGV in fndecl_declared_return_type with -fdump-final-insns=...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57102 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug target/57344] New: wrong code with pragma pack(1) and -O1 on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57344
Bug ID: 57344
Summary: wrong code with pragma pack(1) and -O1 on x86
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code produces wrong output on x86_64-linux-gnu in 32-bit mode,
when compiled at -O1 or higher optimizations. It appears that the behavior
changed between gcc 4.6 which works at all optimization levels, and 4.7 which
does not.
$ gcc-trunk -v
gcc version 4.9.0 20130520 (experimental) [trunk revision 199099] (GCC)
$ gcc-trunk -O0 -m32 wrong.c
$ ./a.out
-3161
$ gcc-trunk -O1 -m64 wrong.c
$ ./a.out
-3161
$ gcc-4.6 -O1 -m32 wrong.c
$ ./a.out
-3161
$ gcc-trunk -O1 -m32 wrong.c
$ ./a.out
2093991
$
--
int printf(const char *, ...);
#pragma pack(1)
struct S0
{
int f0:11;
int f1:22;
char f2;
int:0;
}
s[2];
int i;
int
main ()
{
struct S0 tmp = { 0, -3161L };
s[1] = tmp;
for (; i 1; i++)
printf (%d\n, s[1].f1);
return 0;
}
[Bug c/57345] New: Preprocessor fails to evaluation string token not valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57345
Bug ID: 57345
Summary: Preprocessor fails to evaluation string token not
valid
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: signupnathan at gmail dot com
This error
23L03.c: In function ‘main’:
23L03.c:16:10: error: token I know the C language.\n is not valid in
preprocessor expressions
23L03.c:20:10: error: token I know BASIC.\n is not valid in preprocessor
expressions
Is generated by the following code that compliles fine with clang. Code comes
from a book teaching about C in a preprocessor chapter.
#include stdio.h
#define C_LANG'C'
#define B_LANG'B'
#define NO_ERROR 0
int main(void)
{
#if C_LANG == 'C' B_LANG == 'B'
#undef C_LANG
#define C_LANG I know the C language.\n
#undef B_LANG
#define B_LANG I know BASIC.\n
printf(%s%s, C_LANG, B_LANG);
#elif C_LANG == 'C'
#undef C_LANG
#define C_LANG I only know C language.\n
printf(%s, C_LANG);
#elif B_LANG == 'B'
#undef B_LANG
#define B_LANG I only know BASIC.\n
printf(%s, B_LANG);
#else
printf(I don't know C or BASIC.\n);
#endif
return NO_ERROR;
}
The preprocessor balks at this type of statement:
#if foo == foo
printf(foo matches);
#endif
[Bug c/57345] Preprocessor fails to evaluation string token not valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57345 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I think GCC is correct as it is processing the macros after they have been redefined even though they are using #elif.
[Bug c/57345] Preprocessor fails to evaluation string token not valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57345 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Dup.
[Bug c/57345] Preprocessor fails to evaluation string token not valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57345 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Dup of PR38161 I mean. *** This bug has been marked as a duplicate of bug 38161 ***
[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||signupnathan at gmail dot com --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- *** Bug 57345 has been marked as a duplicate of this bug. ***
[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161 Harald van Dijk harald at gigawatt dot nl changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #6 from Harald van Dijk harald at gigawatt dot nl --- Given that the standard apparently unintentionally requires this behaviour, and the standard will likely be changed to require FOO to not be evaluated (see http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_412.htm), perhaps the pre-4.4 behaviour should be restored, or at least the diagnostics downgraded to a warning?
[Bug c/57345] Preprocessor fails to evaluation string token not valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57345
signupnathan at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |---
--- Comment #4 from signupnathan at gmail dot com ---
First, in this example, the first #if evaluates true, so I wouldn't think it
should even go on to evaluate the #endif and #else.
Secondly, this code fails as well:
#include stdio.h
int main (){
#if foo == foo
printf(foo matches);
#endif
return 0;
}
with this error:
/tmp/foo.c: In function ‘main’:
/tmp/foo.c:4:9: error: token foo is not valid in preprocessor expressions
It doesn't seem to be to be a duplicate as they were evaluating numericals.
This is evaluating strings.
[Bug c++/57346] New: g++ prematurely rejects references to local variables that are not odr-uses from local classes inside templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57346
Bug ID: 57346
Summary: g++ prematurely rejects references to local variables
that are not odr-uses from local classes inside
templates
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
g++ has a rejects-valid on this:
templatetypename T int f() {
T n = 0;
struct X { int get() { return n; } } x;
return x.get();
}
This template definition is valid: instantiation should succeed with T=const
int, for instance.
[Bug preprocessor/36453] [DR 412] PR36320 breaks boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- Summary|PR36320 breaks boost|[DR 412] PR36320 breaks ||boost --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org --- Reopening to ...
[Bug preprocessor/36320] Required diagnosis of syntax error missed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320 Bug 36320 depends on bug 36453, which changed state. Bug 36453 Summary: [DR 412] PR36320 breaks boost http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |---
[Bug preprocessor/36453] [DR 412] PR36320 breaks boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|SUSPENDED --- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org --- Suspend based on the defect report.
[Bug c/57345] Preprocessor fails to evaluation string token not valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57345 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to signupnathan from comment #4) It doesn't seem to be to be a duplicate as they were evaluating numericals. This is evaluating strings. Evaluating strings is not a valid thing for the preprocessor. *** This bug has been marked as a duplicate of bug 38161 ***
[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 57345 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/57343] wrong code on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Component|rtl-optimization|tree-optimization
--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
Reduced a bit:
int printf (const char *, ...);
int c = 0;
int main ()
{
int i;
int f = 1;
for (i = 0; i 5; i++)
{
--c;
unsigned char h = c * 100;
if (h == 0)
{
f = 0;
break;
}
}
printf (%d\n, f);
return 0;
}
-O1 is enough. Disabling cunroll seems to help.
[Bug target/57339] [SH] Wrong ISR FPU register save/restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57339 --- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #0) One idea for now would be to emit fixed ISR prologue / epilogue asm blocks that deal with the FP regs, if FP regs need to be saved/restored for an ISR. This would be fine. I guess that the most important thing with compiler generated interrupt routine would be its correctness and robustness, not efficiency.
[Bug rtl-optimization/57347] New: wrong code for bitfield on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57347
Bug ID: 57347
Summary: wrong code for bitfield on x86_64-linux at -Os and
above
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled on x86_64-linux with gcc trunk and 4.8 at -Os
and above optimization level. It works correctly with gcc 4.7 (outputs 1).
$ gcc-trunk -v
gcc version 4.9.0 20130520 (experimental) [trunk revision 199099] (GCC)
$ gcc-trunk -O1 wrong.c
$ ./a.out
1
$ gcc-4.7 -Os wrong.c
$ ./a.out
1
$ gcc-trunk -Os wrong.c
$ ./a.out
0
$
-
int printf(const char *, ...);
struct S1 {
int f0;
int f1 : 10;
int f2 : 13;
};
int i;
int *j = i;
static void foo(struct S1 s) {
int *p;
int l[88];
int **pp = p;
*pp = l[1];
l[0] = 1;
*j = 1 s.f2;
}
int main(void) {
struct S1 s = { 0, 0, 1 };
foo(s);
printf(%d\n, i);
return 0;
}
[Bug c++/57043] [4.7/4.8/4.9 Regression] converting overloaded complex function pow in C++11 is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57043 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|converting overloaded |[4.7/4.8/4.9 Regression] |complex function pow in |converting overloaded |C++11 is ambiguous |complex function pow in ||C++11 is ambiguous --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Marking (tentatively) as regression, then.
[Bug c++/54891] [C++11] lambda-expression and explicit type conversion (cast notation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54891 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-21 Blocks||54367 Ever confirmed|0 |1
[Bug c++/57342] [C++11] Warning for narrowing conversion has ugly formatting for floating point number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57342 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-21 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Maybe Manuel means PR33067, where we made some progress in caret-less times. In the meanwhile those examples are fixed, we shall fix this one too, of course.
[Bug c++/57342] [C++11] Warning for narrowing conversion has ugly formatting for floating point number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57342 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Depends on||31158 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- The hard part is PR31158.
[Bug fortran/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #1 from Bud Davis bdavis at gcc dot gnu.org --- subroutine max_in_loop(rin, rout) integer :: rin(1000), rout(1000), tmp !real :: rin(1000), rout(1000), tmp integer :: i do i = 2, 1000 tmp = min(rin(i-1), rin(i)) rout(i) = tmp end do end subroutine Is vectorized. The floating point number makes it special in some way. Looking in trans-intrinic.c , it is special. /* FIXME: When the IEEE_ARITHMETIC module is implemented, the call to __builtin_isnan might be made dependent on that module being loaded, to help performance of programs that don't rely on IEEE semantics. */
[Bug rtl-optimization/57046] [4.8 Regression] wrong code generated by gcc 4.8.0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57046 Easwaran Raman eraman at google dot com changed: What|Removed |Added CC||eraman at google dot com --- Comment #8 from Easwaran Raman eraman at google dot com --- *** Bug 57088 has been marked as a duplicate of this bug. ***
