[Bug c/13029] [3.4 Regression] static consts and -Wunused-variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029 Chengnian Sun chengniansun at gmail dot com changed: What|Removed |Added CC||chengniansun at gmail dot com --- Comment #4 from Chengnian Sun chengniansun at gmail dot com --- May I ask what is the design rational of not warning unused static const variables? I saw Clang has a different strategy, and it even has a type of warning -- [-Wunused-const-variable]
[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- The specialization is a regular function, not comdat, thus it is not appropriate to inline it at -O2 -fpic, only -O3 is inlining functions regardless to whether they could be interposed or not, or for -O2 without -fpic because the symbol can't be interposed. Or use the inline keyword for the specialization.
[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 --- Comment #8 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to janus from comment #5) (In reply to Bernd Edlinger from comment #3) The function make_real is not invoked directly, but through the type-bound a%real, which is called three times in the test case. Does the failure occur already at the first one (i.e. line 67)? Can you give a reduced test case? Yes it is in line 67. Ok, then I guess the following reduction should be enough to trigger the bug? module m type :: t1 integer :: i = 42 contains procedure, pass :: real = make_real end type contains real function make_real (arg) class(t1), intent(in) :: arg make_real = real (arg%i) end function make_real end module m use m class(t1), pointer :: a type(t1), target :: b a = b if (a%real() .ne. real (42)) call abort end The crash occurs if I add the line procedure(make_real), pointer :: ptr to type t1. Additionally you could try if calling 'make_real' directly (without the type-binding) works, i.e. replace the last line by: if (make_real(a) .ne. real (42)) call abort This line does not abort. The type-bound call is transformed into a procedure-pointer-component call, i.e. a._vptr-real (a). Do all the proc_ptr_comp_* test cases work on ARMv7? Yes, the test cases that failed with the last snapshot are: FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 execution test FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 execution test FAIL: gfortran.dg/select_type_4.f90 -O2 execution test This one might possibly be related. It also involves polymorphism (but no type-bound procedures). I think dynamic_dispatch_3.f03 duplicates this one. But I am not sure about select_type_4.f90: $ gfortran -O1 -g select_type_4.f90 -o select_type_4 $ ./select_type_4 1.2302 42 Node with no data. Some other node type. 4.5594 $ gfortran -O2 -g select_type_4.f90 -o select_type_4 $ ./select_type_4 1.2302 42 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Segmentation fault Program received signal SIGSEGV, Segmentation fault. MAIN__ () at select_type_4.f90:166 166if (cnt /= 4) call abort() but this statement is executed for the third time when the chash happens: Breakpoint 2, MAIN__ () at select_type_4.f90:166 166if (cnt /= 4) call abort() 2: /x $r2 = 0x8db4 1: x/i $pc = 0x8b14 MAIN__+608:ldrr3, [r2] (gdb) c Continuing. 1.2302 Breakpoint 2, MAIN__ () at select_type_4.f90:166 166if (cnt /= 4) call abort() 2: /x $r2 = 0x8dcc 1: x/i $pc = 0x8b14 MAIN__+608:ldrr3, [r2] (gdb) c Continuing. 42 Breakpoint 2, MAIN__ () at select_type_4.f90:166 166if (cnt /= 4) call abort() 2: /x $r2 = 0xf15aea17 1: x/i $pc = 0x8b14 MAIN__+608:ldrr3, [r2] this looks like some loop optimization problem.
[Bug c/13029] [3.4 Regression] static consts and -Wunused-variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, clang strategy seems to be not to bother with false positives and always prefer warning over not warning on anything, so usually the clang output is just completely unreadable because among the tons of false positives it is hard to find actual real code problems. GCC strategy is to find some ballance between false positive warnings and missed warnings.
[Bug c/13029] [3.4 Regression] static consts and -Wunused-variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029 --- Comment #6 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Chengnian Sun from comment #4) May I ask what is the design rational of not warning unused static const variables? See PR28901. There are cases of unused static const where the warning isn't wanted, and so far the decision has been to favour those over the cases where the warning _is_ wanted and would have detected real bugs. Sigh.
[Bug driver/60233] AVX instructions emitted with -march=native on host without AVX support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233 --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #4) I think the reason for this is that -march=native passes in your case -mf16c, and -mf16c implies -mavx. So, either OPTION_MASK_ISA_F16C_SET should not include OPTION_MASK_ISA_AVX_SET, or the driver shouldn't set -mf16c if AVX support is missing. As at least some of the F16C instructions use ymmN registers, if we'd change OPTION_MASK_ISA_F16C_SET, then the *256 TARGET_F16C patterns would also need to be guarded with TARGET_AVX. For the latter alternative, we would need to do something like: --- gcc/config/i386/driver-i386.c 2014-01-03 11:41:06.393269411 +0100 +++ gcc/config/i386/driver-i386.c 2014-02-17 07:32:41.289022308 +0100 @@ -513,6 +513,7 @@ const char *host_detect_local_cpu (int a has_avx2 = 0; has_fma = 0; has_fma4 = 0; + has_f16c = 0; has_xop = 0; has_xsave = 0; has_xsaveopt = 0; This is the correct approach. We already disable f16c for -mno-avx in common/config/i386/i386-common.c in this way, and it looks that driver-i386.c was not updated accordingly. There are no real processors with F16C and no AVX, but we should be consistent here and follow i386-common.c.
[Bug driver/60233] AVX instructions emitted with -march=native on host without AVX support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- And while looking at driver-i386.c, it looks to me that the whole osxsave state check should be moved below (ext_level 0x8000) processing, otherwise we won't clear FMA4 and XOP flags correctly.
[Bug tree-optimization/60229] wrong code at -O2 and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60229 --- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com --- Technically there is an overflow there. But GCC defines conversion to a smaller signed integer type, when the value cannot be represented in that smaller type, as a non-signalling truncation. Still, portable code mustn't rely on that.
[Bug fortran/60231] [4.8/4.9 Regression] ICE on undefined generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60231 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 CC||janus at gcc dot gnu.org Summary|ICE on undefined generic|[4.8/4.9 Regression] ICE on ||undefined generic Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. The ICE occurs with 4.8 and trunk, but 4.7 gives the following: c0.f90:7.19: generic :: Add = Add1, Add2 1 Error: 'add1' and 'add2' for GENERIC 'add' at (1) are ambiguous c0.f90:5.12: procedure :: Add1 1 Error: 'add1' must be a module procedure or an external procedure with an explicit interface at (1) c0.f90:6.12: procedure :: Add2 1 Error: 'add2' must be a module procedure or an external procedure with an explicit interface at (1) About the first error one can argue, but the second and third one are certainly correct. Thus the ICE is a regresssion.
[Bug c/13029] [3.4 Regression] static consts and -Wunused-variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029 --- Comment #7 from Chengnian Sun chengniansun at gmail dot com --- Thanks, Jakub and Mikael. I see it now. IMHO, it might be worthy to add a flag -Wunused-const-variable similar to Clang, which is not included either -Wall or -Wextra. Therefore the end user can decide whether to enable this warning based on their specific scenario. I think it is better than the current case that people who need this warning support cannot get it.
[Bug c/13029] [3.4 Regression] static consts and -Wunused-variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Chengnian Sun from comment #7) Thanks, Jakub and Mikael. I see it now. IMHO, it might be worthy to add a flag -Wunused-const-variable similar to Clang, which is not included either -Wall or -Wextra. Therefore the end user can decide whether to enable this warning based on their specific scenario. I think it is better than the current case that people who need this warning support cannot get it. Yeah, I guess that is a possibility.
[Bug fortran/60231] [4.8/4.9 Regression] ICE on undefined generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60231
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #2 from janus at gcc dot gnu.org ---
This draft patch fixes the ICE:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 207804)
+++ gcc/fortran/resolve.c(working copy)
@@ -11362,6 +11362,7 @@ check_generic_tbp_ambiguity (gfc_tbp_generic* t1,
{
gfc_symbol *sym1, *sym2;
const char *pass1, *pass2;
+ gfc_formal_arglist *dummy_args;
gcc_assert (t1-specific t2-specific);
gcc_assert (!t1-specific-is_generic);
@@ -11384,19 +11385,33 @@ check_generic_tbp_ambiguity (gfc_tbp_generic* t1,
return false;
}
- /* Compare the interfaces. */
+ /* Determine PASS arguments. */
if (t1-specific-nopass)
pass1 = NULL;
else if (t1-specific-pass_arg)
pass1 = t1-specific-pass_arg;
else
-pass1 = gfc_sym_get_dummy_args
(t1-specific-u.specific-n.sym)-sym-name;
+{
+ dummy_args = gfc_sym_get_dummy_args (t1-specific-u.specific-n.sym);
+ if (dummy_args)
+pass1 = dummy_args-sym-name;
+ else
+pass1 = NULL;
+}
if (t2-specific-nopass)
pass2 = NULL;
else if (t2-specific-pass_arg)
pass2 = t2-specific-pass_arg;
else
-pass2 = gfc_sym_get_dummy_args
(t2-specific-u.specific-n.sym)-sym-name;
+{
+ dummy_args = gfc_sym_get_dummy_args (t2-specific-u.specific-n.sym);
+ if (dummy_args)
+pass2 = dummy_args-sym-name;
+ else
+pass2 = NULL;
+}
+
+ /* Compare the interfaces. */
if (gfc_compare_interfaces (sym1, sym2, sym2-name, !t1-is_operator, 0,
NULL, 0, pass1, pass2))
{
[Bug tree-optimization/60236] New: gfortran.dg/vect/pr32380.f fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236 Bug ID: 60236 Summary: gfortran.dg/vect/pr32380.f fails on ARM Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Hi, this test case fails, because the only 5 of 6 loops get optimized: pr32380.f:162:0: note: function is not vectorizable. pr32380.f:162:0: note: not vectorized: relevant stmt not supported: _113 = __builtin_sqrtf (_112); pr32380.f:5:0: note: vectorized 5 loops in function. but the test case expects 6 loops here. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/4.9.0/lto-wrapper Target: armv7l-unknown-linux-gnueabihf Configured with: ../gcc-4.9-20140209/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard Thread model: posix gcc version 4.9.0 20140209 (experimental) (GCC)
[Bug c++/60215] [4.9 Regression] ICE with invalid bit-field size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60215 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 CC||jakub at gcc dot gnu.org, ||paolo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r205449.
[Bug fortran/60232] [OOP] The rank of the element in the structure constructor does not match that of the component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60232 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 CC||janus at gcc dot gnu.org Summary|OOP False Error: The rank |[OOP] The rank of the |of the element in the |element in the structure |structure constructor |constructor does not match ||that of the component Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Reduced test case: module ObjectLists implicit none Type TObjectList contains procedure :: ArrayItem end Type contains function ArrayItem(L) result(P) Class(TObjectList) :: L Class(TObjectList), pointer :: P(:) end function end module use ObjectLists implicit none Type, extends(TObjectList):: TSampleList end Type contains subroutine TSampleList_ConfidVal(L) Class(TSampleList) :: L end subroutine end Same error with 4.7, 4.8 and trunk. (In 4.6 and earlier, polymorphic arrays are not supported yet.)
[Bug driver/60233] AVX instructions emitted with -march=native on host without AVX support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32151action=edit gcc49-pr60233.patch Untested fix.
[Bug tree-optimization/60229] wrong code at -O2 and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60229 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, the conversion is implementation-defined behavior, and GCC documents what it does in that case (does it?) and thus you can rely on it, and given that other compilers also have simimilar implementation-defined behavior choice for that case, you can portably assume it unless you are targetting extinct architectures.
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #7 from Joey Ye joey.ye at arm dot com --- (In reply to Richard Biener from comment #5) (In reply to Joey Ye from comment #4) -fdisable-tree-forwprop4 doesn't help. -fno-tree-ter makes it even worse. The former is strange because it's the only pass that does sth that is changed by the patch? As said, make sure to include the fix for PR59993 in your testing. Does -fno-tree-forwprop fix the regression? I'm sorry what I meant was: -fdisable-tree-forwprop4 didn't make benchmark faster. Actually with -fdisable-tree-forwprop4 both revision before/after 207239 get the same lower score. 207239 O2: low 207238 O2: high 207239 O2 -fdisable-tree-forwprop4: low 207238 O2 -fdisable-tree-forwprop4: low
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
--- Comment #5 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 14 Feb 2014, wmi at google dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
Bug ID: 60206
Summary: IVOPT has no idea of inline asm
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
CC: rguenth at gcc dot gnu.org, shenhan at google dot com
Host: i386
Target: i386
Created attachment 32141
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32141action=edit
Testcase
This bug is found in google branch but I think the same problem also exists on
trunk (but not exposed).
For the testcase 1.c attached (1.c is extracted from libgcc/soft-fp/divtf3.c),
use trunk compiler gcc-r202164 (Target: x86_64-unknown-linux-gnu) + the patch
r204497 could expose the problem.
The command:
gcc -v -O2 -fno-omit-frame-pointer -fpic -c -S -m32 1.c
The error:
./1.c: In function ‘__divtf3’:
./1.c:64:1194: error: ‘asm’ operand has impossible constraints
The inline asm in error message is as follow:
do {
__asm__ (
sub{l} {%11,%3|%3,%11}\n\t
sbb{l} {%9,%2|%2,%9}\n\t
sbb{l} {%7,%1|%1,%7}\n\t
sbb{l} {%5,%0|%0,%5}
: =r ((USItype) (A_f[3])), =r ((USItype) (A_f[2])), =r ((USItype)
(A_f[1])), =r ((USItype) (A_f[0])) : 0 ((USItype) (B_f[2])), g
((USItype) (A_f[2])), 1 ((USItype) (B_f[1])), g ((USItype) (A_f[1])), 2
((USItype) (B_f[0])), g ((USItype) (A_f[0])), 3 ((USItype) (0)), g
((USItype) (_n_f[_i])));
} while ()
Because -fno-omit-frame-pointer is turned on and the command line uses -fpic,
there are only 5 registers for register allocation.
Before IVOPT,
%0, %1, %2, %3 require 4 registers. The index variable i of _n_f[_i] requires
another register. So 5 registers are used up here.
After IVOPT, MEM reference _n_f[_i] is converted to MEM[base: _874, index:
ivtmp.22_821, offset: 0B]. base and index require 2 registers, Now 6 registers
are required, so LRA cannot find enough registers to allocate.
trunk compiler doesn't expose the problem because of patch r202165. With patch
r202165, IVOPT doesn't change _n_f[_i] in inline asm above. But it just hided
the problem.
Should IVOPT care about the constraints in inline-asm and restrict its
optimization in some case?
It's true that ASMs are not in any way special cased - it may be worth
trying if distinguishing address-uses and other uses may be worth it.
It's only a cost thing, of course. In general find_interesting_uses_stmt
may need some modernization.
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #8 from Joey Ye joey.ye at arm dot com --- Here is tree dump and diff of 133t.forwprop4 bb 2: Int_Index_4 = Int_1_Par_Val_3(D) + 5; Int_Loc.0_5 = (unsigned int) Int_Index_4; _6 = Int_Loc.0_5 * 4; _8 = Arr_1_Par_Ref_7(D) + _6; *_8 = Int_2_Par_Val_10(D); _13 = _6 + 4; _14 = Arr_1_Par_Ref_7(D) + _13; *_14 = Int_2_Par_Val_10(D); _17 = _6 + 60; _18 = Arr_1_Par_Ref_7(D) + _17; *_18 = Int_Index_4; pretmp_20 = Int_Loc.0_5 * 100; pretmp_2 = Arr_2_Par_Ref_22(D) + pretmp_20; _42 = (sizetype) Int_1_Par_Val_3(D); _41 = _42 * 4; - _40 = pretmp_2 + _41; // good + _12 = _41 + pretmp_20; // bad + _40 = Arr_2_Par_Ref_22(D) + _12; // bad MEM[(int[25] *)_40 + 20B] = Int_Index_4; MEM[(int[25] *)_40 + 24B] = Int_Index_4; _29 = MEM[(int[25] *)_40 + 16B]; _30 = _29 + 1; MEM[(int[25] *)_40 + 16B] = _30; _32 = pretmp_20 + 1000; _33 = Arr_2_Par_Ref_22(D) + _32; _34 = *_8; - _51 = _33 + _41; // good + _16 = _41 + _32; // bad + _51 = Arr_2_Par_Ref_22(D) + _16; // bad MEM[(int[25] *)_51 + 20B] = _34; Int_Glob = 5; return;
[Bug c++/60222] [4.8/4.9 Regression] ICE with reference as template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60222 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 CC||jakub at gcc dot gnu.org Version|4.9.0 |4.8.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Indeed, started with r207167.
[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #33 from rguenther at suse dot de rguenther at suse dot de ---
On Sun, 16 Feb 2014, law at redhat dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #32 from Jeffrey A. Law law at redhat dot com ---
The problem we're seeing is with the cc0-setter and cc0-user in different
blocks, they're separated by a NOTE_BASIC_BLOCK.
That causes CSE to blow up because it expects that the cc0-setter and
cc0-user are always consecutive. While we're just seeing the failure in
CSE right now, I'm sure there's a ton of places that assume the
setter/user are inseparable as that has been the documented form for ~20
years.
From rtl.texi:
The instruction setting the
condition code must be adjacent to the instruction using the condition
code; only @code{note} insns may separate them.
We either need to relax that and audit all the HAVE_cc0 code to ensure it
doesn't make that assumption, or we need to somehow restore the property that
the setter and user are inseparable.
I think relaxing this constraint and allowing the cc0-setter and
cc0-user be separated by a fallthru-edge should be allowed
(and make sure that bb-reorder later doesn't separate the BBs)
[Bug c++/60219] [4.8/4.9 Regression] [c++11] ICE invalid use of variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60219 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Version|4.9.0 |4.8.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started likely with r190653 (works with r190650, fails with r190662, coerce_template_parms+resolve_nondeduced_context in backtrace).
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 17 Feb 2014, joey.ye at arm dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #8 from Joey Ye joey.ye at arm dot com --- Here is tree dump and diff of 133t.forwprop4 bb 2: Int_Index_4 = Int_1_Par_Val_3(D) + 5; Int_Loc.0_5 = (unsigned int) Int_Index_4; _6 = Int_Loc.0_5 * 4; _8 = Arr_1_Par_Ref_7(D) + _6; *_8 = Int_2_Par_Val_10(D); _13 = _6 + 4; _14 = Arr_1_Par_Ref_7(D) + _13; *_14 = Int_2_Par_Val_10(D); _17 = _6 + 60; _18 = Arr_1_Par_Ref_7(D) + _17; *_18 = Int_Index_4; pretmp_20 = Int_Loc.0_5 * 100; pretmp_2 = Arr_2_Par_Ref_22(D) + pretmp_20; _42 = (sizetype) Int_1_Par_Val_3(D); _41 = _42 * 4; - _40 = pretmp_2 + _41; // good + _12 = _41 + pretmp_20; // bad + _40 = Arr_2_Par_Ref_22(D) + _12; // bad MEM[(int[25] *)_40 + 20B] = Int_Index_4; MEM[(int[25] *)_40 + 24B] = Int_Index_4; _29 = MEM[(int[25] *)_40 + 16B]; _30 = _29 + 1; MEM[(int[25] *)_40 + 16B] = _30; _32 = pretmp_20 + 1000; _33 = Arr_2_Par_Ref_22(D) + _32; _34 = *_8; - _51 = _33 + _41; // good + _16 = _41 + _32; // bad + _51 = Arr_2_Par_Ref_22(D) + _16; // bad MEM[(int[25] *)_51 + 20B] = _34; Int_Glob = 5; return; But that doesn't make sense - it means that -fdisable-tree-forwprop4 should get numbers back to good speed, no? Because that's the only change forwprop4 does. For completeness please base checks on r207316 (it contains a fix for the blamed revision, but as far as I can see it shouldn't make a difference for the testcase). Did you check whether my hackish patch fixes things?
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 --- Comment #35 from Joey Ye joey.ye at arm dot com --- Here is good expansion: ;; _41 = _42 * 4; (insn 20 19 0 (set (reg:SI 126 [ D.5038 ]) (ashift:SI (reg/v:SI 131 [ Int_1_Par_Val ]) (const_int 2 [0x2]))) -1 (nil)) ;; _40 = _2 + _41; (insn 21 20 22 (set (reg:SI 136 [ D.5035 ]) (plus:SI (reg/v/f:SI 130 [ Arr_2_Par_Ref ]) (reg:SI 119 [ D.5036 ]))) -1 (nil)) (insn 22 21 0 (set (reg/f:SI 125 [ D.5035 ]) (plus:SI (reg:SI 136 [ D.5035 ]) (reg:SI 126 [ D.5038 ]))) -1 (nil)) ;; MEM[(int[25] *)_51 + 20B] = _34; (insn 29 28 30 (set (reg:SI 139) (plus:SI (reg/v/f:SI 130 [ Arr_2_Par_Ref ]) (reg:SI 119 [ D.5036 ]))) Proc_8.c:23 -1 (nil)) (insn 30 29 31 (set (reg:SI 140) (plus:SI (reg:SI 139) (reg:SI 126 [ D.5038 ]))) Proc_8.c:23 -1 (nil)) (insn 31 30 32 (set (reg/f:SI 141) (plus:SI (reg:SI 140) (const_int 1000 [0x3e8]))) Proc_8.c:23 -1 (nil)) (insn 32 31 0 (set (mem:SI (plus:SI (reg/f:SI 141) (const_int 20 [0x14])) [2 MEM[(int[25] *)_51 + 20B]+0 S4 A32]) (reg:SI 124 [ D.5039 ])) Proc_8.c:23 -1 (nil)) After cse1 140 can be replaced by 125, thus lead a series of transformation make it much more efficient. Here is bad expansion: ;; _40 = Arr_2_Par_Ref_22(D) + _12; (insn 22 21 23 (set (reg:SI 138 [ D.5038 ]) (plus:SI (reg:SI 128 [ D.5038 ]) (reg:SI 121 [ D.5036 ]))) -1 (nil)) (insn 23 22 0 (set (reg/f:SI 127 [ D.5035 ]) (plus:SI (reg/v/f:SI 132 [ Arr_2_Par_Ref ]) (reg:SI 138 [ D.5038 ]))) -1 (nil)) ;; _32 = _20 + 1000; (insn 29 28 0 (set (reg:SI 124 [ D.5038 ]) (plus:SI (reg:SI 121 [ D.5036 ]) (const_int 1000 [0x3e8]))) Proc_8.c:23 -1 (nil)) ;; MEM[(int[25] *)_51 + 20B] = _34; (insn 32 31 33 (set (reg:SI 141) (plus:SI (reg/v/f:SI 132 [ Arr_2_Par_Ref ]) (reg:SI 124 [ D.5038 ]))) Proc_8.c:23 -1 (nil)) (insn 33 32 34 (set (reg/f:SI 142) (plus:SI (reg:SI 141) (reg:SI 128 [ D.5038 ]))) Proc_8.c:23 -1 (nil)) (insn 34 33 0 (set (mem:SI (plus:SI (reg/f:SI 142) (const_int 20 [0x14])) [2 MEM[(int[25] *)_51 + 20B]+0 S4 A32]) (reg:SI 126 [ D.5039 ])) Proc_8.c:23 -1 (nil)) Here cse doesn't happen, resulting in less optimal insns. Reason why cse doesn't happen is unclear yet.
[Bug c++/60216] [4.8/4.9 Regression] [c++11] Trouble with deleted template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60216 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Version|4.9.0 |4.8.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r198098 (or r198099, but that seems unrelated, r198096 works, r198100 fails).
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 --- Comment #11 from algrant at acm dot org --- Where do you get that this is racy if the access to data is not atomic? By design, release/acquire and release/consume sequences don't require wholesale changes to the way the data payload (in the general case, multiple fields within a structure) is first constructed and then used. 1.10#13 makes clear that as a result of the intra-thread sequencing between atomic and non-atomic operations (1.9#14), and the inter-thread ordering between atomic operations (1.10 various), there is a resulting ordering on operations to ordinary (sic) objects. Please see the references to the C++ standard in the source example, for the chain of reasoning here.
[Bug fortran/60234] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1883
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-02-17
CC||janus at gcc dot gnu.org
Summary|OOP internal compiler |[4.9 Regression] [OOP] ICE
|error: in |in
|generate_finalization_wrapp |generate_finalization_wrapp
|er |er at fortran/class.c:1883
Ever confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org ---
Reduced test case:
module ObjectLists
implicit none
Type TObjectList
contains
FINAL :: finalize
end Type
Type, extends(TObjectList):: TRealCompareList
end Type
contains
subroutine finalize(L)
Type(TObjectList) :: L
end subroutine
integer function CompareReal(this)
Class(TRealCompareList) :: this
end function
end module
4.8 rejects it cleanly ('not yet implemented'), so the ICE is a regression.
[Bug fortran/60234] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1883
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234 --- Comment #2 from janus at gcc dot gnu.org --- This patchlet seems to be sufficient to fix the ICE: Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c(revision 207804) +++ gcc/fortran/decl.c(working copy) @@ -1199,7 +1199,7 @@ build_sym (const char *name, gfc_charlen *cl, bool sym-attr.implied_index = 0; if (sym-ts.type == BT_CLASS) -return gfc_build_class_symbol (sym-ts, sym-attr, sym-as, false); +return gfc_build_class_symbol (sym-ts, sym-attr, sym-as, true); return true; } Comment 1 compiles fine with this, but comment 0 hits another ICE: ObjectLists.f90:186:0: internal compiler error: Segmentation fault class is (object_array_pointer) ^ 0x93e90f crash_signal /home/jweil/gcc49/trunk/gcc/toplev.c:337 0x672420 gfc_get_derived_type(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2455 0x672988 gfc_typenode_for_spec(gfc_typespec*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:1112 0x671263 gfc_sym_type(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2137 0x671728 gfc_get_function_type(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2797 0x6721ca gfc_get_ppc_type(gfc_component*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2322 0x6726a7 gfc_get_derived_type(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2484 0x672988 gfc_typenode_for_spec(gfc_typespec*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:1112 0x671263 gfc_sym_type(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2137 0x637b96 gfc_get_symbol_decl(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:1390 0x639f99 gfc_create_module_variable /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:4267 0x607453 do_traverse_symtree /home/jweil/gcc49/trunk/gcc/fortran/symbol.c:3575 0x63ae12 gfc_generate_module_vars(gfc_namespace*) /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:4693 0x61cef1 gfc_generate_module_code(gfc_namespace*) /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1930 0x5db92b translate_all_program_units /home/jweil/gcc49/trunk/gcc/fortran/parse.c:4523 0x5db92b gfc_parse_file() /home/jweil/gcc49/trunk/gcc/fortran/parse.c:4733 0x618335 gfc_be_parse_file /home/jweil/gcc49/trunk/gcc/fortran/f95-lang.c:188
[Bug c++/60146] [4.8/4.9 Regression] ICE when compiling this code with -fopenmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60146 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r188939.
[Bug c++/60237] New: isnan fails with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237 Bug ID: 60237 Summary: isnan fails with -ffast-math Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathanael.schaeffer at gmail dot com With -ffast-math, isnan should return true if passed a NaN value. Otherwise, how is isnan different than (x!=x) ? isnan worked as expected with gcc 4.7, but does not with 4.8.1 and 4.8.2 How can I check if x is a NaN in a portable way (not presuming any compilation option) ?
[Bug c++/60237] isnan fails with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, -ffast-math implies -ffinite-math-only, so the compiler is assuming no NaNs or infinites are used as arguments/return values of any expression. So, if you have a program that produces NaNs anyway, you shouldn't be building it with -ffast-math, at least not with -ffinite-math-only.
[Bug c++/60215] [4.9 Regression] ICE with invalid bit-field size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60215
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Evidently, in case of error recovery we can get here:
9672 case COMPONENT_REF:
9673 if (is_overloaded_fn (t))
9674 {
9675 /* We can only get here in checking mode via
9676 build_non_dependent_expr, because any expression that
9677 calls or takes the address of the function will have
9678 pulled a FUNCTION_DECL out of the COMPONENT_REF. */
9679 gcc_checking_assert (allow_non_constant);
9680 *non_constant_p = true;
9681 return t;
9682 }
with allow_non_constant == false. Jason suggested the comment (and the assert
;) as part of the fix for 58647, thus I would like to hear from him... Shall we
maybe || errorcount ? Seems safe for 4.9.0.
[Bug fortran/60238] New: Allow colon-separated triplet in array initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60238 Bug ID: 60238 Summary: Allow colon-separated triplet in array initialization Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Not really a bug, but ifort (and also going back, CVF) allow a clean array initialization sytnax like this integer :: indices(3) indices=[3:5] as an alternative to the ugly indices = (/ (I, I=3, 5) /) Supporting it would allow easier compiler interoperability.
[Bug fortran/60234] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1883
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) Comment 1 compiles fine with this, but comment 0 hits another ICE: ObjectLists.f90:186:0: internal compiler error: Segmentation fault class is (object_array_pointer) ^ 0x93e90f crash_signal /home/jweil/gcc49/trunk/gcc/toplev.c:337 0x672420 gfc_get_derived_type(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2455 A reduced test case for this ICE is: integer function Compare(R1) class(*) R1 end function But it seems to be due to the patch in comment 2 and does not occur without it.
[Bug tree-optimization/60183] [4.7/4.8 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] |phiprop creates invalid |phiprop creates invalid |code|code --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug c++/60237] isnan fails with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237 --- Comment #2 from N Schaeffer nathanael.schaeffer at gmail dot com --- Thank you for your answer. My program (which is a computational fluid dynamics solver) is not supposed to produce NaNs. However, when it does (which means something went wrong), I would like to abort the program and return an error instead of continuing crunching NaNs. I also want it to run as fast as possible (hence the -ffast-math option). I would argue that: if printf(%f,x) outputs NaN, isnan(x) should also be returning true. Do you have a suggestion concerning my last question: How can I check if x is NaN in a portable way (not presuming any compilation option) ?
[Bug c++/60237] isnan fails with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to N Schaeffer from comment #2)
Do you have a suggestion concerning my last question:
How can I check if x is NaN in a portable way (not presuming any compilation
option) ?
This should bypass software optimizations. But if the hardware is put in a mode
that does strange things with NaN, it will be harder to work around.
int my_isnan(double x){
volatile double y=x;
return y!=y;
}
[Bug fortran/60238] Allow colon-separated triplet in array initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60238 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- as an alternative to the ugly indices = (/ (I, I=3, 5) /) You can use indices=[(I, I=3, 5)] if your coding style accepts f2003 syntax. Supporting it would allow easier compiler interoperability. The only way to achieve that is to stick to the Fortran standard, i.e, never use extensions of any kind.
[Bug fortran/60234] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1883
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #4 from janus at gcc dot gnu.org ---
The test case in comment 0 compiles cleanly when adding the following to the
patch in comment 2:
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c(revision 207804)
+++ gcc/fortran/class.c(working copy)
@@ -637,9 +637,10 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
if (!gfc_add_component (fclass, _vptr, c))
return false;
c-ts.type = BT_DERIVED;
- if (delayed_vtab
- || (ts-u.derived-f2k_derived
- ts-u.derived-f2k_derived-finalizers))
+ if ((delayed_vtab
+ || (ts-u.derived-f2k_derived
+ts-u.derived-f2k_derived-finalizers))
+ !ts-u.derived-attr.unlimited_polymorphic)
c-ts.u.derived = NULL;
else
{
[Bug c++/60237] isnan fails with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237
--- Comment #4 from N Schaeffer nathanael.schaeffer at gmail dot com ---
int my_isnan(double x){
volatile double y=x;
return y!=y;
}
is translated to:
0x00406cf0 +0: movsd QWORD PTR [rsp-0x8],xmm0
0x00406cf6 +6: xoreax,eax
0x00406cf8 +8: movsd xmm1,QWORD PTR [rsp-0x8]
0x00406cfe +14:movsd xmm0,QWORD PTR [rsp-0x8]
0x00406d04 +20:comisd xmm1,xmm0
0x00406d08 +24:setne al
0x00406d0b +27:ret
which also fails to detect NaN, which is right according to the documented
behaviour of comisd:
http://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc44.htm
[Bug c++/60239] New: False positive maybe-uninitialized in for loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60239
Bug ID: 60239
Summary: False positive maybe-uninitialized in for loop
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lcid-fire at gmx dot net
The code in
https://github.com/RobertBeckebans/RBDOOM-3-BFG/blob/dd9b8a8710dd7f8c1376eb245ee31fc740eae6eb/neo/renderer/tr_backend_rendertools.cpp
triggers a false positive maybe-uninitialized warning.
The code in question begins at line 1971:
static void RB_DrawText( const char* text, const idVec3 origin, float
scale, const idVec4 color, const idMat3 viewAxis, const int align )
{
// snip/
idVec3 org, p1, p2;
// snip/
for( i = 0; i len; i++ )
{
if( i == 0 || text[i] == '\n' )
{
org = origin - viewAxis[2] * ( line * 36.0f * scale );
// snip/
}
org -= viewAxis[1] * ( spacing * scale );
}
The error message is:
idlib/../idlib/math/Vector.h: In function 'void RB_DrawText(const char*, const
idVec3, float, const idVec4, const idMat3, int)':
idlib/../idlib/math/Vector.h:567:10: error: 'org.idVec3::x' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
/home/andreas/Projects/bfg/neo/renderer/tr_backend_rendertools.cpp:1971:9:
note: 'org.idVec3::x' was declared here
idVec3 org, p1, p2;
I tried to create a simple version that triggers that false positive but
everything I tried analyzes the code correctly.
[Bug other/60240] New: libbacktrace problems with nested functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60240
Bug ID: 60240
Summary: libbacktrace problems with nested functions
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: johannespfau at gmail dot com
Created attachment 32152
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32152action=edit
test case to reproduce the bug
Compile the test case with -lbacktrace -g.
Actual output:
test.c:17 (null)
Expected output: The backtrace should contain the function name ('a') instead
of null.
AFAICS the problem is in read_function_entry. There's a abbrev-has_children
check that assumes all children of a function are inlined instances of the same
function. This is not true, children can also be nested functions. libbacktrace
should check the DW_AT_inline tag here.
[Bug libffi/60073] [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs after recent modification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Mon Feb 17 12:00:04 2014 New Revision: 207822 URL: http://gcc.gnu.org/viewcvs?rev=207822root=gccview=rev Log: PR libffi/60073 * src/sparc/v8.S: Assemble only if !SPARC64. * src/sparc/v9.S: Remove obsolete comment. * src/sparc/ffitarget.h (enum ffi_abi): Add FFI_COMPAT_V9. (V8_ABI_P): New macro. (V9_ABI_P): Likewise. (FFI_EXTRA_CIF_FIELDS): Define only if SPARC64. * src/sparc/ffi.c (ffi_prep_args_v8): Compile only if !SPARC64. (ffi_prep_args_v9): Compile only if SPARC64. (ffi_prep_cif_machdep_core): Use V9_ABI_P predicate. (ffi_prep_cif_machdep): Guard access to nfixedargs field. (ffi_prep_cif_machdep_var): Likewise. (ffi_v9_layout_struct): Compile only if SPARC64. (ffi_call): Deal with FFI_V8PLUS and FFI_COMPAT_V9 and fix warnings. (ffi_prep_closure_loc): Use V9_ABI_P and V8_ABI_P predicates. (ffi_closure_sparc_inner_v8): Compile only if !SPARC64. (ffi_closure_sparc_inner_v9): Compile only if SPARC64. Guard access to nfixedargs field. Modified: trunk/libffi/ChangeLog trunk/libffi/src/sparc/ffi.c trunk/libffi/src/sparc/ffitarget.h trunk/libffi/src/sparc/v8.S trunk/libffi/src/sparc/v9.S
[Bug middle-end/25140] aliases, including weakref, break alias analysis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 60214 has been marked as a duplicate of this bug. ***
[Bug middle-end/60214] Variables with same DECL_ASSEMBLER_NAME are treated as different variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60214 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Yes, that's a know deficiency in alias-analysis. *** This bug has been marked as a duplicate of bug 25140 ***
[Bug fortran/60234] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1883
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) The test case in comment 0 compiles cleanly when adding the following to the patch in comment 2: Unfortunately the combination fails on proc_ptr_comp_37 in the testsuite.
[Bug c++/60216] [4.8/4.9 Regression] [c++11] Trouble with deleted template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60216 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/60219] [4.8/4.9 Regression] [c++11] ICE invalid use of variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60219 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/60231] [4.8/4.9 Regression] ICE on undefined generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60231 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) This draft patch fixes the ICE: ... and regtests cleanly.
[Bug c/60220] Vectorization : simple loop : fails to vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60220 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- It's vectorized with -fno-tree-loop-distribute-patterns since at least GCC 4.7 (the oldest still maintained release).
[Bug middle-end/60221] [4.7/4.8/4.9 Regression] gcc -fexceptions generates unnecessary cleanup code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||EH Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 CC||hubicka at gcc dot gnu.org, ||matz at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|gcc -fexceptions generates |[4.7/4.8/4.9 Regression] |unnecessary cleanup code|gcc -fexceptions generates ||unnecessary cleanup code Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug c++/60227] [4.7/4.8/4.9 Regression] [C++11] ICE using brace-enclosed initializer list to initialize array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60227 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.7.4
[Bug c++/60224] [4.7/4.8/4.9 Regression] ICE using invalid initializer for array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60224 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.7.4
[Bug c++/60225] [4.9 Regression] [c++11] ICE initializing constexpr array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60225 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) The specialization is a regular function, not comdat, thus it is not appropriate to inline it at -O2 -fpic, only -O3 is inlining functions regardless to whether they could be interposed or not, Wouldn't that be a wrong-code bug though? or for -O2 without -fpic because the symbol can't be interposed. Or use the inline keyword for the specialization.
[Bug tree-optimization/60236] gfortran.dg/vect/pr32380.f fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Does ARM have a builtin-vectorized-function hook that handles sqrtf? If not,
then that's expected.
Please adjust the expected number of vectorizations with vect_call_sqrt like
! { dg-final { scan-tree-dump-times vectorized 5 loops 1 vect { ! target
vect_call_sqrt } } }
! { dg-final { scan-tree-dump-times vectorized 6 loops 1 vect { target
vect_call_sqrt } } }
(and hope that powerpc and ia64 hit exactly the same issue ...)
[Bug c/25975] Problems with -ffast-math and isnan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25975 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 60237 has been marked as a duplicate of this bug. ***
[Bug c++/60237] isnan fails with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Dup. You can try building with -fno-builtin-isnan, but no - that's not a portable way. *** This bug has been marked as a duplicate of bug 25975 ***
[Bug fortran/55907] [4.7/4.8/4.9 Regression] ICE with -fno-automatic -finit-local-zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55907 --- Comment #10 from janus at gcc dot gnu.org --- Author: janus Date: Mon Feb 17 12:46:52 2014 New Revision: 207823 URL: http://gcc.gnu.org/viewcvs?rev=207823root=gccview=rev Log: 2014-02-17 Janus Weil ja...@gcc.gnu.org PR fortran/55907 * resolve.c (build_default_init_expr): Don't initialize character variable if -fno-automatic is given. 2014-02-17 Janus Weil ja...@gcc.gnu.org PR fortran/55907 * gfortran.dg/init_flag_12.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/init_flag_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60241] New: internal compiler error: in finish_member_declaration, at cp/semantics.c:2617
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241
Bug ID: 60241
Summary: internal compiler error: in finish_member_declaration,
at cp/semantics.c:2617
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
I've got internal compiler error on the following code:
template typename T
struct x
{
template typename U
struct y
{
typedef T result2;
};
typedef yint zy;
};
template
templateclass T
struct xint::y
{
typedef double result2;
};
int main()
{
xint::zy::result2 xxx;
xint::yint::result2 xxx2;
}
6.cpp: In instantiation of 'struct xint::yint':
6.cpp:23:19: required from here
6.cpp:16:1: internal compiler error: in finish_member_declaration, at
cp/semantics.c:2617
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug inline-asm/60242] New: incorrect optimization of code with inline assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60242 Bug ID: 60242 Summary: incorrect optimization of code with inline assembly Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: cerealguy at yandex dot ru Created attachment 32153 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32153action=edit An archive containing the source code and the .ii file The attached code copies one array to another using inline assembly and outputs the result. When compiled with -O2, the code that copies the data does not get executed. Compiler version: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9) Command line: g++ -O2 -o bug -save-temps bug.cpp ./bug
[Bug tree-optimization/60236] gfortran.dg/vect/pr32380.f fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Richard Biener from comment #1)
Does ARM have a builtin-vectorized-function hook that handles sqrtf? If not,
then that's expected.
Yes, it does have a builtin-vectorized-function which does _not_ handle sqrtf.
Please adjust the expected number of vectorizations with vect_call_sqrt like
! { dg-final { scan-tree-dump-times vectorized 5 loops 1 vect { ! target
vect_call_sqrt } } }
! { dg-final { scan-tree-dump-times vectorized 6 loops 1 vect { target
vect_call_sqrt } } }
(and hope that powerpc and ia64 hit exactly the same issue ...)
you mean vect_call_sqrtf ?
[Bug inline-asm/60242] incorrect optimization of code with inline assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60242 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You fail to tell GCC that your asm clobbers memory.
[Bug c++/60241] [4.7/4.8/4.9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:2617
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 Target Milestone|--- |4.7.4 Summary|internal compiler error: in |[4.7/4.8/4.9 Regression] |finish_member_declaration, |internal compiler error: in |at cp/semantics.c:2617 |finish_member_declaration, ||at cp/semantics.c:2617 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Probably invalid as 4.3 errors: t.C:15: error: specialization ‘xint::yU’ after instantiation ‘xint::yint’
[Bug regression/60133] [4.8/4.9 Regression] wrong multiarch name on aarch64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||dj at redhat dot com, ||iant at google dot com, ||neroden at gcc dot gnu.org, ||Ralf.Wildenhues at gmx dot de --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Looping in the various build infrastructure maintainers.
[Bug fortran/60234] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1883
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
Unfortunately the combination fails on proc_ptr_comp_37 in the testsuite.
To fix this, another hunk in class.c is needed, so that the patch becomes:
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c(revision 207823)
+++ gcc/fortran/class.c(working copy)
@@ -637,9 +637,10 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
if (!gfc_add_component (fclass, _vptr, c))
return false;
c-ts.type = BT_DERIVED;
- if (delayed_vtab
- || (ts-u.derived-f2k_derived
- ts-u.derived-f2k_derived-finalizers))
+ if ((delayed_vtab
+ || (ts-u.derived-f2k_derived
+ts-u.derived-f2k_derived-finalizers))
+ !ts-u.derived-attr.unlimited_polymorphic)
c-ts.u.derived = NULL;
else
{
@@ -790,7 +791,9 @@ has_finalizer_component (gfc_symbol *derived)
static bool
comp_is_finalizable (gfc_component *comp)
{
- if (comp-attr.allocatable comp-ts.type != BT_CLASS)
+ if (comp-attr.proc_pointer)
+return false;
+ else if (comp-attr.allocatable comp-ts.type != BT_CLASS)
return true;
else if (comp-ts.type == BT_DERIVED !comp-attr.pointer
(comp-ts.u.derived-attr.alloc_comp
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c(revision 207823)
+++ gcc/fortran/decl.c(working copy)
@@ -1199,7 +1199,7 @@ build_sym (const char *name, gfc_charlen *cl, bool
sym-attr.implied_index = 0;
if (sym-ts.type == BT_CLASS)
-return gfc_build_class_symbol (sym-ts, sym-attr, sym-as, false);
+return gfc_build_class_symbol (sym-ts, sym-attr, sym-as, true);
return true;
}
This should be free of testsuite failures.
[Bug tree-optimization/60236] gfortran.dg/vect/pr32380.f fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236 --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- ERROR: gfortran.dg/vect/pr32380.f -O : error executing dg-final: syntax error in target selector ! target vect_call_sqrtf what is the right syntax here??
[Bug fortran/58861] Realloc on assignment: Bogus Array bound mismatch error with -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58861 Adam Hirst adam at aphirst dot karoo.co.uk changed: What|Removed |Added CC||adam at aphirst dot karoo.co.uk --- Comment #3 from Adam Hirst adam at aphirst dot karoo.co.uk --- Created attachment 32154 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32154action=edit Failed realloc with -fcheck Here's another realloc-on-assign case which fails with -fcheck, but works without. I was going to submit a new bug report, but thankfully I found this existing one instead.
[Bug fortran/60234] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1883
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234 --- Comment #7 from janus at gcc dot gnu.org --- I think it should be possible (and preferable) to always defer the building of the vtab, and not only partially as in comment 6. Will try to do that ...
[Bug ipa/60243] New: IPA is slow on large cgraph tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
Bug ID: 60243
Summary: IPA is slow on large cgraph tree
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
I've built that testcase to show quadraticness in ipa_modify_call_arguments
calls to update_ssa:
#!/bin/sh
for i in `seq $1`; do
echo static void test$i (int);
done
for i in `seq $1`; do
echo void test$i (int i) {
echo asm (\\:::\memory\);
for j in `seq $i $1`; do
if ! test $i == $j; then
echo test$j (i);
fi
done
echo }
done
echo int main() { test1 (5); return 0; }
but curiously I see (for 1000 and using 4.8):
ipa inlining heuristics : 2.78 ( 6%) usr 0.02 ( 0%) sys 2.80 ( 5%) wall
1546 kB ( 0%) ggc
ipa profile : 14.34 (29%) usr 0.01 ( 0%) sys 14.35 (25%) wall
0 kB ( 0%) ggc
ipa SRA : 2.32 ( 5%) usr 2.09 (34%) sys 4.49 ( 8%) wall
281101 kB (32%) ggc
tree SSA rewrite: 0.54 ( 1%) usr 0.68 (11%) sys 1.99 ( 4%) wall
87933 kB (10%) ggc
tree SSA incremental: 0.02 ( 0%) usr 0.02 ( 0%) sys 0.07 ( 0%) wall
0 kB ( 0%) ggc
TOTAL : 49.83 6.1056.55
883870 kB
that's because all affected bodies are not yet in SSA form ... heh. So
that part may not be a real issue.
But the IPA profile part? At -O2?
[Bug ipa/60243] IPA is slow on large cgraph tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- -O2 -fno-inline
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- While preparing a test case, I have been hit by another snag!-( With the trunk and 4.8, the following test write(*,(en15.2)) 98765. write(*,(en15.3)) 9876.5 write(*,(en15.1)) 987.65 write(*,(en15.2)) 98.765 write(*,(en15.3)) 9.8765 write(*,(en15.1)) .98765 write(*,(en15.2)) .098765 write(*,(en15.3)) .0098765 write(*,(en15.1)) .00098765 write(*,(en15.2)) .98765 write(*,(en15.2)) 98735. write(*,(en15.3)) 9873.5 write(*,(en15.1)) 987.35 write(*,(en15.2)) 98.735 write(*,(en15.3)) 9.8735 write(*,(en15.1)) .98735 write(*,(en15.2)) .098735 write(*,(en15.3)) .0098735 write(*,(en15.1)) .00098735 write(*,(en15.2)) .98735 end gives the following output at run time 98.76E+03 9.876E+03 990.0E+00- wrong 98.76E+00 9.876E+00 990.0E-03- wrong 98.77E-03 9.876E-03 990.0E-06- wrong 98.76E-06 98.73E+03 9.873E+03 990.0E+00- wrong 98.73E+00 9.873E+00 990.0E-03- wrong 98.73E-03 9.873E-03 990.0E-06- wrong 98.73E-06 while 4.7 gives 98.77E+03 9.877E+03 987.7E+00 98.76E+00 9.877E+00 987.6E-03 98.77E-03 9.876E-03 987.7E-06 98.76E-06 98.74E+03 9.874E+03 987.3E+00 98.74E+00 9.873E+00 987.3E-03 98.73E-03 9.874E-03 987.4E-06 98.73E-06 The reason of these wrong code is due to the rounding of x between 0.95*10**d and 1.0*10**d to 1.*10**d. it follows that the exponent returned by 'nprinted = DTOA(y,0,tmp);' in '#define EN_PREC(x,y)' is the actual exponent 'e' plus one. I don't understand why this affects only the cases 'e%3==0' and I have no idea how this can be fixed - any help welcomed!. Note that for the working cases I am not fully happy with the rounding: at least for 98765., 9876.5, 98735., and 9873.5 which have no rounding errors, I am expecting with round to even on tie: 98.76E+03, 98.76E+03, 98.74E+03, and 98.74E+03.
[Bug inline-asm/60242] incorrect optimization of code with inline assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60242 cerealguy at yandex dot ru changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from cerealguy at yandex dot ru --- (In reply to Richard Biener from comment #1) You fail to tell GCC that your asm clobbers memory. Right
[Bug bootstrap/60244] New: GCC-trunk rev.207809, Segmentation fault when executing .../xgcc -dumpspecs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60244 Bug ID: 60244 Summary: GCC-trunk rev.207809, Segmentation fault when executing .../xgcc -dumpspecs Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: i.nixman at autistici dot org configure options: ../../../src/gcc-trunk/configure \ --host=i686-w64-mingw32 \ --build=i686-w64-mingw32 \ --target=i686-w64-mingw32 \ --prefix=/mingw32 \ --with-sysroot=/d/mingwtrunk/i686-trunk-posix-dwarf-rt_v4/mingw32 \ --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ \ --enable-shared \ --enable-static \ --disable-multilib \ --enable-languages=c,c++,lto \ --enable-libstdcxx-time=yes \ --enable-threads=posix \ --enable-libgomp \ --enable-lto \ --enable-graphite \ --enable-checking=release \ --enable-fully-dynamic-string \ --enable-version-specific-runtime-libs \ --disable-sjlj-exceptions \ --with-dwarf2 \ --disable-isl-version-check \ --disable-cloog-version-check \ --disable-libstdcxx-pch \ --disable-libstdcxx-debug \ --enable-bootstrap \ --disable-rpath \ --disable-win32-registry \ --disable-nls \ --disable-werror \ --disable-symvers \ --with-gnu-as \ --with-gnu-ld \ --with-arch=i686 \ --with-tune=generic \ --with-libiconv \ --with-system-zlib \ --enable-cloog-backend=isl Previously, I've successfully built GCC-trunk rev.205009 with the same options. Also, I've successfully built rev.207809 as x86_64-posix-sjlj i686-posix-sjlj. That is I suspect that the reason is that the problem occurred with the build using DWARF.
[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Isn't it an ODR violation if UnicodeString::extractBetween inline has different definition between unorm.ii and uniset.ii? In any case, the bug reported here seems to be unrelated to that. Anyway, from what I see, here is what happens: 1) uniset.ii UnicodeString::extractBetween is being streamed by cc1plus, including debug stmts, so gets high uid (in my case uid 45 and lto_stmt_uid for the corresponding edge is streamed as 46 (+1)). 2) now, when the first lto1 invocation happens (is that WPA pass, right), it first reads all the stmts, then drop debug stmts after assinging uids (ok) 3) next: #3 0x0064790c in build_function_decl_skip_args (orig_decl=0x71a1ac00, args_to_skip=0x71a2d240, skip_return=false) at ../../gcc/cgraphclones.c:375 #4 0x00647bef in cgraph_create_virtual_clone (old_node=0x71a2b668, redirect_callers=..., tree_map=0x71a33488, args_to_skip=0x71a2d240, suffix=0x1590c10 constprop) at ../../gcc/cgraphclones.c:433 #5 0x011579d9 in create_specialized_node (node=0x71a2b668, known_vals=..., aggvals=0x0, callers=...) at ../../gcc/ipa-cp.c:2790 #6 0x01159755 in decide_whether_version_node (node=0x71a2b668) at ../../gcc/ipa-cp.c:3545 versions the UnicodeString::extractBetween function, but nothing allocates DECL_STRUCT_FUNCTION for it - it supposedly inherits the body of the master 4) then output_function is called on the original UnicodeString::extractBetween (not the clone), this reassigns stmt uids, and as 2) dropped the debug stmts already, the call stmt in there gets much smaller uid (25) 5) finally, lto_output_edge is called, and does: uid = (!gimple_has_body_p (edge-caller-decl) ? edge-lto_stmt_uid : gimple_uid (edge-call_stmt) + 1); but here edge-caller-decl is the clone of UnicodeString::extractBetween, rather than original, it has NULL DECL_STRUCT_FUNCTION and thus gimple_has_body_p returns false for it and it happily uses the now completely out of bound lto_stmt_uid (46), rather than the right one (25+1). Now, I wonder if it isn't always safe to use gimple_uid (edge-call_stmt) + 1 here if edge-call_stmt is non-NULL, or e.g. if we need to look through clone_of pointers to find ultimate clone and check gimple_has_body_p on that, or loop through clone_of pointers and stop on the first one where gimple_has_body_p returns true, something else? Honza?
[Bug c++/60241] [4.7/4.8/4.9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:2617
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Likely caused by r149188 (r149186 works, r149196 fails).
[Bug middle-end/60221] [4.7/4.8/4.9 Regression] gcc -fexceptions generates unnecessary cleanup code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221 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'm not aware of a dup, but this has been recently discussed on gcc-patches, see the http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01200.html thread.
[Bug c/60197] ICE with _Cilk_spawn in expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60197 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-02-17 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. I believe the testcase is invalid as _Cilk_spawn can't be in a return statement. I have a patch.
[Bug middle-end/60214] Variables with same DECL_ASSEMBLER_NAME are treated as different variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60214 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 --- Well, the question is if we want to change the status quo here at all, looking through the asm redirects breaks quite a lot of things as well, consider PR59626 etc. I'd say it is a user error to refer to the same underlying variable through different variables.
[Bug c++/60225] [4.9 Regression] [c++11] ICE initializing constexpr array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60225 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||paolo at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r204164.
[Bug c++/60237] isnan fails with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237 --- Comment #6 from N Schaeffer nathanael.schaeffer at gmail dot com --- -fno-builtin-isnan is also interesting, thanks. Is there somewhere a rationale for not making isnan() find NaN's with -ffinite-math-only ?
[Bug c++/60224] [4.7/4.8/4.9 Regression] ICE using invalid initializer for array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60224 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-17 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, even 4.1.x seems to ICE with checking enabled, the ICE in check_array_designated_initializer started in between r119500 and r12.
[Bug c++/60227] [4.7/4.8/4.9 Regression] [C++11] ICE using brace-enclosed initializer list to initialize array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60227 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Most likely r171614 (r171600 works, r171625 ICEs).
[Bug target/41076] [avr] pessimal code for logical OR of 8-bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41076 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||matthijs at stdin dot nl --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org --- *** Bug 60145 has been marked as a duplicate of this bug. ***
[Bug other/60145] [AVR] Suboptimal code for byte order shuffling using shift and or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60145 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- Looks like PR41076 *** This bug has been marked as a duplicate of bug 41076 ***
[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- Seems like PR58545 *** This bug has been marked as a duplicate of bug 58545 ***
[Bug rtl-optimization/58545] [4.7/4.8 Regression] error: unable to find a register to spill in class 'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58545 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org --- *** Bug 60040 has been marked as a duplicate of this bug. ***
[Bug other/56183] [meta-bug][avr] Problems with register allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183 Bug 56183 depends on bug 60040, which changed state. Bug 60040 Summary: AVR: error: unable to find a register to spill in class 'POINTER_REGS' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/60245] New: Template static function not accepted as constexpr parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245
Bug ID: 60245
Summary: Template static function not accepted as constexpr
parameter
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: florent.hivert at lri dot fr
GCC is not able to compile the following code
#include array
using Ar = std::arrayunsigned long, 10;
templatetypename T
constexpr T Apply(const T in, T (*f)(const T)) { return f(in); }
static constexpr Ar id(const Ar line) { return line; }
static constexpr Ar ar1 = {{1}};
static constexpr Ar results1 = ApplyAr(ar1, id);
It complains that
bug4.cpp:10:50: in constexpr expansion of ‘Applystd::arraylong unsigned
int, 10ul ((* ar1), id)’
bug4.cpp:6:63: error: expression ‘id’ does not designate a constexpr function
constexpr T Apply(const T in, T (*f)(const T)) { return f(in); }
This seems to be a problem with template substitution since manually
specializing the template makes the error vanish:
#include array
using Ar = std::arrayunsigned long, 10;
templatetypename T
constexpr T Apply(const T in, T (*f)(const T)) { return f(in); }
// manual specialization:
template
constexpr Ar ApplyAr(const Ar in, Ar (*f)(const Ar)) { return f(in); }
static constexpr Ar id(const Ar line) { return line; }
static constexpr Ar ar1 = {{1}};
static constexpr Ar results1 = ApplyAr(ar1, id);
System informations:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.8 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux)
[Bug c++/60245] Template static function not accepted as constexpr parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245 --- Comment #1 from Florent Hivert florent.hivert at lri dot fr --- Created attachment 32155 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32155action=edit preprocessed code
[Bug ipa/60243] IPA is slow on large cgraph tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
So:
#define A(n) static void test##n (int);
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7)
C(n##8) C(n##9)
D(1)
#undef A
#define E(m, n) if (n m) test##n (i);
#define F(m, n) E(m, n##0) E(m, n##1) E(m, n##2) E(m, n##3) E(m, n##4) E(m,
n##5) E(m, n##6) E(m, n##7) E(m, n##8) E(m, n##9)
#define G(m, n) F(m, n##0) F(m, n##1) F(m, n##2) F(m, n##3) F(m, n##4) F(m,
n##5) F(m, n##6) F(m, n##7) F(m, n##8) F(m, n##9)
#define H(m, n) G(m, n##0) G(m, n##1) G(m, n##2) G(m, n##3) G(m, n##4) G(m,
n##5) G(m, n##6) G(m, n##7) G(m, n##8) G(m, n##9)
#define A(n) \
static void test##n (int i)\
{\
asm ( : : : memory);\
H(n, 1)\
}
D(1)
int
main ()
{
test1000 (5);
return 0;
}
so that we have something for the testsuite?
[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- Even at -O3 we inline only functions that either can not be interposed (i.e. static or -fno-pic) or are known to be same everywhere (comdat and functions declared inlined). I was considering command line option -fno-semantic-interposition to control this. Perhaps it is a good idea. In C++ context I am not really that convinced interposition makes much sense though. In real life, 99.9% symbols will never be interposed by a symbol with different semantic and I would say that all of them will be C symbols (malloc). Given that ELF decided to allow interposition to everything by default, we need to play safe. I tried to discuss in http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01509.html the consequences of One Definition Rule that IMO prevents two different implementations of one template coexist in one program. But I lost the case and the conclusion was that if you fully interpose out one instantiation by another, OND rule works.
[Bug c++/60245] Template static function not accepted as constexpr parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245
--- Comment #2 from Florent Hivert florent.hivert at lri dot fr ---
Sorry ! The version I submitted is not the most reduced. Here is a version not
using vectors:
constexpr int Apply(const int in, int (*f)(const int)) { return f(in); }
using Foo = int;
static constexpr int id(const Foo i) { return i; }
static constexpr int results1 = Apply(0, id);
Note: Replacing the Foo by int in the definition of id makes the problem
vanish.
[Bug c++/60237] isnan fails with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237 --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to N Schaeffer from comment #6) Is there somewhere a rationale for not making isnan() find NaN's with -ffinite-math-only ? finite-math-only is basically a promise that isinf and isnan always return false... I have inline library functions that do: if (isnan(x)) ... When compiled with -ffinite-math-only, I want this eliminated as dead code, that's the reason I made the function inline in the first place. Another way to cheat: int myisnan(double)__asm__(isnan);
[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235 --- Comment #5 from Mehdi Amini joker.eph at gmail dot com --- (In reply to Jakub Jelinek from comment #2) The specialization is a regular function, not comdat, thus it is not appropriate to inline it at -O2 -fpic, only -O3 is inlining functions regardless to whether they could be interposed or not, or for -O2 without -fpic because the symbol can't be interposed. Or use the inline keyword for the specialization. As I understand your comment, O2 does not inline because of interposition possibility, but O3 should break interposition? Note that -O3 does not inline here either by the way. Considering the (potentially huge) impact on the runtime, there should be a GCC flag to disable safe interposition at compile time, as this feature isn't use most of the time (I think). Unless you want to follow this path, you can close this bug as won't fix. It is interesting to see that Clang does not seem to care about interposition since the call disappears starting at O2.
[Bug c++/60146] [4.8/4.9 Regression] ICE when compiling this code with -fopenmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60146 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- decl in this case in tsubst_omp_for_iterator is i, and init is DECL_EXPR i, i has DECL_INITIAL set to the function call. RECUR on both of these will tsubst the initializer before the loop, rather than in the loop, thus init is later on NULL. For #pragma omp for we really need the initializer. I'm afraid I haven't understood fully the PR53565 fix though.
[Bug c++/60225] [4.9 Regression] [c++11] ICE initializing constexpr array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60225
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Thus, it seems to me that to have a consistent literal_type_p /
ensure_literal_type_for_constexpr_object pair we should use strip_array_types
in the latter too. The below passes testing, for example:
Index: semantics.c
===
--- semantics.c(revision 207817)
+++ semantics.c(working copy)
@@ -7380,7 +7380,8 @@ ensure_literal_type_for_constexpr_object (tree dec
if (VAR_P (decl) DECL_DECLARED_CONSTEXPR_P (decl)
!processing_template_decl)
{
- if (CLASS_TYPE_P (type) !COMPLETE_TYPE_P (complete_type (type)))
+ tree stype = strip_array_types (type);
+ if (CLASS_TYPE_P (stype) !COMPLETE_TYPE_P (complete_type (stype)))
/* Don't complain here, we'll complain about incompleteness
when we try to initialize the variable. */;
else if (!literal_type_p (type))
[Bug debug/60246] New: Emit debug info for explicit template instantiation definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60246
Bug ID: 60246
Summary: Emit debug info for explicit template instantiation
definitions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
CC: echristo at gmail dot com
A possible size optimization for debug info exists whenever an explicit
template instantiation declaration/definition is present.
If, in the translation unit that contains the explicit instantiation
definition, the full type is always emitted, then in the instantiation
declaration translation units the definition can be omitted in favor of just a
declaration.
I haven't done the analysis to see how valuable this is, but for simple things
like std::string it should fire and save a slew of debug info in consumers.
The problem is that this isn't backwards compatible (if the optimization is
done on the basis of declarations some debug info from (albeit
unnecessary/unuseful) explicit instantiations will be lost).
If the explicit instantiation declaration is actually useful (saves on code
emission in the declaration translation units and causes code to be emitted in
the defining translation unit) then this optimization is safe already - the
emission of the code for the member function will cause the type to be emitted
there.
But in the degenerate case such as:
templatetypename T
struct foo {
// neither of these members would cause code to be emitted
int i;
void f1();
// void f2() {} // this would though
};
// templatetypename T void fooT::f1() { } // or this
template struct fooint;
no functions are emitted (so the explicit instantiation decl/def was pointless,
but someone might write this) and thus the assumption fails and debug info is
broken (no translation unit ends up with the definition of 'fooint').
The first step is to ensure that the definition is always emitted in a
translation unit with an explicit template instantiation definition. Then at
some point in the future its presence can be assumed and explicit instantiation
declarations can be optimized more aggressively.
[Bug libstdc++/10350] thread-safety problem in std::string.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10350 --- Comment #12 from owner at bugs dot debian.org --- Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian GCC Maintainers debian-...@lists.debian.org If you wish to submit further information on this problem, please send it to 140...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
