[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 --- Comment #5 from Jakub Jermar jakub at jermar dot eu 2012-07-16 06:18:55 UTC --- (In reply to comment #1) Without a test case on a platform that is supported in GCC, there isn't much anyone can do to help. Can you reproduce this on linux or hpux? BTW, are there plans to contribute HelenOS support to FSF GCC? Well, we are squatting on ia64-pc-linux-gnu-gcc to build HelenOS, so this is reproducible on Linux (no HelenOS-specific support exists). The testcase is our 'image.boot' loader program, but it's kind of huge. Even the function which contains this issue, i.e. printf_core(), is pretty huge and inlines lots of other functions.
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 --- Comment #6 from Jakub Jermar jakub at jermar dot eu 2012-07-16 06:28:29 UTC --- (In reply to comment #4) Ah, of course the move branch register instruction faults if the NaT bit of the source register is set. So the recovery code is irrelevant, and this could be a GCC bug. Need a test case to investigate, though... Exactly. The problem is that the NaT bit cannot propagate any further when the new destination is a branch register and so the exception can no longer remain deferred. As for the test case, once you have the toolchain in place, the easiest way to reproduce this is simply to build HelenOS and disassemble the image.boot binary around the addresses above. I'd be more than happy to provide assistance with this. If tinkering with the entire HelenOS is not plausible, I can try to separate at least the printf_core() into a separately buildable testcase.
[Bug tree-optimization/45978] [4.6 Regression] bogus array subscript is above array bounds warning in extremely simple code with no loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45978 --- Comment #11 from Petr.Salinger at seznam dot cz 2012-07-16 06:48:07 UTC --- Created attachment 27800 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27800 testcase Another failing testcase - reduced from xserver-xorg-input-mouse
[Bug tree-optimization/53198] [4.6/4.7 Regression] gcc wrongly emits array subscript is above array bounds for simple arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53198 --- Comment #3 from Petr.Salinger at seznam dot cz 2012-07-16 07:28:26 UTC --- Created attachment 27801 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27801 another testcase - from xorg mouse driver
[Bug fortran/53977] New: CPP: Support __func__/__FUNCTION__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53977 Bug #: 53977 Summary: CPP: Support __func__/__FUNCTION__ Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org As requested at http://gcc.gnu.org/ml/fortran/2012-07/msg00054.html It would be useful to provide the name of the current procedure when using -cpp via __func__/__FUNCTION__. From the GCC's CPP manual: C99 introduces __func__, and GCC has provided __FUNCTION__ for a long time. Both of these are strings containing the name of the current function (there are slight semantic differences; see the GCC manual). Neither of them is a macro; the preprocessor does not know the name of the current function. They tend to be useful in conjunction with __FILE__ and __LINE__, though. http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
[Bug fortran/53977] CPP: Support __func__/__FUNCTION__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53977 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-16 07:50:21 UTC --- See also http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html for how that's implemented in C.
[Bug fortran/53977] CPP: Support __func__/__FUNCTION__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53977 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-16 08:14:15 UTC --- A quick test of other Fortran compilers shows that this is not a widely supported feature - none of the tried compilers supports it. In C, it falls semantically into the preprocessor, even though it is implemented as compiler feature. In terms of the form, gcc's __FUNCTION__ looks much more like a CPP macro than C99's __func__. (As CPP is not a Fortran-tuned preprocessor, the semantic - when applied to Fortran - is a bit unclear as are features like C99's __func__.)
[Bug target/53961] internal compiler error: in memory_address_length, at config/i386/i386.c:23341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53961 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Uros Bizjak ubizjak at gmail dot com 2012-07-16 08:44:29 UTC --- .
[Bug fortran/53956] [F03] PROCEDURE w/ interface: Bogus EXTERNAL attribute conflicts with FUNCTION attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53956 --- Comment #4 from janus at gcc dot gnu.org 2012-07-16 08:45:56 UTC --- (In reply to comment #3) ... and therefore an alternative (and probably preferable) patch would be: The patch in comment #3 generates the correct if_source for c2, but a wrong one for fp: Since it is just copied from sub it becomes IFSRC_IFBODY, but it should be IFSRC_DECL.
[Bug rtl-optimization/53908] [4.6 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 --- Comment #19 from Steven Bosscher steven at gcc dot gnu.org 2012-07-16 09:36:11 UTC --- Author: steven Date: Mon Jul 16 09:36:04 2012 New Revision: 189512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189512 Log: Backport from trunk: gcc/ PR rtl-optimization/53908 * df-problems.c (can_move_insns_across): When doing memory-reference book-keeping, handle call insns. testsuite/ PR rtl-optimization/53908 * gcc.dg/torture/pr53908.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr53908.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/df-problems.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/53970] -ftree-vectorization does not handle well unaligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53970 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |ASSIGNED Keywords||wrong-code Last reconfirmed||2012-07-16 Component|c++ |tree-optimization AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Known to fail||4.6.3, 4.7.1, 4.8.0 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 09:40:20 UTC --- Confirmed, mine.
[Bug other/53969] internal compiler error: Segmentation fault on Android(use NDK)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53969 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 09:42:18 UTC --- In file included from jni/../../../source/Irrlicht/CImage.cpp:8: also please provide pre-processed source of CImage.cpp. See gcc.gnu.org/bugs.html.
[Bug tree-optimization/53966] procmail build deadloop on _autotst -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53966 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-16 Ever Confirmed|0 |1
[Bug middle-end/53959] [4.8 Regression] 189.lucas in SPEC CPU 2000 miscompiled by LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53959 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-16 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 09:46:29 UTC --- Probably a dup.
[Bug c++/53954] [C++11] Undefined reference to non-odr-used static const member variable of variadic class template in DSO with -flto and -Wl,--export-dynamic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53954 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 09:49:59 UTC --- Not sure what happens here, but I believe not odr-using value does not make the definition not necessary.
[Bug regression/53953] [4.7/4.8 Regression]: g++.dg/cpp0x/lambda/lambda-ice2.C (warnings and errors not matching)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53953 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug c++/53954] [C++11] Undefined reference to non-odr-used static const member variable of variadic class template in DSO with -flto and -Wl,--export-dynamic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53954 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 09:54:18 UTC --- (In reply to comment #0) When a DSO is created from this code with `-std=c++11', `-lfto' and `-Wl,--export-dynamic' options, it requires the definition of `std::allocator_traitsstd::allocatorint ::__construct_helperint, int::value'. Ah, that's actually a bug in my libstdc++ code, the definition should be present.
[Bug other/53969] internal compiler error: Segmentation fault on Android(use NDK)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53969 --- Comment #4 from zhangbin vincent_zhangbin at hotmail dot com 2012-07-16 09:56:15 UTC --- Created attachment 27802 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27802 the C file Please see the attach CImage.cpp.
[Bug libstdc++/53978] New: Missing static const definitions in bits/alloc_traits.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53978 Bug #: 53978 Summary: Missing static const definitions in bits/alloc_traits.h Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: r...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org As pointed out in PR 53954 there are no definitions for the static members such as allocator_traits::__construct_helper::value
[Bug libstdc++/53978] Missing static const definitions in bits/alloc_traits.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53978 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-16 Target Milestone|--- |4.7.2 Ever Confirmed|0 |1
[Bug c++/53954] [C++11] Undefined reference to non-odr-used static const member variable of variadic class template in DSO with -flto and -Wl,--export-dynamic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53954 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 09:58:57 UTC --- I've created PR 53978 for the libstdc++ fixes
[Bug fortran/53956] [F03] PROCEDURE w/ interface: Bogus EXTERNAL attribute conflicts with FUNCTION attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53956 --- Comment #5 from janus at gcc dot gnu.org 2012-07-16 10:13:26 UTC --- Author: janus Date: Mon Jul 16 10:13:19 2012 New Revision: 189514 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189514 Log: 2012-07-16 Janus Weil ja...@gcc.gnu.org PR fortran/53956 * gfortran.h (gfc_copy_formal_args,gfc_copy_formal_args_ppc): Modified prototypes. * symbol.c (gfc_copy_formal_args): New argument 'if_src'. Copy if_source of dummy procedures. (gfc_copy_formal_args_ppc): Ditto. * resolve.c (resolve_procedure_interface): Pass IFSRC_DECL to gfc_copy_formal_args. (resolve_fl_derived0): Pass IFSRC_DECL to gfc_copy_formal_args_ppc. 2012-07-16 Janus Weil ja...@gcc.gnu.org PR fortran/53956 * gfortran.dg/proc_decl_28.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/53956] [F03] PROCEDURE w/ interface: Bogus EXTERNAL attribute conflicts with FUNCTION attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53956 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from janus at gcc dot gnu.org 2012-07-16 10:17:37 UTC --- Fixed with r189514. Closing.
[Bug fortran/53885] seg. fault during assignment to allocatable component within type-bounded proc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53885 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from janus at gcc dot gnu.org 2012-07-16 10:22:32 UTC --- Closing as fixed.
[Bug tree-optimization/53979] New: (a^b^b) not simplified to (a) (in combination with CSE??)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53979
Bug #: 53979
Summary: (a^b^b) not simplified to (a) (in combination with
CSE??)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vermaelen.wou...@gmail.com
The following 3 functions should ideally generate identical code (and they do
when using clang).
int f1(int a, int b) {
int c = b;
return (a ^ b ^ c) | (a ^ b) | a;
}
int f2(int a, int b) {
return (a ^ b) | a;
}
int f3(int a, int b) {
return a | b;
}
I tested gcc revision trunk@189510 and it shows 2 missed optimizations:
1) (a ^ b ^ b) not simplified to (a)
Normally gcc performs this optimization, but I *guess* it misses it here
because of the CSE opportunity with (a ^ b).
2) ((a ^ b) | a) not simplified to (a | b)
Of course in this example it's easy to manually rewrite the code. But in my
original code this function was actually a template and for some instantiations
the expression for the variable 'c' simplified to just 'b'. So the first missed
optimization is something I saw in real code. The second missed optimization
only occurs in this (much) simplified variant of the function.
[Bug lto/53895] [4.7/4.8 Regression][lto] symbol 'std::__once_callable' used as both __thread and non-__thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53895 Marc Dietrich marvin24 at gmx dot de changed: What|Removed |Added CC||marvin24 at gmx dot de --- Comment #4 from Marc Dietrich marvin24 at gmx dot de 2012-07-16 11:12:42 UTC --- also triggered when compiling mesa with -ftlo: g++ -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -O2 -flto=jobserver -fPIC -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0301 -fvisibility=hidden -o r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp ../../../../lib64/libdricore8.1.0.so -ldrm -lexpat -lm -lpthread -ldl -ldrm_radeon -march=barcelona -Ofast -flto=jobserver -L/usr/lib -lpthread -ldl -lm ; /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: error: r600_dri.so.tmp: symbol '_glapi_tls_Context' used as both __thread and non-__thread /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: ../../../../src/mesa/drivers/dri/common/dri_test.o: previous definition here /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: error: r600_dri.so.tmp: symbol '_glapi_tls_Dispatch' used as both __thread and non-__thread /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: ../../../../src/mesa/drivers/dri/common/dri_test.o: previous definition here /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: error: ../../../../lib64/libdricore8.1.0.so: symbol '_glapi_tls_Context' used as both __thread and non-__thread /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: ../../../../src/mesa/drivers/dri/common/dri_test.o: previous definition here /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: error: ../../../../lib64/libdricore8.1.0.so: symbol '_glapi_tls_Dispatch' used as both __thread and non-__thread /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: ../../../../src/mesa/drivers/dri/common/dri_test.o: previous definition here on openSUSE 12.2 (factory): ld --version - GNU gold (GNU Binutils; openSUSE Factory 2.22) 1.11 gcc --version - gcc (SUSE Linux) 4.7.1 20120615 [gcc-4_7-branch revision 188649]
[Bug rtl-optimization/53942] [4.6/4.7/4.8 Regression] unable to find a register to spill in class 'CREG'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53942
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 2012-07-16
11:31:59 UTC ---
C testcase for just -O2 -m32 -mtune=pentium2:
struct S
{
unsigned short data[3];
unsigned int x;
unsigned int y;
};
struct S *baz (void);
__attribute__ ((noinline))
static unsigned char
foo (struct S *x, unsigned char y)
{
unsigned char c = 0;
unsigned char v = x-data[0];
c |= v;
v = ((x-data[1]) (1 y)) ? 1 : 0;
c |= v 1;
v = ((x-data[2]) 0xff) (1 y);
c |= v 2;
return c;
}
void
bar (void)
{
struct S *s = baz ();
s-x = foo (s, 6);
s-y = foo (s, 7);
}
cant_combine_insn_p already handles hard regs likely spilled correctly if they
are just seen in a simple register move, unfortunately in this case there is no
simple reg move, but instead a zero extension already in the *.expand dump:
(insn 4 3 5 2 (set (reg:SI 80 [ ISRA.4 ])
(zero_extend:SI (reg:HI 2 cx [ ISRA.4 ]))) pr53942.c:12 -1
(nil))
I wonder if either we shouldn't force the HI cx register first into pseudo and
have separate zero extension afterwards (the other alternative would be if we
have a zero or sign extension from hard register likely spilled, force the hard
register into a pseudo in the combiner at the spot where it used to be zero
extended).
[Bug rtl-optimization/53942] [4.6/4.7/4.8 Regression] unable to find a register to spill in class 'CREG'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53942
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-07-16
11:54:23 UTC ---
The following patch fixes this issue during expansion, don't have time right
now to test what effects it might have on generated code though:
--- gcc/function.c.jj2012-06-25 08:38:26.0 +0200
+++ gcc/function.c2012-07-16 13:41:52.847928315 +0200
@@ -2988,11 +2988,26 @@ assign_parm_setup_reg (struct assign_par
insn_operand_matches (icode, 1, op1))
{
enum rtx_code code = unsignedp ? ZERO_EXTEND : SIGN_EXTEND;
- rtx insn, insns;
+ rtx insn, insns, t = op1;
HARD_REG_SET hardregs;
start_sequence ();
- insn = gen_extend_insn (op0, op1, promoted_nominal_mode,
+ /* If op1 is a hard register that is likely spilled, first
+ force it into a pseudo, otherwise combiner might extend
+ its lifetime too much. */
+ if (GET_CODE (t) == SUBREG)
+t = SUBREG_REG (t);
+ if (REG_P (t)
+ HARD_REGISTER_P (t)
+ ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (t))
+ targetm.class_likely_spilled_p (REGNO_REG_CLASS (REGNO (t
+{
+ t = gen_reg_rtx (GET_MODE (op1));
+ emit_move_insn (t, op1);
+}
+ else
+t = op1;
+ insn = gen_extend_insn (op0, t, promoted_nominal_mode,
data-passed_mode, unsignedp);
emit_insn (insn);
insns = get_insns ();
[Bug bootstrap/53980] New: [4.8 Regression] Bootstrap fails in stage 1: i386.md:17784:3: error: 'OPTION_BIONIC' undeclared here (not in a function) in build/gencondmd.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53980 Bug #: 53980 Summary: [4.8 Regression] Bootstrap fails in stage 1: i386.md:17784:3: error: 'OPTION_BIONIC' undeclared here (not in a function) in build/gencondmd.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: rai...@emrich-ebersheim.de Bootstrap fails in stage 1 for x86_64-w64-mingw32: gcc -c -g -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../src/gcc-4.8.0/gcc -I../../../src/gcc-4.8.0/gcc/build -I../../../src/gcc-4.8.0/gcc/../include -I./../intl -I../../../src/gcc-4.8.0/gcc/../libcpp/include -I/SCRATCH/tmp.xipisatGtI/install/include -I/SCRATCH/tmp.xipisatGtI/install/include -I/SCRATCH/tmp.xipisatGtI/install/include -I../../../src/gcc-4.8.0/gcc/../libdecnumber -I../../../src/gcc-4.8.0/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_INT_GMP -I/SCRATCH/tmp.xipisatGtI/install/include -I/SCRATCH/tmp.xipisatGtI/install/include \ -o build/gencondmd.o build/gencondmd.c ../../../src/gcc-4.8.0/gcc/config/i386/i386.md:17784:3: error: 'OPTION_BIONIC' undeclared here (not in a function) ../../../src/gcc-4.8.0/gcc/config/i386/i386.md:920:5: warning: missing initializer [-Wmissing-field-initializers] ../../../src/gcc-4.8.0/gcc/config/i386/i386.md:920:5: warning: (near initialization for 'insn_conditions[657].value') [-Wmissing-field-initializers] ../../../src/gcc-4.8.0/gcc/config/i386/i386.md:17755:5: warning: missing initializer [-Wmissing-field-initializers] ../../../src/gcc-4.8.0/gcc/config/i386/i386.md:17755:5: warning: (near initialization for 'insn_conditions[1097].value') [-Wmissing-field-initializers] ../../../src/gcc-4.8.0/gcc/config/i386/i386.md:920:5: warning: missing initializer [-Wmissing-field-initializers] ../../../src/gcc-4.8.0/gcc/config/i386/i386.md:920:5: warning: (near initialization for 'insn_conditions[1177].value') [-Wmissing-field-initializers] make[3]: *** [build/gencondmd.o] Error 1 make[3]: Target `all' not remade because of errors. make[3]: Leaving directory `/SCRATCH/tmp.xipisatGtI/gcc-4.8.0/gcc-4.8.0/gcc'
[Bug target/53980] [4.8 Regression] Bootstrap fails in stage 1: i386.md:17784:3: error: 'OPTION_BIONIC' undeclared here (not in a function) in build/gencondmd.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53980 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Component|bootstrap |target Target Milestone|--- |4.8.0
[Bug other/53969] internal compiler error: Segmentation fault on Android(use NDK)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53969 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 12:34:40 UTC --- Please attach _preprocessed_ source.
[Bug middle-end/53959] [4.8 Regression] 189.lucas in SPEC CPU 2000 miscompiled by LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53959 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-07-16 12:35:16 UTC --- Author: hjl Date: Mon Jul 16 12:35:10 2012 New Revision: 189528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189528 Log: Restore type attribute comparison PR middle-end/53959 PR bootstrap/53963 * gimple.c (gimple_types_compatible_p_1): Restore type attribute comparison. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c
[Bug bootstrap/53963] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53963 --- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-07-16 12:35:18 UTC --- Author: hjl Date: Mon Jul 16 12:35:10 2012 New Revision: 189528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189528 Log: Restore type attribute comparison PR middle-end/53959 PR bootstrap/53963 * gimple.c (gimple_types_compatible_p_1): Restore type attribute comparison. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-16 Ever Confirmed|0 |1 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 12:42:15 UTC --- What options do you use besides -march=corei7-avx? The build-log does not tell. Did you try -march=corei7 instead of -march=corei7-avx?
[Bug tree-optimization/32378] can't determine dependence (distinct sections of an array)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 13:02:49 UTC --- Fixed - vectorized with versioning for aliasing (consider n == 4). The testcase from comment#6 is PR32375.
[Bug tree-optimization/32375] not vectorized: can't determine dependence (array sections)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32375
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16
13:03:10 UTC ---
The issue is that we have
bb 5:
# j_2 = PHI 2(4), j_30(10)
pretmp.38_71 = (integer(kind=8)) j_2;
pretmp.38_72 = stride.2_6 * pretmp.38_71;
pretmp.38_73 = offset.3_8 + pretmp.38_72;
pretmp.39_75 = j_2 + -1;
pretmp.40_76 = (integer(kind=8)) pretmp.39_75;
pretmp.40_77 = stride.2_6 * pretmp.40_76;
pretmp.40_78 = offset.3_8 + pretmp.40_77;
bb 6:
# i_37 = PHI i_29(7), 1(5)
...
D.1940_22 = *aa_21(D)[D.1939_20];
*aa_21(D)[D.1934_14] = D.1950_28;
and data-dependence analysis sees
(analyze_overlapping_iterations
(chrec_a = {pretmp.40_78 + 1, +, 1}_2)
(chrec_b = {pretmp.38_73 + 1, +, 1}_2)
and
(analyze_overlapping_iterations
(chrec_a = {{(stride.2_6 + offset.3_8) + 1, +, stride.2_6}_1, +, 1}_2)
(chrec_b = {{(stride.2_6 * 2 + offset.3_8) + 1, +, stride.2_6}_1, +, 1}_2)
[Bug tree-optimization/33711] Missed optimization: reduction by subtraction (vectorizer)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33711 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 13:05:15 UTC --- Fixed.
[Bug tree-optimization/53966] procmail build deadloop on _autotst -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53966 --- Comment #3 from Dzianis Kahanovich mahatma at eu dot by 2012-07-16 13:15:50 UTC --- (In reply to comment #2) Yes, right, -O2 -finline-functions broken too. -O3 -fno-inline-functions - broken; -O3 -fno-inline-functions -fno-ipa-cp-clone - good. -fno-strict-aliasing and/or -fwrapv - I found no differences in all combinations.
[Bug testsuite/53981] New: gcc.dg/20020201-1.c fails with Android NDK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53981 Bug #: 53981 Summary: gcc.dg/20020201-1.c fails with Android NDK Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: anna.m.tikhon...@gmail.com Created attachment 27803 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27803 Proposed fix Hi, when I compile gcc.dg/20020201-1.c with android ndk gcc (4.4 or 4.6) I get the following error: /tmp/ccK41Qjx.o: In function `doit': 20020201-1.c:(.text+0x43): undefined reference to `srand' 20020201-1.c:(.text+0x48): undefined reference to `rand' 20020201-1.c:(.text+0x55): undefined reference to `rand' collect2: ld returned 1 exit status In srand man it is stated that you need to include stdlib.h for (s)rand. Adding #include stdlib.h fixes the issue. Thanks, Anna
[Bug target/53980] [4.8 Regression] Bootstrap fails in stage 1: i386.md:17784:3: error: 'OPTION_BIONIC' undeclared here (not in a function) in build/gencondmd.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53980 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2012-07-16 14:13:02 UTC --- Offending patch got reverted.
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #8 from bfriesen at simple dot dallas.tx.us 2012-07-16 14:16:46 UTC --- I used -march=native in this case. It is interesting that this enabled AVX (this particular CPU does support it). To be clear, the problem also occurs with -m64 -mtune=generic -march=x86-64 -mfpmath=sse vs -m64 -mtune=generic -march=x86-64 -mfpmath=387 and is also observed on a 5-year old Opteron. With GCC 4.7.1, and for a specific application benchmark case and with generic architecture and tuning, -mfpmath=387 produces 0.133 iter/s and -mfpmath=sse produces 0.047 iter/s. A different (non-GCC) compiler on the same system produces 0.155 iter/s. In the course of testing, I have indeed tried -march=corei7 and it did not provide an improvement.
[Bug java/53982] New: gij built for x32 can't run a simple Hello World class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53982
Bug #: 53982
Summary: gij built for x32 can't run a simple Hello World class
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dschep...@gmail.com
Built and installed gcc from hjl/x32/gcc-4_7-branch (in a test chroot), after
running git merge origin/branches/gcc-4_7-branch, using
../src/configure --prefix=/usr --with-abi=mx32 --enable-languages=c,c++,java
With this configuration, I imported a HelloWorld.class file built outside the
chroot (since gcj -C HelloWorld.java inside the chroot complains about
missing ecj1), and tried running gij HelloWorld. This gave an error:
Exception in thread main java.lang.NullPointerException
at java.lang.String.charAt(libgcj.so.13)
at gnu.gcj.convert.Output_ASCII.write(libgcj.so.13)
at java.io.PrintStream.writeChars(libgcj.so.13)
at java.io.PrintStream.print(libgcj.so.13)
at java.io.PrintStream.println(libgcj.so.13)
at HelloWorld.main(HelloWorld.java:3)
The Java source is just the prototypical Java hello-world example:
public class HelloWorld {
public static void main(String args[]) {
System.out.println(Hello World!);
}
}
On the other hand, if I compile the .class file into a native executable using
gcj -O2 HelloWorld.class --main=HelloWorld -o ./HelloWorld
then that executable runs just fine.
But I'm not entirely convinced gcj-compiled native executables work without
problems, either. For example, with ecj compiled from the Debian libecj-java
binary package's jar file into native code, I can run gcj -C HelloWorld.java OK
in the Debian x32 chroot I'm bootstrapping. But on most source packages of any
size, it bails out sooner or later with a heap corruption message
ecj1: arena.c:661: heap_trim: Assertion `p-size == (0|0x1)' failed.
gcj-4.7: internal compiler error: Aborted (program ecj1)
[Bug target/53983] New: Cross arm-none-eabi armv6-m need a fake Makefile to compile libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53983 Bug #: 53983 Summary: Cross arm-none-eabi armv6-m need a fake Makefile to compile libgcc Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: erm230...@ermione.com Target: arm-none-eabi Configured with: ../gcc-4.7.1/configure --target=arm-none-eabi --prefix=/opt --enable-interwork --enable-multilib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-nls --disable-shared --disable-threads --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libgomp --disable-werror --with-system-zlib --with-arch=armv6-m --with-mode=thumb --with-float=soft --with-newlib --without-headers I had to create a Makefile with empty targets all: and install: in BUILDDIR/arm-none-eabi/fpu/libgcc/ to complete successfully compilation and install of libgcc.
[Bug tree-optimization/53970] -ftree-vectorization does not handle well unaligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53970 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 14:53:21 UTC --- The only hint we have on the a-l[i] expression that it involves a packed aggregate is DECL_ALIGN of the 'l' FIELD_DECL and TYPE_ALIGN of mystruct itself. Nowhere we have a TYPE/DECL_PACKED flag set. That is because how pragma pack works - it simply adjusts the global maximum_field_alignment of stor-layout.c. That means that expr.c:contains_packed_reference does not work.
[Bug java/53982] gij built for x32 can't run a simple Hello World class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53982 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-16 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-07-16 14:53:25 UTC --- Please show us how to reproduce it.
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-16 14:56:59 UTC --- (In reply to comment #8) I used -march=native in this case. It is interesting that this enabled AVX (this particular CPU does support it). To be clear, the problem also occurs with -m64 -mtune=generic -march=x86-64 -mfpmath=sse vs -m64 -mtune=generic -march=x86-64 -mfpmath=387 and is also observed on a 5-year old Opteron. With GCC 4.7.1, and for a specific application benchmark case and with generic architecture and tuning, -mfpmath=387 produces 0.133 iter/s and -mfpmath=sse produces 0.047 iter/s. A different (non-GCC) compiler on the same system produces 0.155 iter/s. In the course of testing, I have indeed tried -march=corei7 and it did not provide an improvement. What kind of optimization options are you using? -O3? Or are you really using -O0 (aka nothing)?
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #10 from bfriesen at simple dot dallas.tx.us 2012-07-16 15:35:03 UTC --- This particular application test was done with these options (i.e. -O2): -m64 -mtune=generic -march=x86-64 -mfpmath=387 -O2 I have also tried -O3, with no positive benefit. The Autoconf default is -O2 so that is what I generally test/tune the software with. It is pretty rare to see additional benefit from -O3, although with some versions of GCC I have seen application crashes due to wrong code from the tree vectorizer. Bob
[Bug bootstrap/53963] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53963 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-07-16 15:39:52 UTC --- Fixed.
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #11 from bfriesen at simple dot dallas.tx.us 2012-07-16 15:41:08 UTC --- I just verified that -O3 produces similar timings to -O2 for both -mfpmath=387 and -mfpmath=sse
[Bug java/53982] gij built for x32 can't run a simple Hello World class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53982 --- Comment #2 from Daniel Schepler dschepler at gmail dot com 2012-07-16 15:53:41 UTC --- (In reply to comment #1) Please show us how to reproduce it. I assume you mean the heap corruption issue in ecj1? To pick a Debian package at random which is running into this... download the source package from http://ftp.egr.msu.edu/debian/pool/main/libj/libjpedal-jbig2-java/libjpedal-jbig2-java_20100117.orig.tar.gz and unpack. Then run gcj -C -Wall `find org -name *.java | LC_COLLATE=C sort` Here, the output ends with org/jpedal/jbig2/decoders/MMRDecoder.java:189: warning: The declared exception IOException is not acecj1: arena.c:661: heap_trim: Assertion `p-size == (0|0x1)' failed. gcj: internal compiler error: Aborted (program ecj1) Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcj-4.7/README.Bugs for instructions.
[Bug java/53982] gij built for x32 can't run a simple Hello World class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53982 --- Comment #3 from Daniel Schepler dschepler at gmail dot com 2012-07-16 16:04:47 UTC --- Update on comment #2: Running through the java files one at a time, I found that just gcj -C -Wall org/jpedal/jbig2/examples/viewer/NavigationToolbar.java fails by itself. The first time, it creates a bunch of dependent .class files and outputs warnings for the sources, but subsequent times, I get just ecj1: arena.c:661: heap_trim: Assertion `p-size == (0|0x1)' failed. gcj: internal compiler error: Aborted (program ecj1) Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcj-4.7/README.Bugs for instructions. But oddly, that's not 100% reproducible. When I just ran that command 10 times in a row, it failed 6 times out of the 10.
[Bug libstdc++/53984] New: iostream operation throwing exception when exceptions not enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984
Bug #: 53984
Summary: iostream operation throwing exception when exceptions
not enabled
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gccbz.10.petec...@spamgourmet.com
I'm getting an exception thrown in a situation where I believe a failbit should
be set instead.
Is my expectation wrong?
---
#include fstream
#include sstream
int main()
{
std::ifstream in(.);
std::ostringstream out;
if (in)
in out.rdbuf();
}
---
terminate called after throwing an instance of 'std::ios_base::failure'
what(): basic_filebuf::underflow error reading the file
Aborted (core dumped)
[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984
--- Comment #1 from Pete Chapman gccbz.10.petechap at spamgourmet dot com
2012-07-16 17:00:10 UTC ---
Even simpler:
---
#include fstream
int main()
{
std::ifstream in(.);
int x;
if (in)
in x;
}
---
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails at stage 2 with error: cast from 'void*' to 'long int' loses precision in ggc-common.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 Rainer Emrich rai...@emrich-ebersheim.de changed: What|Removed |Added Summary|[4.7 Regression] bootstrap |[4.7/4.8 Regression] |fails at stage 2 with |bootstrap fails at stage 2 |error: cast from 'void*' to |with error: cast from |'long int' loses precision |'void*' to 'long int' loses |in ggc-common.c |precision in ggc-common.c Known to fail||4.8.0 --- Comment #2 from Rainer Emrich rai...@emrich-ebersheim.de 2012-07-16 17:10:16 UTC --- There are similar issues in other source files most of the form: error: cast loses precision [-fpermissive] And the same for gcc-4.8.0
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails at stage 2 with error: cast from 'void*' to 'long int' loses precision in ggc-common.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #3 from Rainer Emrich rai...@emrich-ebersheim.de 2012-07-16 17:17:24 UTC --- Created attachment 27804 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27804 Errors in stage 2 These are the errors I get in stage 2 for gcc-4.8.0. How to proceed?
[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-16 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 17:26:39 UTC --- Confirmed, I'm not sure filebuf::underflow should throw on invalid byte sequences either.
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|3.1.x/3.2.x |---
[Bug fortran/53985] New: -Wno-c-binding-type still prints a warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53985 Bug #: 53985 Summary: -Wno-c-binding-type still prints a warning Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Seemingly, I forgot a rather common usage when adding -W(no-)c-binding-type. For the following program, one still gets a warning by default – and it cannot be silenced! subroutine test(x) bind(C) 1 Warning: Variable 'x' at (1) is a parameter to the BIND(C) procedure 'test' but may not be C interoperable subroutine test(x) bind(C) integer :: x end subroutine test --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -1029,3 +1033,3 @@ gfc_verify_c_interop_param (gfc_symbol *sym) sym-ns-proc_name-name); - else + else if (gfc_option.warn_c_binding_type) gfc_warning (Variable '%s' at %L is a parameter to the
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-07-16 19:03:27 UTC --- (In reply to comment #1) (Fixed the component) I can't reproduce this. I can print wordMapBitset before it is initialized but I get a different error: (gdb) p wordBitsetMap $4 = std::map with 140737488349518 elementsCannot access memory at address 0x68732f6c61636f7c in line 15 the wordBitsetMap reference is initialized. (gdb) p wordBitsetMap $3 = Python Exception type 'exceptions.IndexError' list index out of range: std::map with 1 elements ^^^ this is true. What version of gdb are you using? gdb from git 7.4/master branch. Can you do it with stack-printing enabled? (set python print-stack on in recent versions, somewhere under maint in older ones.) This might help. (gdb) set python print-stack full (gdb) p wordBitsetMap $6 = std::map with 1 elementsTraceback (most recent call last): File /opt/gcc47/share/gcc-4.7.2/python/libstdcxx/v6/printers.py, line 427, in children rep_type = find_type(self.val.type, '_Rep_type') File /opt/gcc47/share/gcc-4.7.2/python/libstdcxx/v6/printers.py, line 43, in find_type field = typ.fields()[0] IndexError: list index out of range
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 19:14:26 UTC --- Author: redi Date: Mon Jul 16 19:14:18 2012 New Revision: 189545 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189545 Log: PR c++/53919 * doc/install.texi (Installing GCC): Refer to instructions for released versions. Fix hypenation. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53948 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-16 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-07-16 19:36:48 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=189361 IMHO the ira part of the patch should be reverted.
[Bug fortran/52101] Obsolescence warning for non-obs. feature character name*length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52101
--- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-16
19:38:33 UTC ---
Untested patch:
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -725,3 +729,3 @@ syntax:
static match
-match_char_length (gfc_expr **expr, bool *deferred)
+match_char_length (gfc_expr **expr, bool *deferred, bool obsolenscent_check)
{
@@ -741,4 +745,5 @@ match_char_length (gfc_expr **expr, bool *deferred)
{
- if (gfc_notify_std (GFC_STD_F95_OBS, Obsolescent feature:
- Old-style character length at %C) == FAILURE)
+ if (obsolenscent_check
+ gfc_notify_std (GFC_STD_F95_OBS, Obsolescent feature:
+Old-style character length at %C) == FAILURE)
return MATCH_ERROR;
@@ -1029,3 +1034,3 @@ gfc_verify_c_interop_param (gfc_symbol *sym)
sym-ns-proc_name-name);
- else
+ else if (gfc_option.warn_c_binding_type)
gfc_warning (Variable '%s' at %L is a parameter to the
@@ -1851,3 +1856,3 @@ variable_decl (int elem)
{
- switch (match_char_length (char_len, cl_deferred))
+ switch (match_char_length (char_len, cl_deferred), false)
{
@@ -2413,3 +2418,3 @@ gfc_match_char_spec (gfc_typespec *ts)
- m = match_char_length (len, deferred);
+ m = match_char_length (len, deferred, true);
if (m != MATCH_NO)
[Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53948 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||steven at gcc dot gnu.org AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2012-07-16 19:48:50 UTC --- I don't see how reverting this helps. We should understand why REG_USERVAR_P is apparently not true for this user variable.
[Bug java/53982] gij built for x32 can't run a simple Hello World class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53982 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-07/msg00686.htm ||l --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-07-16 20:15:23 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00686.html
[Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53948 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2012-07-16 20:23:20 UTC --- The problem seems to be that PARM_DECLs are not marked as REG_USERVAR_P.
[Bug libstdc++/53978] Missing static const definitions in bits/alloc_traits.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53978 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 20:43:16 UTC --- Author: redi Date: Mon Jul 16 20:43:11 2012 New Revision: 189547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189547 Log: PR libstdc++/53978 * include/bits/alloc_traits.h (allocator_traits): Define static constants. * include/bits/ptr_traits.h (pointer_traits): Likewise. * include/ext/alloc_traits.h (__allocator_always_compares_equal): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/alloc_traits.h trunk/libstdc++-v3/include/bits/ptr_traits.h trunk/libstdc++-v3/include/ext/alloc_traits.h
[Bug libstdc++/53978] Missing static const definitions in bits/alloc_traits.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53978 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 20:47:45 UTC --- Author: redi Date: Mon Jul 16 20:47:40 2012 New Revision: 189548 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189548 Log: PR libstdc++/53978 * include/bits/alloc_traits.h (allocator_traits): Define static constants. * include/bits/ptr_traits.h (pointer_traits): Likewise. * include/ext/alloc_traits.h (__allocator_always_compares_equal): Likewise. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/alloc_traits.h branches/gcc-4_7-branch/libstdc++-v3/include/bits/ptr_traits.h branches/gcc-4_7-branch/libstdc++-v3/include/ext/alloc_traits.h
[Bug libstdc++/53978] Missing static const definitions in bits/alloc_traits.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53978 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Known to fail||4.7.1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 20:48:50 UTC --- fixed
[Bug target/33135] [SH] -ffinite-math-only should not be on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135 --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-16 20:50:50 UTC --- (In reply to comment #3) I guess that the better default would be -mno-ieee for bare metals Hm ... Is there a particular reason to distinguish between linux and non-linux? I was actually thinking of tying -mno-ieee to -ffinite-math-only in the following way: no options- implicit -fno-finite-math-only -mieee -ffinite-math-only- disable ieee fcmp, allow other optimizations -ffinite-math-only -mieee - enable ieee fcmp, allow other optimizations -mno-ieee - disable ieee fcmp, disallow other optimizations I think if faster FPU code is desired, most likely the -ffast-math (or some sub-option like -ffinite-math-only) will be consulted in the first place. In case of bare metal configurations, users will probably tweak their specific options. Thus, I did not want to distinguish between linux or non-linux here.
[Bug c++/53954] [C++11] Undefined reference to non-odr-used static const member variable of variadic class template in DSO with -flto and -Wl,--export-dynamic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53954
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16
20:55:02 UTC ---
(In reply to comment #0)
Note also that the above reproducer originally comes from a likely C++ code
using `std::vector' and `-std=c++11' option, like the following;
/
#include vector
void f()
{
std::vectorint v;
v.push_back(0);
}
/
When a DSO is created from this code with `-std=c++11', `-lfto' and
`-Wl,--export-dynamic' options, it requires the definition of
`std::allocator_traitsstd::allocatorint ::__construct_helperint,
int::value'.
I have no view on whether this PR is valid or not, but the std::vector failure
is fixed for 4.7.2
[Bug middle-end/53986] New: missing vrp on bit-mask test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
Bug #: 53986
Summary: missing vrp on bit-mask test
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org
Consider the following test-case:
...
/* { dg-do link } */
/* { dg-options -O2 } */
/* Based on f3 from vrp63.c, but with switch instead of if-chain. */
extern void link_error (void);
void
f3 (int s)
{
if (s 3 == -2)
/* s in range [ -16, -9]. */
;
else
{
/* s in range ~[-16, -9], so none of the case labels can be taken. */
switch (s)
{
case -16:
case -12:
case -9:
link_error ();
break;
default:
break;
}
}
}
int
main ()
{
return 0;
}
...
the switchconv dump shows that the switch is converted to a bit-test:
...
;; Function f3 (f3, funcdef_no=0, decl_uid=1710, cgraph_uid=0)
beginning to process the following SWITCH statement (vrp72.c:18) : ---
switch (s_1(D)) default: L8, case -16: L2, case -12: L2, case -9: L2
expanding as bit test is preferable
Switch converted
f3 (int s)
{
_Bool D.1736;
long unsigned int D.1735;
long unsigned int D.1734;
long unsigned int csui.1;
_Bool D.1732;
int D.1730;
unsigned int D.1731;
int D.1720;
bb 2:
D.1720_2 = s_1(D) 3;
if (D.1720_2 == -2)
goto bb 5 (L8);
else
goto bb 3;
bb 3:
D.1730_6 = s_1(D) + 16;
D.1731_7 = (unsigned int) D.1730_6;
D.1732_8 = D.1731_7 7;
if (D.1732_8 != 0)
goto bb 6 (L9);
else
goto bb 7;
bb 7:
D.1734_10 = (long unsigned int) D.1731_7;
csui.1_9 = 1 D.1734_10;
D.1735_11 = csui.1_9 145;
D.1736_12 = D.1735_11 != 0;
if (D.1736_12 != 0)
goto bb 4 (L2);
else
goto bb 8;
bb 8:
L9:
goto bb 5 (L8);
L2:
link_error ();
L8:
return;
}
...
vrp doesn't manage to remove the path to function link_error.
Test-case vrp63 uses 'if (s == -16 || s == -12 || s == -9)' instead of a
switch. In that case, the path to link_error is removed.
Btw, if the switch is not converted to a bit-test the path to link_error is
also not removed by vrp, because it doesn't handle anti-ranges for switches.
[Bug fortran/53824] ICE with ALLOCATE of coarrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53824 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-07-16 20:58:08 UTC --- Author: tkoenig Date: Mon Jul 16 20:58:04 2012 New Revision: 189549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189549 Log: 2012-07-16 Thomas König tkoe...@gcc.gnu.org PR fortran/53824 * resolve.c (resolve_allocate_deallocate): If both start indices are NULL, skip the test for equality. 2012-07-16 Thomas König tkoe...@gcc.gnu.org PR fortran/53824 * gfortran.dg/coarray_allocate_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/coarray_allocate_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug java/53973] [x32] libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53973 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-07/msg00689.htm ||l --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-07-16 21:05:52 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00689.html
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 --- Comment #7 from Jakub Jermar jakub at jermar dot eu 2012-07-16 21:25:47 UTC --- Created attachment 27805 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27805 Reproducible testcase Here is a trimmed down reproducible testcase which exhibits the problem. The tarball contains a README file with instructions.
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|redi at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 21:33:34 UTC --- I still don't think it's the right thing to do, but does this help? --- a/libgcc/config/rs6000/gthr-aix.h +++ b/libgcc/config/rs6000/gthr-aix.h @@ -30,6 +30,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #include gthr-posix.h #else #include gthr-single.h +#undef _GLIBCXX_HAS_GTHREADS #endif #endif /* GCC_GTHR_AIX_H */
[Bug libstdc++/53270] [4.6/4.7 Regression] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #34 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 21:57:25 UTC --- Author: redi Date: Mon Jul 16 21:57:18 2012 New Revision: 189553 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189553 Log: PR libstdc++/53270 * include/ext/concurrence.h (__mutex, __recursive_mutex, __cond): Use NSDMI in C++98 mode too. * include/ext/rope: Add system_header pragma. (_Refcount_Base, _Rope_RopeRep): Use NSDMI. (_Rope_RopeRep::~_Rope_RopeRep): Destroy mutex. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/concurrence.h trunk/libstdc++-v3/include/ext/rope
[Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53948 --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-07-16 21:57:55 UTC --- Created attachment 27806 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27806 Proposed fix: Distinguish between a user variable and a function argument
[Bug target/33135] [SH] -ffinite-math-only should not be on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135 --- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-07-16 22:15:40 UTC --- (In reply to comment #4) Thus, I did not want to distinguish between linux or non-linux here. I have no strong feelings about the bare metal case. We didn't catch any complaints for defaulting -mieee in 4.6 and 4.7 compilers. It could be a proof of your argument.
[Bug target/38621] [4.6/4.7/4.8 Regression] sh gcc unable to spill register when building ghostscript-gpl with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38621 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org Known to work||4.6.4, 4.7.2 Known to fail|| --- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-16 22:24:11 UTC --- I've tried to reproduce the issue with rev 189549 (GCC 4.8), GCC 4.7.2 20120711 (prerelease) and GCC 4.6.4 20120716 (prerelease). It seems this is no longer an issue.
[Bug libstdc++/53270] [4.6/4.7 Regression] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #35 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 22:34:17 UTC --- Author: redi Date: Mon Jul 16 22:34:13 2012 New Revision: 189555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189555 Log: PR libstdc++/53270 * include/ext/concurrence.h: Use NSDMI for gthreads types. * include/ext/rope: Likewise. Destroy mutexes in destructors. Add system_header pragma. Revert: 2012-06-19 Jonathan Wakely jwakely@gmail.com PR libstdc++/53270 * config/os/gnu-linux/os_defines.h: Disable static initializer macros for gthreads types in C++11 mode. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/config/os/gnu-linux/os_defines.h branches/gcc-4_7-branch/libstdc++-v3/include/ext/concurrence.h branches/gcc-4_7-branch/libstdc++-v3/include/ext/rope
[Bug libstdc++/53270] [4.6 Regression] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.2 Summary|[4.6/4.7 Regression] Error |[4.6 Regression] Error when |when bootstrapping gcc on |bootstrapping gcc on |hppa2.0-unknown-linux-gcc |hppa2.0-unknown-linux-gcc --- Comment #35 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-16 22:34:17 UTC --- Author: redi Date: Mon Jul 16 22:34:13 2012 New Revision: 189555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189555 Log: PR libstdc++/53270 * include/ext/concurrence.h: Use NSDMI for gthreads types. * include/ext/rope: Likewise. Destroy mutexes in destructors. Add system_header pragma. Revert: 2012-06-19 Jonathan Wakely jwakely@gmail.com PR libstdc++/53270 * config/os/gnu-linux/os_defines.h: Disable static initializer macros for gthreads types in C++11 mode. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/config/os/gnu-linux/os_defines.h branches/gcc-4_7-branch/libstdc++-v3/include/ext/concurrence.h branches/gcc-4_7-branch/libstdc++-v3/include/ext/rope
[Bug target/53987] New: [SH] Unnecessary zero-extension before cmp/eq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
Bug #: 53987
Summary: [SH] Unnecessary zero-extension before cmp/eq
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
The following function:
int test_00 (unsigned char* a, unsigned char* b, int c, int d)
{
if (*a == *b)
return c;
return d;
}
gets compiled to:
mov.b @r4,r1
mov.b @r5,r2
extu.b r1,r1
extu.b r2,r2
cmp/eq r2,r1
bt .L4
mov r7,r6
.L4:
rts
mov r6,r0
Obviously the zero-extensions can be omitted.
The following combine patterns can be used to eliminate the zero extensions
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md(revision 189550)
+++ gcc/config/sh/sh.md(working copy)
@@ -759,6 +759,30 @@
cmp/eq%1,%0
[(set_attr type mt_group)])
+(define_insn_and_split *cmpeqsi_t
+ [(set (reg:SI T_REG)
+(eq:SI (zero_extend:SI (match_operand:QI 0 arith_reg_operand r))
+ (match_operand:SI 1 arith_reg_operand r)))]
+ TARGET_SH1
+{
+ gcc_unreachable ();
+ return #;
+}
+ can_create_pseudo_p ()
+ [(set (match_dup 2) (zero_extend:SI (match_dup 0)))
+ (set (reg:SI T_REG) (eq:SI (match_dup 1) (match_dup 2)))]
+{
+ operands[2] = gen_reg_rtx (SImode);
+})
+
+(define_insn *cmpeqsi_t
+ [(set (reg:SI T_REG)
+(eq:SI (sign_extend:SI (match_operand:QI 0 arith_reg_operand r))
+ (sign_extend:SI (match_operand:QI 1 arith_reg_operand r]
+ TARGET_SH1
+ cmp/eq%1,%0
+ [(set_attr type mt_group)])
+
(define_insn cmpgtsi_t
[(set (reg:SI T_REG)
(gt:SI (match_operand:SI 0 arith_reg_operand r,r)
A quick look at the CSiBE result-size set (-m4-single -O2 -pretend-cmove) shows
a few code size decreases and one increase, where the following code sequence
is generated in unrarlib.s:
.L397:
mov.l .L467,r3! 167movsi_ie/1
mov.b @(2,r9),r0 ! 165*movqi_load_mem_disp/1
mov.w @r9,r6 ! 169*extendhisi2_compact_snd
mov r0,r7 ! ! 513*movqi_reg_reg/1
mov.b r0,@(2,r3) ! 172*movqi_store_mem_disp04/1
mov.w @(4,r9),r0 ! 514*movhi_load_mem_disp/1
extu.b r7,r7 ! ! 441*zero_extendqisi2_compact
mov.w r6,@r3 ! 170*movhi/4
cmp/eq r7,r8 ! 442cmpeqsi_t/3
This seems to be the consequence of the splitter, which changes the insn
order...
[Bug target/53988] New: [SH] tst Rm,Rn not used for QI/HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53988
Bug #: 53988
Summary: [SH] tst Rm,Rn not used for QI/HImode
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
The following functions:
int test_00 (unsigned char* a, unsigned char* b, int c, int d)
{
if (*a *b)
return c;
return d;
}
int test_01 (char* a, char* b, int c, int d)
{
if (*a *b)
return c;
return d;
}
get compiled to:
mov.b @r4,r1 ! 10*extendqisi2_compact_snd
mov.b @r5,r0 ! 11*extendqisi2_compact_snd
and r1,r0 ! 12*andsi_compact/4
tst #255,r0 ! 15tstqi_t_zero
bf .L9 ! 16branch_false
mov r7,r6 ! 7movsi_ie/2
.L9:
rts ! 49*return_i
mov r6,r0 ! 24movsi_ie/2
which should actually result in:
mov.b @r4,r1
mov.b @r5,r2
tst r1,r2
bf .L9
mov r7,r6
.L9:
rts
mov r6,r0
The same happens for QImode and HImode.
[Bug c++/53989] New: Internal compiler error in strip_typedefs, at cp/tree.c:1187
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53989
Bug #: 53989
Summary: Internal compiler error in strip_typedefs, at
cp/tree.c:1187
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@limax.org
Running 'g++ -std=c++0x -c test.cpp' with the following source saved as
test.cpp:
---
struct Foo {
int value;
static Foo const foos[2];
};
void bar() {
for (Foo f : Foo::foos) { (void) f; }
}
--
produces this result:
---
test.cpp: In function ‘void bar()’:
test.cpp:8:21: internal compiler error: in strip_typedefs, at cp/tree.c:1187
---
If I get rid of the 'value' member of Foo, or if I provide a definition of
Foo::foos before it is used by Bar, or if I change Foo::foos to be type 'Foo'
instead of type 'Foo const', or if I move Foo::foos outside of class Foo, I
don't see the error.
GCC was built using the following configuration:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/tools/sw/gcc/471/rhel5-x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/tools/sw/gcc/471/rhel5-x86_64
--with-gmp=/home/tools/sw/gcc/471/rhel5-x86_64
--with-ppl=/home/tools/sw/gcc/471/rhel5-x86_64
--with-cloog=/home/tools/sw/gcc/471/rhel5-x86_64 --enable-cloog-backend=isl
--with-system-zlib --enable-__cxa_atexit --enable-shared --enable-threads=posix
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.7.1 (GCC)
[Bug c++/53990] New: wrong optimisation: automatic variable doesn't removed at fuction exit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53990
Bug #: 53990
Summary: wrong optimisation: automatic variable doesn't
removed at fuction exit
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vol.li...@gmail.com
I use C++ with the following specs by g++ -v
Using built-in specs.
Target: x86_64-manbo-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --with-bugurl=https://qa.mandriva.com/
--mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java
--build=x86_64-manbo-linux-gnu --host=x86_64-manbo-linux-gnu --with-cpu=generic
--with-system-zlib --enable-threads=posix --enable-shared --enable-objc-gc
--enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp --disable-werror
--with-ppl --with-cloog --with-python-dir=/lib/python2.6/site-packages
Thread model: posix
gcc version 4.4.1 (GCC)
I've also done tests with gcc version 4.4.5 (Debian 4.4.5-8) and gcc version
4.6.2 (SUSE Linux).
See the next code
struct A {
int d;
A operator*(const A) const;
A operator+(const A) const;
} a;
A A::operator*(const A a) const {
A c;
c.d = d*a.d;
return c;
}
A A::operator+(const A a) const {
cout *this;
return a;
}
return a; causes the call of the copy constructor, but return c; doesn't
call this constructor---it returns (does not destroy!) automatic (!) variable
c. Is this optimization in C++ standard? If no then this optimisation may
cause severe errors if we are using pointers. See the next code.
#include iostream
using namespace std;
struct Array {
unsigned char HSize, VSize;
int *p;
bool canBeDeleted;
Array(unsigned char, unsigned char);
Array(unsigned char, unsigned char, int*);
Array(const Array);
Array operator[](unsigned char) const;
Array operator=(const Array);
Array operator=(int);
Array operator+(Array) const;
friend ostream operator(ostream, const Array);
operator int() {return p[0];};
~Array();
};
Array::Array(unsigned char n, unsigned char m) {
VSize = n;
HSize = m;
p = new int[n*m];
canBeDeleted = true;
}
Array::Array(unsigned char n, unsigned char m, int* p1) {
VSize = n;
HSize = m;
p = p1;
canBeDeleted = true;
}
Array::Array(const Array Data) {
HSize = Data.HSize;
VSize = Data.VSize;
p = new int[VSize*HSize];
for (int i = 0; i Data.VSize; i++) {
for (int j = 0; j Data.HSize; j++)
p[i*HSize + j] = Data.p[i*HSize + j];
}
canBeDeleted = true;
}
Array::~Array() {
if (canBeDeleted)
delete []p;
}
Array Array::operator[](unsigned char i) const {
if (i = VSize VSize != 1)
throw 1;
unsigned char size = HSize;
if (VSize == 1) {
size = 1;
if (i = HSize)
throw 7;
}
Array A(1, size, p + i*size);
A.canBeDeleted = false;
return A;
}
Array Array::operator=(int i) {
if (HSize != 1 VSize != 1)
throw 2;
this-p[0] = i;
}
Array Array::operator=(const Array Data) {
if (VSize == Data.VSize HSize == Data.HSize)
for (int i = 0; i VSize; i++)
for (int j = 0; j HSize; j++)
p[i*HSize + j] = Data.p[i*HSize + j];
else
throw 3;
return *this;
}
Array Array::operator+(Array Data) const {
if (VSize == Data.VSize HSize == Data.HSize)
for (int i = 0; i VSize; i++)
for (int j = 0; j HSize; j++)
Data.p[i*HSize + j] += p[i*HSize + j];
else
throw 5;
return Data;
}
ostream operator(ostream s, const Array Data) {
if (Data.VSize == 1 Data.HSize == 1) {
s Data.p[0];
return s;
}
s endl;
for (int i = 0; i Data.VSize; i++) {
for (int j = 0; j Data.HSize; j++)
s '\t' Data.p[i*Data.HSize + j];
s endl;
}
s endl;
return s;
}
int main() {
Array A(3,3), E(3,3);
for (int i = 0; i 3; i++)
for (int j = 0; j 3; j++) {
E[i][j] = i == j;
A[i][j] = i + j;
}
cout A A E E;
A[1][2] = 7;
A[2] = E[1]; //it works. but should it work?
A[1] + E[2]; //a problem!
cout E E;
}
E was changed! :-(
Regards
Litwr
