[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69038 Eric Botcazou changed: What|Removed |Added CC||davem at gcc dot gnu.org --- Comment #8 from Eric Botcazou --- > It's probably too late to implement this in reload though. So an incentive for the switch to LRA if one was needed.
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991 --- Comment #15 from Jakub Jelinek --- (In reply to H.J. Lu from comment #11) > (In reply to Jakub Jelinek from comment #10) > > But why should the *mov_internal use Bm or vector_operand? It > > can/should handle both aligned and unaligned memory operands. > > Only for historical reason. I thought Uros said: "Looking at the comment in Patch 3, I'd say let's keep *mov_internal constraints unchanged." IMNSHO you only want to touch patterns which don't have ssememalign attributes (== have it 0) and leave the others as is. Perhaps in the next step you can kill the UNSPEC_LOADU/UNSPEC_STOREU patterns and handle them in *mov_internal too - the unspecs were there just to make sure they aren't combined into SSE arithmetic instructions.
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991 --- Comment #16 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #15) > (In reply to H.J. Lu from comment #11) > > (In reply to Jakub Jelinek from comment #10) > > > But why should the *mov_internal use Bm or vector_operand? It > > > can/should handle both aligned and unaligned memory operands. > > > > Only for historical reason. > > I thought Uros said: > "Looking at the comment in Patch 3, I'd say let's keep *mov_internal > constraints unchanged." > IMNSHO you only want to touch patterns which don't have ssememalign > attributes (== have it 0) and leave the others as is. Perhaps in the next > step you can kill the UNSPEC_LOADU/UNSPEC_STOREU patterns and handle them in > *mov_internal too - the unspecs were there just to make sure they > aren't combined into SSE arithmetic instructions. Yes, there is no need to change *mov_internal constraints.
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991 --- Comment #17 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #15) > IMNSHO you only want to touch patterns which don't have ssememalign > attributes (== have it 0) and leave the others as is. Perhaps in the next > step you can kill the UNSPEC_LOADU/UNSPEC_STOREU patterns and handle them in > *mov_internal too - the unspecs were there just to make sure they > aren't combined into SSE arithmetic instructions. I agree with the above. In the patch, please include minimum changes needed to solve the problem, we will do more radical changes after gcc-6 is released. IOW, ssememalign should stay in gcc-6.
[Bug c/69122] -Wmisleading-indentation false positive with empty macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69122 David Malcolm changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #2 from David Malcolm --- Candidate patch posted as: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00126.html
[Bug tree-optimization/69141] [6 Regression] -O2 -fdump-tree-fre ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69141 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-05 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 37223 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37223&action=edit gcc6-pr69141.patch Untested fix.
[Bug ipa/66223] [5/6 Regression] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- The advantage of __builtin_unreachable () is that it allows better optimizations, at the expense of the invalid code not being so nicely reported. With -fsanitize=undefined you get the undefined behavior reported, but with information loss - it is reported as a call to __builtin_unreachable rather than call to pure virtual method. Perhaps as a compromise we could make sure __cxa_pure_virtual is called in this case when -fsanitize=undefined (say in particular with -fsanitize=unreachable) and let it be optimized to __builtin_unreachable otherwise?
[Bug jit/69144] New: running the libgccjit tests leaves temporary files /tmp/libgccjit-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69144 Bug ID: 69144 Summary: running the libgccjit tests leaves temporary files /tmp/libgccjit-* Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- running the libgccjit tests leaves temporary files /tmp/libgccjit-* these should be cleaned.
[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/69145] New: [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69145 Bug ID: 69145 Summary: [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included' Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 37224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37224&action=edit Patch used to show the "note" line Since a while, I get seemingly bogus warnings of the form: file.cc:38:24: warning: #pragma implementation for ‘header.h’ appears after file is included The warning is generated in gcc/cp/lex.c's handle_pragma_implementation and calls cpp_included_before, which contains: while (entry && (entry->start_dir == NULL || entry->u.file->err_no || entry->location > location)) entry = entry->next; I modified the code to print a "note" with the entry->location after the warning call. Example: TDICmds.cc:7:24: warning: #pragma implementation for ‘create_defect_script_SCDBase.cc’ appears after file is included #pragma implementation "create_defect_script_SCDBase.cc" ^ In file included from TDICmds.cc:33:0: ./create_defect_script_SCDBase.cc:1:0: note: File was included here #include "create_defect_script_SCDBase.h" I will now try to create a small example and to find the commit, which caused the regression.
[Bug tree-optimization/67781] [5/6 Regression] wrong code generated on big-endian with -O1 -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781 --- Comment #12 from Mikael Pettersson --- Thanks for posting the patch, I'm currently doing a sparc64-linux bootstrap and regtest with it.
[Bug target/69030] [6 Regression] ICE on x86_64-linux-gnu at -O2 and above in 32-bit mode (ICE in copy_rtx, at rtl.c:358)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69030
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Note, I need also -march=x86-64 to reproduce.
Seems in remove_pseudos for pseudo 93 we don't have pseudo_slots initialized.
This pseudo is initialized in bb3, then used there and the last use in that bb
is in a debug_insn, this bb then conditionally jumps to another bb where there
is
(insn 121 140 42 6 (set (reg/v:SI 93 [ h ])
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 93 [ h ])
(reg:SI 135))) pr69030.c:12 969 {*movsicc_noc}
(expr_list:REG_DEAD (reg:SI 135)
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_UNUSED (reg/v:SI 93 [ h ])
(expr_list:REG_EQUAL (if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 93 [ h ])
(const_int 0 [0]))
(nil))
followed by a debug_insn that uses the SI 93 pseudo, but nothing else
afterwards uses it. And it seems (at least from *.reload dump without -g) that
LRA decides to remove the dead insn, thus shortening the live range of the
pseudo 93, but doesn't adjust the debug insns mentioning it, thus the pseudo 93
doesn't live in a register nor in memory.
[Bug target/69135] [5/6 Regression][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||arm* Status|NEW |ASSIGNED CC||ktkachov at gcc dot gnu.org Known to work||4.9.4 Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Target Milestone|--- |5.4 Summary|[5/6][ARM] instruction |[5/6 Regression][ARM] |cannot be conditional --|instruction cannot be |`vcvtpne.s32.f32 s0,s0' |conditional -- ||`vcvtpne.s32.f32 s0,s0' Known to fail||5.3.1, 6.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed, mine.
[Bug c++/69145] [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69145 --- Comment #1 from Tobias Burnus --- Test case (seems as if the file name of the included file matters): $ g++ TDICmds.cc TDICmds.cc:1:24: warning: #pragma implementation for ‘create_defect_script_SCDBase.cc’ appears after file is included #pragma implementation "create_defect_script_SCDBase.cc" ^ In file included from TDICmds.cc:2:0: create_defect_script_SCDBase.cc:1:0: note: File was included here #include "create_defect_script_SCDBase.h" ==> create_defect_script_SCDBase.cc <== #include "create_defect_script_SCDBase.h" ==> create_defect_script_SCDBase.h <== #ifndef create_defect_script_SCDBase_H # define create_defect_script_SCDBase_H #endif ==> TDICmds.cc <== #pragma implementation "create_defect_script_SCDBase.cc" #include "create_defect_script_SCDBase.cc"
[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012 --- Comment #13 from Bernd Edlinger --- (In reply to Bernd Edlinger from comment #12) > > glibc-config: > ../glibc-2.22/configure --prefix=/home/ed/gnu/mips-linux-gnu/mips-linux-gnu > --build=mips-linux-gnu --disable-werror CC=mips-linux-gnu-gcc > correction, the glibc-config was actually wrong: ../glibc-2.22/configure --prefix=/home/ed/gnu/mips-linux-gnu/mips-linux-gnu --host=mips-linux-gnu --disable-werror then I can build a full cross gcc: ../gcc-trunk/configure --prefix=/home/ed/gnu/mips-linux-gnu --target=mips-linux-gnu --enable-languages=c,c++,fortran,ada and then finally canadian cross: ../gcc-trunk/configure --prefix=/home/ed/gnu/mips-linux-gnu --target=mips-linux-gnu --enable-languages=c,c++,fortran,ada --host=mips-linux-gnu (which fails currently in an in-tree mpfr issue: pr69134
[Bug target/69030] [6 Regression] ICE on x86_64-linux-gnu at -O2 and above in 32-bit mode (ICE in copy_rtx, at rtl.c:358)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69030 --- Comment #3 from Jakub Jelinek --- Note, before *.ira the pseudo 93 set by the movsicc is actually used by another insn, but that is removed early in the ira pass during delete_trivially_dead_insns. But for some reason the if_then_else is not removed as trivially dead, and even if it would, nothing recomputes the lr problem (or is that live) that would adjust or reset the debug insns that are refering the pseudos that are not live anymore.
[Bug target/69135] [5/6 Regression][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to Richard Earnshaw from comment #1) > Confirmed based on inspection. > > The patch suggested is not correct, since vcvtr can be conditional and it > shares the same basic pattern. In the lsi2 pattern we use the VCVT iterator which iterates over [UNSPEC_VRINTP UNSPEC_VRINTM UNSPEC_VRINTA] all of which cannot be conditional. UNSPEC_VRINTR is handled by the vrint_variant int attribute, but it's not utilised in this pattern because the VCVT iterator doesn't include UNSPEC_VRINTR So I think the proposed patch is correct, but would need to be sent to gcc-patches with a the testcase properly added to the testsuite.
[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 --- Comment #7 from Nick Clifton --- Author: nickc Date: Tue Jan 5 10:57:01 2016 New Revision: 232071 URL: https://gcc.gnu.org/viewcvs?rev=232071&root=gcc&view=rev Log: PR target/66655 * config/i386/cygming.h (MAKE_DECL_ONE_ONLY): Define to use weak decls if weak support is available. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h
[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #11 from vehre at gcc dot gnu.org --- No complaints so far, closing.
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 Bug 67779 depends on bug 69011, which changed state. Bug 69011 Summary: [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/69060] Invalid 'cannot bind lvalue to rvalue' error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69060
--- Comment #2 from Jonathan Wakely ---
(In reply to Sławomir from comment #1)
> The same with version 4.9.4 20150813 (prerelease)
No, the error for your (incomplete, and so not very useful) example is not the
same at all.
> Error:
> CXX diag/bin/fsmf_test/collector_handler.o
> src/log_collecting/collector_handler.cpp: In member function ‘void
> diag::collector_handler::add_file_to_dl_list(const string&, bool)’:
> src/log_collecting/collector_handler.cpp:274:47: error: cannot bind ‘bool’
> lvalue to ‘bool&&’
> observers_list->notify_observers(uri, is_last);
>^
This error is correct, because 'is_last' is an lvalue, but ...
> In file included from ../diag/src/log_collecting/diag_object.h:8:0,
> from src/log_collecting/collector_handler.h:11,
> from src/log_collecting/collector_handler.cpp:13:
> ../diag/src/log_collecting/observers_container.h:52:15: note: initializing
> argument 2 of ‘void
> diag::observers_container::
> notify_observers(callback_args_types&& ...) [with callback_args_types =
> {boost::optional,
> std::allocator > >, bool}]’
> virtual void notify_observers(callback_args_types&&... args) {
This function only accepts rvalues.
[Bug c++/69060] Invalid 'cannot bind lvalue to rvalue' error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69060 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- The original report is valid though.
[Bug libstdc++/69116] [4.9/5/6 Regression] compile error when including valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69116 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 Known to work||4.7.3 Summary|compile error when |[4.9/5/6 Regression] |including valarray |compile error when ||including valarray Ever confirmed|0 |1
[Bug libstdc++/69114] A couple allocator-related helpers should use __addressof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69114 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-05 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/69105] front_/back_/insert_iterator should use addressof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69105 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-05 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69106 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-05 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #24 from Jonathan Wakely --- (In reply to Martin Sebor from comment #23) > What doesn't work correctly is including in the test case and > compiling it in C++ 98 mode. The test case below shows there's still no > warning there. This is because Jonathan's patch left false defined as a > macro in C++ 98 for compatibility, and the system header preprocessor bug > still hasn't been fixed. I'm still not convinced keeping the "GNU extension" (or historical baggage, depending on your point of view) in C++98 for hypothetical compatibility is useful.
[Bug c++/69016] In C++14 standard, function with auto as return and arguments returns result with the datatype of first argument only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69016 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- Yes, dup, and unlikely to be fixable in older releases. *** This bug has been marked as a duplicate of bug 64969 ***
[Bug c++/64969] generic functions do not work with placeholder return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969 Jonathan Wakely changed: What|Removed |Added CC||emailstorbala at gmail dot com --- Comment #7 from Jonathan Wakely --- *** Bug 69016 has been marked as a duplicate of this bug. ***
[Bug testsuite/68232] gcc.dg/ifcvt-4.c fails on some arm configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68232 James Greenhalgh changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from James Greenhalgh --- "Fixed" with the testsuite skips. Feel free to add any other target triplets for which this test is unreliable.
[Bug c++/69145] [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69145 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 CC||jakub at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1
[Bug c++/69145] [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69145 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 37225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37225&action=edit gcc6-pr69145.patch Untested fix.
[Bug target/69053] [6 Regression] ICE in build_vector_from_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69053 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 CC||alahay01 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from alalaw01 at gcc dot gnu.org --- Yes. The r230423 change means x86 now has a reduc_umax_scal_optab for V4DI, causing the loop to be vectorized as a COND_REDUCTION. (It is not vectorized on e.g. AArch64, as that platform has reduc_umax_scal_optabs only for vector modes with smaller elements, not V2DI).
[Bug target/69053] [6 Regression] ICE in build_vector_from_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69053 --- Comment #2 from alalaw01 at gcc dot gnu.org --- build_vector_from_val then gets called to build a vector (4) unsigned long, from an int* (which is the right signedness and size, but being a pointer it is not types_compatible_p).
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2016-01-03 00:00:00 |2016-01-05 Ever confirmed|0 |1 --- Comment #3 from H.J. Lu --- tree-vect-slp.o is miscompiled. When I replaced tree-vect-slp.o from r231672 build, cc1plus finished.
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 H.J. Lu changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #4 from H.J. Lu --- r231674 may have exposed a latent bug in var-tracking.c since the same file compiles without -g.
[Bug target/69146] New: [5 Regression] ICE in extract_insn, at recog.c:2343 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69146
Bug ID: 69146
Summary: [5 Regression] ICE in extract_insn, at recog.c:2343 on
powerpc64le-linux-gnu
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen building the kumofs package with the gcc-5 branch 20160101:
reduced test case:
class A {
bool m_fn1();
short m_role;
};
char a;
bool A::m_fn1() { __sync_bool_compare_and_swap(&m_role, -1, a); }
$ g++ -c -g -O2 cluster.ii
cluster.ii: In member function 'bool A::m_fn1()':
cluster.ii:6:65: error: unrecognizable insn:
bool A::m_fn1() { __sync_bool_compare_and_swap(&m_role, -1, a); }
^
(insn 11 10 12 4 (set (reg:CC 166)
(compare:CC (reg:SI 165)
(const_int 65535 [0x]))) cluster.ii:6 -1
(nil))
cluster.ii:6:65: internal compiler error: in extract_insn, at recog.c:2343
0x102c0103 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:110
0x102c014f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:118
0x109a5bfb extract_insn(rtx_insn*)
../../src/gcc/recog.c:2343
0x10832e7f instantiate_virtual_regs_in_insn
../../src/gcc/function.c:1598
0x10832e7f instantiate_virtual_regs
../../src/gcc/function.c:1966
0x10832e7f execute
../../src/gcc/function.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug sanitizer/69147] New: [5 Regression] Several hundred asan failures with 5.3.1 on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69147 Bug ID: 69147 Summary: [5 Regression] Several hundred asan failures with 5.3.1 on x86_64-apple-darwin15 Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- On x86_64-apple-darwin15 (Xcode 7.2) I get several hundred asan failures with 5.3.1. They are of the kind ==16114==AddressSanitizer CHECK failed: ../../../../../5_work/libsanitizer/asan/asan_malloc_mac.cc:103 "((!asan_init_is_running)) != (0)" (0x0, 0x0) They appeared between revisions r231560 (x86_64-apple-darwin14, only strncpy-overflow-1.c fails) and r231847 (x86_64-apple-darwin15, 820 failures). I don't see them on trunk (6.0).
[Bug target/69148] New: [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
Bug ID: 69148
Summary: [5/6 Regression] ICE (floating point exception) on
s390x-linux-gnu
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen building the mame package on s390x with gcc-5-branch 20160101
In file included from src/emu/cpu/sharc/sharc.c:227:0:
src/emu/cpu/sharc/sharcops.inc: In member function 'void
adsp21062_device::COMPUTE(UINT32)':
src/emu/cpu/sharc/sharcops.inc:1066:1: internal compiler error: Floating point
exception
}
^
Compiling src/emu/cpu/dsp32/dsp32.c...
0x802bb761 crash_signal
../../src/gcc/toplev.c:383
0x8067dfa6 validate_subreg(machine_mode, machine_mode, rtx_def const*, unsigned
int)
../../src/gcc/emit-rtl.c:904
0x8067e1d3 gen_rtx_SUBREG(machine_mode, rtx_def*, int)
../../src/gcc/emit-rtl.c:909
0x80229a8f emit_spill_move
../../src/gcc/lra-constraints.c:1054
0x8080a811 curr_insn_transform
../../src/gcc/lra-constraints.c:3561
0x808067ed lra_constraints(bool)
../../src/gcc/lra-constraints.c:4446
0x807ef89b lra(_IO_FILE*)
../../src/gcc/lra.c:2344
0x8079831d do_reload
../../src/gcc/ira.c:5421
0x8079831d execute
../../src/gcc/ira.c:5592
Please submit a full bug report,
with preprocessed source if appropriate.
reduced with a cross compiler
typedef int UINT32;
union SHARC_REG {
int r;
float f;
};
class adsp21062_device {
SHARC_REG m_r[];
double fabs(double);
UINT32 m_astat;
void compute_fclip(int, int, int);
};
void adsp21062_device::compute_fclip(int, int, int ry) {
SHARC_REG r_alu;
r_alu.f = fabs(m_r[ry].f);
m_astat = r_alu.r ? 4 : r_alu.r;
}
$ s390x-linux-gnu-g++ -c -O sharc.i
sharc.i: In member function 'void adsp21062_device::compute_fclip(int, int,
int)':
sharc.i:16:1: internal compiler error: Floating point exception
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 --- Comment #7 from Nick Clifton --- Author: nickc Date: Tue Jan 5 13:20:29 2016 New Revision: 232072 URL: https://gcc.gnu.org/viewcvs?rev=232072&root=gcc&view=rev Log: PR target/68770 * ira-costs.c (copy_cost): Initialise the t_icode field of the secondary_reload_info structure. tests: * g++.dg/pr68770.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr68770.C Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 --- Comment #5 from H.J. Lu --- Created attachment 37226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37226&action=edit A testcase ./xgcc -B./ -S -O3 -g /tmp/x.ii -fno-rtti -fno-exceptions never finishes.
[Bug fortran/62536] ICE (segfault) for invalid END BLOCK statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62536 vehre at gcc dot gnu.org changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #8 from vehre at gcc dot gnu.org --- ICE confirmed. You need to provide a main program to compilation unit and not compile with -c, i.e., $ cat test_pr62536.f90 function f2 (x) implicit none integer f2, x block block named integer a ! should be SAVEd a = a + x ! should increment by y every time f2 = a end block named end block return endfunction end $ ./gfortran.sh -g test_pr62536.f90 -o test_pr62536 Fortraning using ***DEVelopment*** version... test_pr62536.f90:5:3: block named 1 Error: Unclassifiable statement at (1) test_pr62536.f90:9:18: end block named 1 Error: Syntax error in END BLOCK statement at (1) test_pr62536.f90:10:5: end block 1 Error: Expecting END FUNCTION statement at (1) f951: internal compiler error: Segmentation fault 0xe3e374 crash_signal .../gcc/gcc/toplev.c:334 0x7d1efd gfc_resolve(gfc_namespace*) .../gcc/gcc/fortran/resolve.c:15543
[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67973 --- Comment #15 from Dominique d'Humieres --- Could the fix be back ported to the gcc5 branch?
[Bug c/69104] invalid atomic memory order not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69104 Marek Polacek changed: What|Removed |Added Keywords|accepts-invalid |diagnostic --- Comment #7 from Marek Polacek --- I'll post a patch for 1).
[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67973 --- Comment #16 from Iain Sandoe --- Created attachment 37227 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37227&action=edit back-port of Rainer's fix. I've been using this on my GCC5.3 WIP (it might be a reasonable starting point, don't know if it'll apply cleanly to 5.3.1)
[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583 --- Comment #9 from Nathan Sidwell --- Author: nathan Date: Tue Jan 5 14:40:11 2016 New Revision: 232075 URL: https://gcc.gnu.org/viewcvs?rev=232075&root=gcc&view=rev Log: gcc/cp/ PR c++/58583 * pt.c (build_non_dependent_expr): Don't try a checking fold when parsing an nsdmi. gcc/testsuite/ PR c++/58583 * g++.dg/cpp0x/nsdmi-template14.C: Adjust test & errors. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template14.C
[Bug target/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 Matthias Klose changed: What|Removed |Added Keywords||wrong-code CC||doko at gcc dot gnu.org, ||ramana at gcc dot gnu.org Known to work||4.9.3 Host|arm-linux-gnueabihf | Summary|arm miss compiled code |[5/6 Regression] wrong code |since gcc 5 |in thumb mode on ||arm-linux-gnueabihf Known to fail||5.3.1, 6.0 Build|arm-linux-gnueabihf | --- Comment #6 from Matthias Klose --- $ gcc -g -O2 -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb fp_mul_comba_32.c && ./a.out 27 0x0a7d8ff8 != 0xce804437 28 0x1c8a1f70 != 0x1c8a1f6f -> 3 works with -marm.
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 58583, which changed state. Bug 58583 Summary: [c++11] ICE with invalid non-static data member initialization in template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I bet vt_find_location must be oscillating for some reason and thus not converging. This is on the get_address_cost routine. Alex, do you think you could have a look? Thanks.
[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583 Nathan Sidwell changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Nathan Sidwell --- Patch tested with both checking & release builds. Applied.
[Bug target/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 --- Comment #7 from Matthias Klose --- > Debian is known to heavily modify their GCC sources. While Debian applies patches, these are almost all not code-modifying patches, just the release plus updates from the release branches.
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 H.J. Lu changed: What|Removed |Added Attachment #37226|0 |1 is obsolete|| --- Comment #7 from H.J. Lu --- Created attachment 37228 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37228&action=edit A smaller testcase
[Bug c++/69145] [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69145 --- Comment #4 from Jakub Jelinek --- (In reply to David Malcolm from comment #3) > (In reply to Tobias Burnus from comment #1) > > Test case (seems as if the file name of the included file matters): > > It may be that the threshold for triggering the bug is length of token >= > 32: libcpp uses location_t to store range information for tokens and > expressions, and uses 5 bits of location_t to store short ranges. i.e. for > tokens of up to 31 chars length, it can store them directly in location_t; > for 32 and above it needs to use an ad-hoc location. Yes, one char shorter filename works fine. > > $ g++ TDICmds.cc > > > > TDICmds.cc:1:24: warning: #pragma implementation for > > ‘create_defect_script_SCDBase.cc’ appears after file is included > > #pragma implementation "create_defect_script_SCDBase.cc" > > ^ > > FWIW, this token is 32 chars long (including the quotes), and so would have > its location stored as an ad-hoc location. Indeed, see the patch I've attached.
[Bug c/68612] Const-compatibility in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68612 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Marek Polacek --- Confirmed as per Comment 5.
[Bug c++/69145] [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69145 --- Comment #3 from David Malcolm --- (In reply to Tobias Burnus from comment #1) > Test case (seems as if the file name of the included file matters): It may be that the threshold for triggering the bug is length of token >= 32: libcpp uses location_t to store range information for tokens and expressions, and uses 5 bits of location_t to store short ranges. i.e. for tokens of up to 31 chars length, it can store them directly in location_t; for 32 and above it needs to use an ad-hoc location. > $ g++ TDICmds.cc > > TDICmds.cc:1:24: warning: #pragma implementation for > ‘create_defect_script_SCDBase.cc’ appears after file is included > #pragma implementation "create_defect_script_SCDBase.cc" > ^ FWIW, this token is 32 chars long (including the quotes), and so would have its location stored as an ad-hoc location.
[Bug c/68960] __attribute__ ((aligned ())) is ignored for OpenMP private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68960 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Severity|major |normal --- Comment #1 from Marek Polacek --- GCC 4.8 is no longer supported. Please try some supported version.
[Bug target/69146] [5 Regression] ICE in extract_insn, at recog.c:2343 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69146 --- Comment #1 from Bill Schmidt --- Please provide cluster.ii as an attachment. Thanks...
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
This doesn't even compile on the trunk:
pr69148.C:7:17: error: flexible array member ‘adsp21062_device::m_r’ not at end
of ‘class adsp21062_device’
SHARC_REG m_r[];
^
pr69148.C:6:7: note: in the definition of ‘class adsp21062_device’
class adsp21062_device {
^~~~
If I move m_r declaration to the end, then it compiles fine.
[Bug target/69146] [5 Regression] ICE in extract_insn, at recog.c:2343 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69146 --- Comment #2 from Bill Schmidt --- Oh, sorry, you provided it inline. Need my coffee this morning.
[Bug c++/69113] [6 Regression] ICE: in vague_linkage_p, at cp/decl2.c:1875 with -fno-weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69113 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with commit 8b2942f7c961ee83bb0ff605129165ecdf6ac8f6 Author: jason Date: Wed Apr 15 21:17:21 2015 + * decl.c (grokmethod): Only set DECL_COMDAT if TREE_PUBLIC is set. * method.c (implicitly_declare_fn): Likewise. * decl2.c (vague_linkage_p): Check TREE_PUBLIC first. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222134 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/69149] New: Segmentation fault during compile of libre office with debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69149 Bug ID: 69149 Summary: Segmentation fault during compile of libre office with debug Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hauf.johannes at gmail dot com Target Milestone: --- Command line: S=/home/johannes/core && I=$S/instdir && W=$S/workdir && mkdir -p $W/CxxObject/sw/source/uibase/app/ $W/Dep/CxxObject/sw/source/uibase/app/ && cd /home/johannes/core && g++ -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DINTEL -DLINUX -DOSL_DEBUG_LEVEL=1 -DSAL_LOG_INFO -DSAL_LOG_WARN -DUNIX -DUNX -DX86 -D_PTHREADS -D_REENTRANT -DSW_DLLIMPLEMENTATION -DSWUI_DLL_NAME=\"libswuilo.so\" -DSYSTEM_LIBXML -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wno-missing-braces -Wnon-virtual-dtor -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -pipe -fvisibility-inlines-hidden -fstack-protector-strong -fPIC -Wshadow -Woverloaded-virtual -std=gnu++14 -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -O0 -fstrict-aliasing -fstrict-overflow -ggdb2 -finline-limit=0 -fno-inline -fno-default-inline -DLIBO_INTERNAL_ONLY -c $S/sw/source/uibase/app/apphdl.cxx -o $W/CxxObject/sw/source/uibase/app/apphdl.o -MMD -MT $W/CxxObject/sw/source/uibase/app/apphdl.o -MP -MF $W/Dep/CxxObject/sw/source/uibase/app/apphdl.d_ -I$S/sw/source/uibase/app/ -I$W/UnpackedTarball/icu/source -I$W/UnpackedTarball/icu/source/i18n -I$W/UnpackedTarball/icu/source/common -I$W/UnpackedTarball/boost -I$S/sw/source/core/inc -I$S/sw/source/filter/inc -I$S/sw/source/uibase/inc -I$S/sw/inc -I$W/SdiTarget/sw/sdi -I$S/include -I/usr/lib/jvm/java-7-openjdk-i386/include -I/usr/lib/jvm/java-7-openjdk-i386/include/linux -I$S/config_host -I$W/CustomTarget/officecfg/registry -I$W/CustomTarget/sw/generated -I$W/UnoApiHeadersTarget/udkapi/normal -I$W/UnoApiHeadersTarget/offapi/normal -isystem /usr/include/libxml2 -save-temps Output: g++: warning: -pipe ignored because -save-temps specified In file included from /home/johannes/core/sw/source/uibase/app/apphdl.cxx:117:0: /home/johannes/core/workdir/SdiTarget/sw/sdi/swslots.hxx:1870:87: in constexpr expansion of ‘operator|((SfxSlotMode)1, (SfxSlotMode)16)’ /home/johannes/core/workdir/SdiTarget/sw/sdi/swslots.hxx:1933:1: internal compiler error: Segmentation fault }; ^ 0x84579b6 crash_signal ../../src/gcc/toplev.c:383 0x8a87449 bool vec_safe_reserve(vec*&, unsigned int, bool) ../../src/gcc/vec.h:575 0x8a87449 tree_node** vec_safe_push(vec*&, tree_node* const&) ../../src/gcc/vec.h:669 0x8a87449 add_local_decl(function*, tree_node*) ../../src/gcc/function.c:6703 0x8be2b09 remap_decls ../../src/gcc/tree-inline.c:653 0x8e82282 remap_block ../../src/gcc/tree-inline.c:721 0x8be175e copy_bind_expr ../../src/gcc/tree-inline.c:794 0x8be175e copy_tree_body_r(tree_node**, int*, void*) ../../src/gcc/tree-inline.c:1128 0x8ce20ea walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*)) ../../src/gcc/tree.c:11092 0x8e8351c copy_tree_body ../../src/gcc/tree-inline.c:2966 0x8e8351c copy_fn(tree_node*, tree_node*&, tree_node*&) ../../src/gcc/tree-inline.c:6044 0x8980127 cxx_eval_call_expression ../../src/gcc/cp/constexpr.c:1387 0x897b848 cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:3161 0x897c4ba cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:3219 0x897ff24 cxx_bind_parameters_in_call ../../src/gcc/cp/constexpr.c:1115 0x897ff24 cxx_eval_call_expression ../../src/gcc/cp/constexpr.c:1305 0x897b848 cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:3161 0x897c4ba cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:3219 0x897ff24 cxx_bind_parameters_in_call ../../src/gcc/cp/constexpr.c:1115 0x897ff24 cxx_eval_call_expression ../../src/gcc/cp/constexpr.c:1305 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. gcc Version: gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/5/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.1-5ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-d
[Bug target/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from ktkachov at gcc dot gnu.org --- Confirmed as well. Would be nice to have a smaller testcase though, or a bisect to the offending commit so we can have a sane look at before/after codegen and compiler dumps
[Bug c++/69149] Segmentation fault during compile of libre office with debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69149 --- Comment #1 from Johannes Hauf --- Created attachment 37229 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37229&action=edit Compiler output Compressed compiler output
[Bug target/69150] New: undocumented dllimport/dllexport attributes in mcore backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69150 Bug ID: 69150 Summary: undocumented dllimport/dllexport attributes in mcore backend Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- I have been reviewing undocumented target-specific attributes for PR 1078, and spotted that the mcore backend defines "dllimport" and "dllexport" attributes that are missing documentation. Rather than document these, though I think they are obsolete, and should be removed. I think they were provided for the long-deleted mcore-*-pe* target, and are not useful for the remaining bare-metal mcore-elf target. Right?
[Bug c/68960] __attribute__ ((aligned ())) is ignored for OpenMP private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68960 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-05 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 37230 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37230&action=edit gcc6-pr68960.patch Untested fix.
[Bug c++/69149] Segmentation fault during compile of libre office with debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69149 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- ICEs on the trunk too. Reducing...
[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 --- Comment #7 from Justas L --- (In reply to Eric Botcazou from comment #5) > As expected, reverting the patch doesn't change anything on the 5 branch, so > I'd suggest either filling a bug report for 'git bisect' or double checking > its result next time. Sorry, I indeed made a mistake - r230176 makes compilation fail with a different error than the one I get with 5.3 release. However, after rerunning git bisect and manually checking these revisions I can confirm that: - r230165 is the last good revision in the 5 branch; - r230176 is the first one that fails, but with a different error (internal compiler error: in ix86_adjust_stack_and_probe, at config/i386/i386.c:11064); - r230247 is the first one that fails with the error in choose_baseaddr; - reverting r230176 from 5.3.0 release fixes the problem (i.e. both testcases pass and Wine compiles and runs correctly) Also, passing -v to the testcases shows that these additional options are included by default, presumably from some distro (Arch) configuration: -mtune=generic -march=x86-64 -fPIE -fstack-check=specific -fstack-protector-strong
[Bug c/69122] -Wmisleading-indentation false positive with empty macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69122 --- Comment #3 from David Malcolm --- Author: dmalcolm Date: Tue Jan 5 15:54:46 2016 New Revision: 232076 URL: https://gcc.gnu.org/viewcvs?rev=232076&root=gcc&view=rev Log: Fix PR c/69122 (-Wmisleading-indentation false positive with empty macros) gcc/c-family/ChangeLog: PR c/69122 * c-indentation.c (get_visual_column): Remove default argument. (should_warn_for_misleading_indentation): For the multiline case, update call to get_visual_column for next_stmt_exploc so that it captures the location of the first non-whitespace character in the relevant line. Don't issue warnings if there is non-whitespace before the next statement. gcc/testsuite/ChangeLog: PR c/69122 * c-c++-common/Wmisleading-indentation.c (pr69122): New function. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-indentation.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 Ever confirmed|0 |1 --- Comment #2 from Andreas Krebbel --- I can confirm this for GCC 5 branch compiling with -march=z196. It does not seem to get triggered with older -march levels. It also does work fine with -mno-lra. On S/390 we need a memory slot when copying 32 bit entities between FPRs and GPRs. So from a first glance it appears to be related to the handling of secondary memory needed in LRA.
[Bug c/69122] -Wmisleading-indentation false positive with empty macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69122 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed as of r232076.
[Bug c++/69113] [6 Regression] ICE: in vague_linkage_p, at cp/decl2.c:1875 with -fno-weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69113 --- Comment #2 from Marek Polacek --- Looks like this fixes it... diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c index 9a07e1e..a7212ca0 100644 --- a/gcc/cp/decl2.c +++ b/gcc/cp/decl2.c @@ -1820,7 +1820,8 @@ comdat_linkage (tree decl) } } - DECL_COMDAT (decl) = 1; + if (TREE_PUBLIC (decl)) +DECL_COMDAT (decl) = 1; } /* For win32 we also want to put explicit instantiations in
[Bug rtl-optimization/68651] [5/6 Regression][AArch64] Missing combination of shift-by-one with other arithmetic patterns with -mcpu=cortex-a53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68651 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.0 Resolution|--- |FIXED --- Comment #3 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug rtl-optimization/68651] [5/6 Regression][AArch64] Missing combination of shift-by-one with other arithmetic patterns with -mcpu=cortex-a53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68651 --- Comment #2 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Jan 5 16:06:06 2016 New Revision: 232077 URL: https://gcc.gnu.org/viewcvs?rev=232077&root=gcc&view=rev Log: [combine][v2] Canonicalise (r + r) to (r << 1) to aid recognition PR rtl-optimization/68651 * combine.c (combine_simplify_rtx): Canonicalize x + x into x << 1. * gcc.target/aarch64/pr68651_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr68651_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/69108] [6 Regression] ICE in gather_scalar_reductions with -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69108 vries at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Target Milestone|--- |6.0 Summary|ICE in |[6 Regression] ICE in |gather_scalar_reductions|gather_scalar_reductions |with|with |-ftree-parallelize-loops=2 |-ftree-parallelize-loops=2 --- Comment #1 from vries at gcc dot gnu.org --- Starts failing at r231162, but that looks like a trigger commit. The error occurs in double reduction handling code, so marking it 6 regression.
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
--- Comment #4 from Jakub Jelinek ---
And
union U { int r; float f; };
struct A {
int a;
union U b[64];
};
double foo (double);
void
bar (struct A *z, int x)
{
union U y;
y.f = foo (z->b[x].f);
z->a = y.r ? 4 : y.r;
}
too (to make it C rather than C++).
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |5.4
--- Comment #3 from Jakub Jelinek ---
Ah, ok, I can confirm
union U { int r; float f; };
struct A {
double foo (double);
void bar (int);
int a;
U b[64];
};
void
A::bar (int x)
{
U y;
y.f = foo (b[x].f);
a = y.r ? 4 : y.r;
}
ICEs with -O -march=z196 -m64 on the trunk as well.
[Bug ipa/66223] [5/6 Regression] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223 --- Comment #7 from Daniel Frey --- (In reply to Jakub Jelinek from comment #6) > The advantage of __builtin_unreachable () is that it allows better > optimizations, at the expense of the invalid code not being so nicely > reported. > With -fsanitize=undefined you get the undefined behavior reported, but with > information loss - it is reported as a call to __builtin_unreachable rather > than call to pure virtual method. > Perhaps as a compromise we could make sure __cxa_pure_virtual is called in > this case when -fsanitize=undefined (say in particular with > -fsanitize=unreachable) and let it be optimized to __builtin_unreachable > otherwise? I checked the Itanium ABI and I guess https://mentorembedded.github.io/cxx-abi/abi.html#pure-virtual is sufficiently loosely specified to allow __builtin_unreachable (or basically anything you like). Anyways, calling __builtin_unreachable did call the terminate-handler previously, it was able to print a backtrace and I even got a core dump. The current behavior makes it almost impossible to debug such a situation and I'm not sure why. No output, no hint, no core dump (when I registered my own terminate handler). Could this be fixed in some way?
[Bug target/69151] New: missing docs for H8/3000 monitor/OS_Task attributes and related breakage in -mexr/-mno-exr options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69151
Bug ID: 69151
Summary: missing docs for H8/3000 monitor/OS_Task attributes
and related breakage in -mexr/-mno-exr options
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
In reviewing the current state of PR1078, I found that there is no
documentation for the H8/3000 function attributes "monitor" and "OS_Task".
The "monitor" attribute is mentioned in invoke.texi, though:
@item -mexr
@opindex mexr
Extended registers are stored on stack before execution of function
with monitor attribute. Default option is @option{-mexr}.
This option is valid only for H8S targets.
@item -mno-exr
@opindex mno-exr
Extended registers are not stored on stack before execution of function
with monitor attribute. Default option is @option{-mno-exr}.
This option is valid only for H8S targets.
Besides needing markup fixes and copy-editing, this text is totally confusing:
*both* of these behaviors cannot be the default. Trying to figure this out
from the code, in "monitor_prologue" in h8300.md I see:
...
else if (TARGET_H8300S && TARGET_NEXR )
return
"mov.l\\ter0,@-er7\;stc\tccr,r0l\;mov.b\tr0l,@(4,er7)\;mov.l\\t@er7+,er0\;orc\t#128,ccr";
else if (TARGET_H8300S && TARGET_NEXR && TARGET_NORMAL_MODE)
return
"subs\\t#2,er7\;mov.l\\ter0,@-er7\;stc\tccr,r0l\;mov.b\tr0l,@(4,er7)\;mov.l\\t@er7+,er0\;orc\t#128,ccr";
...
The second clause is clearly dead code. I think there is a mistake in logic
here, and that a target expert needs to figure out what the intended behavior
is and correct both the implementation and documentation.
[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 --- Comment #8 from Nick Clifton --- Patch applied. (Unfortunately I cannot close this BZ...)
[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed.
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123
--- Comment #8 from H.J. Lu ---
A small testcase:
[hjl@gnu-mic-2 i386]$ cat /tmp/x.ii
struct xxx_def;
typedef xxx_def *xxx;
union rtxxx
{
const char *rt_str;
xxx rt_xxx;
};
struct xxx_def {
union u {
rtxxx fld[1];
} u;
};
extern xxx bar (void);
extern int foo1 (xxx);
static inline xxx
foo2 (xxx arg0, xxx arg1)
{
xxx rt;
rt = bar ();
(((rt)->u.fld[0]).rt_xxx) = arg0;
(((rt)->u.fld[1]).rt_xxx) = arg1;
return rt;
}
static inline xxx
foo4 (const char *arg0 )
{
xxx rt;
rt = bar ();
(((rt)->u.fld[0]).rt_str) = arg0;
(((rt)->u.fld[1]).rt_xxx) = (xxx) 0;
return rt;
}
extern xxx foo5 (long);
struct address_cost_data
{
unsigned costs[2][2][2][2];
};
void
get_address_cost (address_cost_data *data)
{
unsigned acost;
long i;
long rat, off = 0;
unsigned sym_p, var_p, off_p, rat_p;
xxx addr, base;
xxx reg0, reg1;
reg1 = bar ();
addr = foo2 (reg1, (xxx) 0);
rat = 1;
acost = 0;
reg0 = bar ();
reg1 = bar ();
for (i = 0; i < 16; i++)
{
sym_p = i & 1;
var_p = (i >> 1) & 1;
off_p = (i >> 2) & 1;
rat_p = (i >> 3) & 1;
addr = reg0;
if (rat_p)
addr = foo2 (addr, foo5 (rat)) ;
if (var_p)
addr = foo2 (addr, reg1);
if (sym_p)
base = foo4 ("");
else if (off_p)
base = foo5 (off);
else
base = (xxx) 0;
if (base)
addr = foo2 (addr, base);
acost = foo1 (addr);
data->costs[sym_p][var_p][off_p][rat_p] = acost;
}
}
[hjl@gnu-mic-2 i386]$ ./cc1plus -fpreprocessed /tmp/x.ii -quiet -dumpbase x.ii
-mtune=generic -march=x86-64 -auxbase x -g -O3 -version -fno-rtti
-fno-exceptions -o x.s
[Bug target/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #9 from ktkachov at gcc dot gnu.org --- So I did a bisection between 4.9 and 5. The offending commit is r217624: Author: vmakarov Date: Sun Nov 16 05:00:30 2014 + 2014-11-15 Vladimir Makarov * lra-remat.c (cand_transf_func): Process regno for rematerialization too. * lra.c (lra): Switch on rematerialization pass. i.e. when the LRA rematiralisation pass was turned on.
[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 --- Comment #8 from Eric Botcazou --- > Sorry, I indeed made a mistake - r230176 makes compilation fail with a > different error than the one I get with 5.3 release. However, after > rerunning git bisect and manually checking these revisions I can confirm > that: > > - r230165 is the last good revision in the 5 branch; > - r230176 is the first one that fails, but with a different error (internal > compiler error: in ix86_adjust_stack_and_probe, at config/i386/i386.c:11064); > - r230247 is the first one that fails with the error in choose_baseaddr; > - reverting r230176 from 5.3.0 release fixes the problem (i.e. both > testcases pass and Wine compiles and runs correctly) I see, then please always post the full set of options. r230176 & r230247 only free the frame pointer register for the register allocator with -fstack-check (this was done at the request of the Arch folks IIRC) so you can work around the failure by forcing it to be reserved again (-fno-omit-frame-pointer). I gather that this didn't work with 5.2, did it? If so, then the alignment stuff needs more work.
[Bug rtl-optimization/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 ktkachov at gcc dot gnu.org changed: What|Removed |Added Component|target |rtl-optimization --- Comment #10 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #9) > So I did a bisection between 4.9 and 5. > The offending commit is r217624: > Author: vmakarov > Date: Sun Nov 16 05:00:30 2014 + > > 2014-11-15 Vladimir Makarov > > * lra-remat.c (cand_transf_func): Process regno for > rematerialization too. > * lra.c (lra): Switch on rematerialization pass. > > i.e. when the LRA rematiralisation pass was turned on. Consequently, compiling with -fno-lra-remat the testcase runs successfully (no output)
[Bug target/69143] PowerPC64: aggregate results are badly handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69143
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-05
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||5.1.0, 6.0
--- Comment #1 from Martin Sebor ---
Confirmed. A slightly simpler (but equivalent) test case that generates the
same code is below. See also bug 65421.
typedef struct B { float x, y; } B;
B bar (B y) { return y; }
[Bug other/60465] [4.9/5/6 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #38 from Jeffrey A. Law --- Author: law Date: Tue Jan 5 17:57:05 2016 New Revision: 232080 URL: https://gcc.gnu.org/viewcvs?rev=232080&root=gcc&view=rev Log: [PATCH v2] ia64: don't use dynamic relocations for local symbols PR other/60465 * config/ia64/ia64.c (ia64_expand_load_address): Use gprel64 for local symbolic operands. * config/ia64/predicates.md (local_symbolic_operand64): New predicate. PR other/60465 * gcc.target/ia64/pr60465-gprel64.c: New test. * gcc.target/ia64/pr60465-gprel64-c37.c: New test. Added: trunk/gcc/testsuite/gcc.target/ia64/pr60465-gprel64-c37.c trunk/gcc/testsuite/gcc.target/ia64/pr60465-gprel64.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c trunk/gcc/config/ia64/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 Jeffrey A. Law changed: What|Removed |Added Summary|[4.9/5/6 Regression]|[4.9/5 Regression] |Compiling glibc-2.17,2.18 |Compiling glibc-2.17,2.18 |with gcc-4.8.2 and |with gcc-4.8.2 and |binutils-2.23.2,2.24|binutils-2.23.2,2.24 |results in segfaults in |results in segfaults in |_start /|_start / |elf_get_dynamic_info|elf_get_dynamic_info --- Comment #39 from Jeffrey A. Law --- Fixed on the trunk. Patch is backportable to the active release branches, but I'm not sure it's worth the effort.
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123
--- Comment #9 from H.J. Lu ---
(insn:TI 248 289 246 8 (set (reg:V2DI 21 xmm0 [130])
(mem/c:V2DI (plus:DI (reg/f:DI 7 sp)
(const_int 16 [0x10])) [9 %sfp+-32 S16 A128])) /tmp/x.ii:24
1215 {*movv2di_internal}
(nil))
...
(insn:TI 250 118 120 9 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 16 [0x10])) [9 %sfp+-32 S8 A128])
(reg/v/f:DI 0 ax [orig:120 base ] [120])) /tmp/x.ii:33 85
{*movdi_internal}
(nil))
seem to confuse canonicalize_values_star and lead to infinite loop.
[Bug rtl-optimization/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 --- Comment #11 from Mikael Pettersson --- (In reply to ktkachov from comment #9) > So I did a bisection between 4.9 and 5. > The offending commit is r217624: > Author: vmakarov > Date: Sun Nov 16 05:00:30 2014 + > > 2014-11-15 Vladimir Makarov > > * lra-remat.c (cand_transf_func): Process regno for > rematerialization too. > * lra.c (lra): Switch on rematerialization pass. > > i.e. when the LRA rematiralisation pass was turned on. Strange, my bisect identified r217588 as the culprit, although it also talks about lra materialization: 2014-11-14 Vladimir Makarov * lra-int.h (lra_create_live_ranges): Add parameter. * lra-lives.c (temp_bitmap): Move higher. (initiate_live_solver): Move temp_bitmap initialization into lra_live_ranges_init. (finish_live_solver): Move temp_bitmap clearing into live_ranges_finish. (process_bb_lives): Add parameter. Use it to control live info update and dead insn elimination. Pass it to mark_regno_live and mark_regno_dead. (lra_create_live_ranges): Add parameter. Pass it to process_bb_lives. (lra_live_ranges_init, lra_live_ranges_finish): See changes in initiate_live_solver and finish_live_solver. * lra-remat.c (do_remat): Process insn non-operand hard regs too. Use temp_bitmap to update avail_cands. * lra.c (lra): Pass new parameter to lra_create_live_ranges. Move check with lra_need_for_spill_p after live range pass. Switch on rematerialization pass.
[Bug target/1078] Problems with attributes documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1078 --- Comment #10 from sandra at gcc dot gnu.org --- Author: sandra Date: Tue Jan 5 18:04:01 2016 New Revision: 232081 URL: https://gcc.gnu.org/viewcvs?rev=232081&root=gcc&view=rev Log: 2016-01-05 Sandra Loosemore PR 1078 gcc/ * doc/extend.texi (MicroBlaze Function Attributes): Document interrupt_handler and fast_interrupt attributes. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 --- Comment #10 from H.J. Lu --- This change makes it to compile: diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c index 07eea84..43a85b7 100644 --- a/gcc/var-tracking.c +++ b/gcc/var-tracking.c @@ -4968,7 +4968,7 @@ dataflow_set_different (dataflow_set *old_set, dataflow_set *new_set) if (old_set->vars == new_set->vars) return false; - if (shared_hash_htab (old_set->vars)->elements () + if (0 && shared_hash_htab (old_set->vars)->elements () != shared_hash_htab (new_set->vars)->elements ()) return true;
[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 --- Comment #9 from Justas L --- Yes, forced stack alignment on x86_64 was introduced after 5.2, in r228728 for pr66697. Also, I can confirm that adding -fno-omit-frame-pointer allows Wine to compile normally.
[Bug fortran/65996] [5/6 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #11 from Jerry DeLisle --- I will work this one.
[Bug c++/69149] Segmentation fault during compile of libre office with debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69149
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-05
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Markus Trippelsdorf ---
This is what creduce came up with:
markus@x4 tmp % cat deb.ii
template struct A { typedef __underlying_type(_Tp) type; };
namespace o3tl {
template struct typed_flags;
template ::type> struct is_typed_flags {
class Wrap {
public:
constexpr operator E() {}
};
};
}
template
constexpr typename o3tl::typed_flags::Wrap operator|(E, E) {
__PRETTY_FUNCTION__;
}
enum SfxSlotMode { NONE, PROPGET };
namespace o3tl {
template <>
struct typed_flags : is_typed_flags {};
class {
public:
short nGroupId;
} a{(short)(NONE | PROPGET)};
}
markus@x4 tmp % g++ deb.ii
deb.ii:22:20: in constexpr expansion of
‘operator|((SfxSlotMode)0u, (SfxSlotMode)1u)’
deb.ii:22:28: internal compiler error: Segmentation fault
} a{(short)(NONE | PROPGET)};
^
0xcc988f crash_signal
../../gcc/gcc/toplev.c:334
0x7f1334c6230f ???
/home/markus/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xa48714 bool vec_safe_reserve(vec*&, unsigned int, bool)
../../gcc/gcc/vec.h:553
0xa48714 tree_node** vec_safe_push(vec*&, tree_node* const&)
../../gcc/gcc/vec.h:647
0xa48714 add_local_decl(function*, tree_node*)
../../gcc/gcc/function.c:6791
0xd3c416 remap_decls
../../gcc/gcc/tree-inline.c:611
0xd3d290 remap_block
../../gcc/gcc/tree-inline.c:679
0xd4373e copy_bind_expr
../../gcc/gcc/tree-inline.c:752
[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 --- Comment #10 from Eric Botcazou --- Created attachment 37231 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37231&action=edit Reduced testcase To be compiled with -O2 -mincoming-stack-boundary=3
[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 Eric Botcazou changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #11 from Eric Botcazou --- > Yes, forced stack alignment on x86_64 was introduced after 5.2, in r228728 > for pr66697. Also, I can confirm that adding -fno-omit-frame-pointer allows > Wine to compile normally. I see, thanks. Uros, would you mind having a look? I don't know this stuff.
[Bug fortran/68009] [6 Regression] prototype for gfortran_runtime_error with inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68009 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- I will poke at this unless Thomas wants to take it.
[Bug c++/66460] ICE using __func__ in constexpr function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66460 Markus Trippelsdorf changed: What|Removed |Added CC||hauf.johannes at gmail dot com --- Comment #6 from Markus Trippelsdorf --- *** Bug 69149 has been marked as a duplicate of this bug. ***
[Bug c++/69149] Segmentation fault during compile of libre office with debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69149 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 66460 ***
[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #40 from Mike Frysinger --- (In reply to Jeffrey A. Law from comment #39) we should at least do gcc-5. i'm guessing there won't be another 4.9.
