[Bug testsuite/54397] [regression] gfortran.dg/guality/pr41558.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54397 --- Comment #6 from Jakub Jelinek 2012-08-30 07:01:12 UTC --- You need GDB 7.5 (or the changes mentioned in the other PR backported). It doesn't make any sense to XFAIL the test, all debugging of code compiled by GCC 4.8 is broken with older GDBs.
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 --- Comment #14 from Michael Haubenwallner 2012-08-30 07:33:16 UTC --- Indeed, the old buffer is freed before being copied. Yep, this isn't a regression. In fact, with 4.4.3 it was the /empty string/ having the size of 1 in the comment#0 testcase, so bug#40518 actually improved things here. However, doesn't any operation with (const _CharT*, size_type) as input parameter potentially have a problem with ( own.c_str(), own.size()+1 ) ?
[Bug libstdc++/54172] [4.7/4.8 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #4 from Thiago Macieira 2012-08-30 07:52:31 UTC --- I'll post today. I haven't yet looked up which mailing list you're even talking about.
[Bug c++/54413] New: Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413
Bug #: 54413
Summary: Option for turning off compiler extensions for
-std=c++11 with respect to complex/fixed-point numbers
missing
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: p4s...@hispeed.ch
All versions of g++ that support UDL operators should have such an option to
turn off GNU complex literals and fixed point literals extensions.
I am prototyping C++1x library extensions for user-defined literals. While it
is possible to turn off GCC's extensions for complex numbers for "old" C++ it
is impossible to combine the effects of -ansi with -std=c++11. Especially the
syntax extensions for complex numbers, e.g., 1.1i cannot be turned off and thus
do not allow testing of UDL operators for the purpose of creating
std::complex<> literals, such as
constexpr std::complex operator"" i(long double d){
return std::complex(0,d);
}
>From the fixed-point extension also number suffixes r and R are occupied.
More info at my proposal,
http://wiki.hsr.ch/PeterSommerlad/files/N3402_UDLsuffixes.pdf
All versions of g++ that support UDL operators should have such an option to
turn off GNU complex literals and fixed point literals extensions.
[Bug libstdc++/54172] [4.7/4.8 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #5 from Jakub Jelinek 2012-08-30 08:19:56 UTC --- Send to both gcc-patches at gcc.gnu.org and libstdc++ at gcc.gnu.org. I think it would be better to send both hunks separately, as the first hunk is shorter for backporting and the only necessary thing to fix, and you should include ChangeLog entries alongside with the patches, something like: 2012-08-30 Thiago Macieira PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Describe your change here.
[Bug target/54414] New: ARM:mis-compiled prologue/epilogue on cortex-m0 when optimizing with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54414
Bug #: 54414
Summary: ARM:mis-compiled prologue/epilogue on cortex-m0 when
optimizing with -Os
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amker.ch...@gmail.com
For the case of pr45070.c as below:
/* PR45070 */
extern void abort(void);
struct packed_ushort {
unsigned short ucs;
} __attribute__((packed));
struct source {
int pos, length;
int flag;
};
static void __attribute__((noinline)) fetch(struct source *p)
{
p->length = 128;
}
static struct packed_ushort __attribute__((noinline)) next(struct source *p)
{
struct packed_ushort rv;
if (p->pos >= p->length) {
if (p->flag) {
p->flag = 0;
fetch(p);
return next(p);
}
p->flag = 1;
rv.ucs = 0x;
return rv;
}
rv.ucs = 0;
return rv;
}
int main(void)
{
struct source s;
int i;
s.pos = 0;
s.length = 0;
s.flag = 0;
for (i = 0; i < 16; i++) {
struct packed_ushort rv = next(&s);
if ((i == 0 && rv.ucs != 0x)
|| (i > 0 && rv.ucs != 0))
abort();
}
return 0;
}
Compile with below options:
$ arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os pr45070.c -o pr45070.S
The generated assembly code for function next is like:
next:
push{r0, r1, r2, r3, r4, lr}
ldrr2, [r0]
ldrr3, [r0, #4]
movr4, r0
cmpr2, r3
blt.L3
ldrr2, [r0, #8]
cmpr2, #0
beq.L4
movr3, #0
strr3, [r0, #8]
addr0, r0, #4
blfetch.isra.0
movr0, r4
blnext
movr3, sp
sxthr0, r0
strbr0, [r3]
lsrr0, r0, #8
strbr0, [r3, #1]
movr3, sp
ldrhr2, [r3]
b.L6
.L4:
movr3, #1
strr3, [r0, #8]
negr2, r3
b.L6
.L3:
movr2, #0
.L6:
addr3, sp, #12
strhr2, [r3]
addr3, sp, #12
ldrbr0, [r3, #1]
ldrbr2, [r3]
lslr0, r0, #8
orrr0, r2
@ sp needed for prologue
pop{r1, r2, r3, r4, pc}
The pc register is restored with wong value.
[Bug bootstrap/54415] New: GCC 4.4.4 build fails on solaris sparc with error as undefined reference to `_Qp_xtoq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54415 Bug #: 54415 Summary: GCC 4.4.4 build fails on solaris sparc with error as undefined reference to `_Qp_xtoq' Classification: Unclassified Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: birender.si...@hotmail.com Created attachment 28104 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28104 Attachment contains error message while executing 'make' command after configuring gcc. Machine Details: --- #uname -a SunOS slimsol10t1 5.10 Generic_147440-01 sun4u sparc SUNW,Sun-Fire-V240 # cat /etc/release Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 23 August 2011 GCC Deatils: bash-3.2# gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.4.4/configure --prefix=/usr/local/gcc-4.4.4 --program-suffix=-4.4.4 --enable-threads=posix --enable-shared --enable-languages=c,c++ --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.4 (GCC) bash-3.2# Binutils details: -- # ld -V GNU ld (GNU Binutils) 2.20 Supported emulations: elf32_sparc elf64_sparc Environment Settings: # echo $PATH /usr/local/bin:/usr/sbin:/usr/bin:/usr/local/bin:/els/install/gcc-4.4.4/bin:/usr/sfw/bin:/usr/ccs/bin # echo $LD_LIBRARY_PATH /usr/local/lib:/els/install/gcc-4.4.4/lib:/usr/sfw/lib:/els/install/gcc-4.4.4_64/gmp32/lib:/els/install/gcc-4.4.4_64/mpfr32/lib Building 64bit gcc-4.4.4 on solaris 10 sparc machine. Configured successfully but fails while executing 'make' command. Steps to produce: # pwd /els/install/gcc-4.4.4_64/build_64 Configures command: # ../gcc-4.4.4/configure --prefix=/usr/local/gcc-4.4.4_64 --with-gmp=/els/install/gcc-4.4.4_64/gmp32 --with-mpfr=/els/install/gcc-4.4.4_64/mpfr32 --build=sparcv9-sun-solaris2.10 --enable-languages=c,c++ --with-gnu-as --with-gnu-ld #make Observed: . . . /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1929: undefined reference to `_Qp_sub' _fixtfdi_s.o: In function `__fixtfti': /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1212: undefined reference to `_Qp_flt' _fixunstfdi_s.o: In function `__fixunstfti': /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1186: undefined reference to `_Qp_flt' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1193: undefined reference to `_Qp_mul' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1193: undefined reference to `_Qp_qtoux' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1196: undefined reference to `_Qp_sub' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1200: undefined reference to `_Qp_flt' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1201: undefined reference to `_Qp_qtoux' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1203: undefined reference to `_Qp_qtoux' _floatditf_s.o: In function `__floattitf': /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1392: undefined reference to `_Qp_xtoq' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1393: undefined reference to `_Qp_mul' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1393: undefined reference to `_Qp_uxtoq' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1393: undefined reference to `_Qp_add' _floatunditf_s.o: In function `__floatuntitf': /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1406: undefined reference to `_Qp_uxtoq' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1407: undefined reference to `_Qp_mul' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1407: undefined reference to `_Qp_uxtoq' /els/install/gcc-4.4.4_64/build_64/sparcv9-sun-solaris2.10/libgcc/../../../gcc-4.4.4/libgcc/../gcc/libgcc2.c:1407: undefined reference to `_Qp_a
[Bug c++/54413] Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2012-08-30 09:10:58 UTC --- [usrlit.suffix]/1 says that udlit suffixes that don't start with underscore are reserved.
[Bug c++/54416] New: [4.8] ICE (segv) in codegen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54416
Bug #: 54416
Summary: [4.8] ICE (segv) in codegen
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sim...@google.com
Created attachment 28105
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28105
ice.cc
In gcc trunk at r190799:
configure \
--enable-languages=c,c++ --disable-bootstrap \
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu \
--target=x86_64-unknown-linux-gnu
make -j6 all-gcc
cat /tmp/ice.cc
int mumble;
static
__typeof (mumble)
__gthrw_pthread_once __attribute__ ((__weakref__ ("mumble")));
template < typename T > struct foo;
template <> struct foo < int >;
template < typename T > struct bar
{
template <> struct foo < int >
{
void baz ();
};
};
void foo < int >::baz () { }
gcc/xgcc -B gcc -c -o /dev/null /tmp/ice.cc
/tmp/ice1.cc:9:13: error: explicit specialization in non-namespace scope
'struct bar'
template <> struct foo < int >
^
/tmp/ice1.cc:15:28: internal compiler error: Segmentation fault
void foo < int >::baz () { }
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug c++/54413] Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-30 Ever Confirmed|0 |1 Severity|major |normal --- Comment #2 from Jonathan Wakely 2012-08-30 09:55:31 UTC --- (In reply to comment #0) > While it > is possible to turn off GCC's extensions for complex numbers for "old" C++ it Is it? I don't think that's true. > is impossible to combine the effects of -ansi with -std=c++11. That's because -ansi means -std=c++98, it has nothing to do with whether complex literals are supported. (In reply to comment #1) > [usrlit.suffix]/1 says that udlit suffixes that don't start with underscore > are > reserved. Yes, for future UDLs. Peter's paper proposes new standard UDLs for standard library types so in order for G++ to support them it must be able to tell the preprocessor not to treat 1i as a complex literal, so the front-end can turn it into a call to a UDL operator in the standard library.
[Bug libstdc++/54172] [4.7/4.8 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #6 from Jonathan Wakely 2012-08-30 09:56:44 UTC --- This is just the usual submission process, documented at http://gcc.gnu.org/contribute.html#patches
[Bug c++/54416] [4.7/4.8 Regression] ICE (segv) in codegen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54416 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-invalid-code Last reconfirmed||2012-08-30 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever Confirmed|0 |1 Summary|[4.8] ICE (segv) in codegen |[4.7/4.8 Regression] ICE ||(segv) in codegen Target Milestone|--- |4.7.2 --- Comment #1 from Jakub Jelinek 2012-08-30 10:00:15 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183221 Guess the uninstantiated templates shouldn't be registered with cgraph either then.
[Bug c++/54413] Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413 --- Comment #3 from Jakub Jelinek 2012-08-30 10:03:51 UTC --- Perhaps we should for i and r etc. suffixes in C++11+ first try to look it up as user-defined-literal and only if there are no corresponding operator""s, treat it as the GNU extension?
[Bug c++/54403] [C++11] operator! applied to a member of a templated class in a lambda expression that captures 'this' pointer crashes compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54403 Jonathan Wakely changed: What|Removed |Added Blocks||54367 Severity|major |normal
[Bug target/54252] [4.7/4.8 Regression] Bad alignment code generated for Neon loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252 --- Comment #6 from Ramana Radhakrishnan 2012-08-30 10:17:08 UTC --- Author: ramana Date: Thu Aug 30 10:17:04 2012 New Revision: 190800 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190800 Log: Fix PR target/54252 2012-08-29 Ramana Radhakrishnan Richard Earnshaw PR target/54252 * config/arm/arm.c (neon_dereference_pointer): Adjust nelems by element size. Use elem_type from the formal parameter. New parameter fcode. (neon_expand_args): Adjust call to neon_dereference_pointer. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug target/54414] ARM:mis-compiled prologue/epilogue on cortex-m0 when optimizing with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54414 --- Comment #1 from amker.cheng 2012-08-30 10:17:15 UTC --- I suspect that the call of arm_size_return_regs in function thumb1_extra_regs_pushed should also be covered as in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00830.html
[Bug target/54252] [4.7/4.8 Regression] Bad alignment code generated for Neon loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252 --- Comment #7 from Ramana Radhakrishnan 2012-08-30 10:21:59 UTC --- Fixed now I believe on trunk.
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 --- Comment #1 from Jonathan Wakely 2012-08-30 10:42:07 UTC --- (In reply to comment #0) > On powerpc-apple-darwin9 and x86_64-apple-darwin10, the test > 30_threads/condition_variable/54185.cc is timed out (from > http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02572.html this does seem to > occur on x86_64-apple-darwin12.2.0). Do you mean does *not* happen on darwin12? > Sampling the run after ~40 minutes gives: There's no need to wait 40 mins, the process will be deadlocked after a few milliseconds. I can't look into this for a week, but it looks like notify_all only woke one of the nine threads waiting on the condition variable, which would be a darwin bug. That looks more likely if it doesn't happen on later versions.
[Bug lto/54417] New: lto1: internal compiler error: in edge_badness, at ipa-inline.c:793
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54417 Bug #: 54417 Summary: lto1: internal compiler error: in edge_badness, at ipa-inline.c:793 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: einar.sjurso+...@gmail.com lto1: internal compiler error: in edge_badness, at ipa-inline.c:793 Please submit a full bug report, with preprocessed source if appropriate. gcc 4.7.1 snapshot with date 20120811 on x86_64 (linux). This failure occured during final LTO (-fno-fat-lto-objects -flto-partition=none -flto) with -fprofile-use, it passes otherwise. Unfortunately I'm no longer able to give any more details, If I can reproduce this again I will try to get a proper testcase. Sorry :)
[Bug target/54418] New: [4.8 Regression] [SH] Invalid operands for opcode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418
Bug #: 54418
Summary: [4.8 Regression] [SH] Invalid operands for opcode
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kkoj...@gcc.gnu.org
CC: olege...@gcc.gnu.org
Target: sh*-*-*
There are new libgomp failures with 4.8 compiler:
FAIL: libgomp.c++/loop-9.C -O0 (test for excess errors)
Excess errors:
/tmp/ccGZWxT0.s:8594: Error: invalid operands for opcode
The compiler outputs the invalid insn like "cmp/hs #0,reg".
Here is a reduced test case with -O0 -fopenmp.
typedef struct { } omp_sched_t;
extern "C" void abort ();
int arr[6 * 5];
void set (int loopidx, int idx)
{
for (idx = 0; idx < 5; idx++)
if (arr[4 * 5 + idx] != idx < 4)
abort ();
}
int test4 ()
{
int e = 0, idx;
{
unsigned long long j;
#pragma omp for schedule(static,1) nowait
for (j = 9223372036854775807LL - 2ULL;
9223372036854775807LL + 1ULL >= j;
j += 1ULL)
{
}
}
for (idx = 0; idx < 5; idx++)
if (arr[5 * 5 + idx] != idx < 5)
abort ();
}
It seems that cmpgeusi_t insn_and_split doesn't do its work.
(define_insn_and_split "cmpgeusi_t"
[(set (reg:SI T_REG)
(geu:SI (match_operand:SI 0 "arith_reg_operand" "r")
(match_operand:SI 1 "arith_reg_or_0_operand" "rN")))]
"TARGET_SH1"
"cmp/hs%1,%0"
"&& satisfies_constraint_Z (operands[0])"
[(set (reg:SI T_REG) (const_int 1))]
Oleg, operands[0] in the splitter condition is a typo of
operands[1], doesn't it?
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 --- Comment #2 from Dominique d'Humieres 2012-08-30 12:53:54 UTC --- (In reply to comment #1) > Do you mean does *not* happen on darwin12? Well, I don't have access to darwin11 nor 12, so the only thing I am sure of is that the failure does not show up in the darwin12 logs. > ... which would be a darwin bug. > That looks more likely if it doesn't happen on later versions. I agree, but I doubt that apple will backport the fix. Does it exist a simple workaround? If not, the test should be skipped for darwin before 10 (maybe 11).
[Bug target/54418] [4.8 Regression] [SH] Invalid operands for opcode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418 --- Comment #1 from Oleg Endo 2012-08-30 13:11:30 UTC --- (In reply to comment #0) > > It seems that cmpgeusi_t insn_and_split doesn't do its work. > > (define_insn_and_split "cmpgeusi_t" > [(set (reg:SI T_REG) > (geu:SI (match_operand:SI 0 "arith_reg_operand" "r") > (match_operand:SI 1 "arith_reg_or_0_operand" "rN")))] > "TARGET_SH1" > "cmp/hs%1,%0" > "&& satisfies_constraint_Z (operands[0])" > [(set (reg:SI T_REG) (const_int 1))] > > Oleg, operands[0] in the splitter condition is a typo of > operands[1], doesn't it? Yes, it is. Sorry about that. Also, the 'N' alternative doesn't make sense in this case, as the split will happen before reload will start looking at the constraints. I think the pattern should be: (define_insn_and_split "cmpgeusi_t" [(set (reg:SI T_REG) (geu:SI (match_operand:SI 0 "arith_reg_operand" "r") (match_operand:SI 1 "arith_reg_or_0_operand" "r")))] "TARGET_SH1" "cmp/hs%1,%0" "&& satisfies_constraint_Z (operands[1])" [(set (reg:SI T_REG) (const_int 1))] "" [(set_attr "type" "mt_group")]) I always wondered under which condition this case would actually happen. Now I know it. Thanks!
[Bug rtl-optimization/54365] ARM optimization bug when pointer arithmetic wraps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54365 --- Comment #5 from Greg Law 2012-08-30 13:23:54 UTC --- -fwrapv doesn't appear to make a difference: $ gcc compilerbug.c $ ./a.out it wraps $ gcc -O2 compilerbug.c $ ./a.out no wrap $ gcc -O2 -fwrapv compilerbug.c $ ./a.out no wrap $
[Bug rtl-optimization/54365] ARM optimization bug when pointer arithmetic wraps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54365 --- Comment #6 from Florian Weimer 2012-08-30 13:33:05 UTC --- (In reply to comment #5) > -fwrapv doesn't appear to make a difference: > > $ gcc compilerbug.c > $ ./a.out > it wraps > $ gcc -O2 compilerbug.c > $ ./a.out > no wrap > $ gcc -O2 -fwrapv compilerbug.c > $ ./a.out > no wrap > $ This is surprising. Is there a way to extend the effect of -fwrapv to pointer arithmetic?
[Bug rtl-optimization/54365] ARM optimization bug when pointer arithmetic wraps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54365 --- Comment #7 from Jakub Jelinek 2012-08-30 13:45:13 UTC --- This is not surprising, just use integer arithmetic instead of pointer arithmetic. Pointer arithmetic not only has undefined wrapping, it is defined only within the bounds of the object it points into (or one past the last byte in it, but you can't dereference it in that case).
[Bug rtl-optimization/54365] ARM optimization bug when pointer arithmetic wraps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54365 --- Comment #8 from Florian Weimer 2012-08-30 13:56:04 UTC --- (In reply to comment #7) > This is not surprising, just use integer arithmetic instead of pointer > arithmetic. Pointer arithmetic not only has undefined wrapping, it is defined > only within the bounds of the object it points into (or one past the last byte > in it, but you can't dereference it in that case). I was hoping that -fwrapv would turn pointer arithmetic into pure address arithmetic as well. The -fwrapv documentation only mentions integer arithmetic so this is not a bug, it's just ... surprising.
[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 Hin-Tak Leung changed: What|Removed |Added Attachment #27346|0 |1 is obsolete|| Attachment #27347|0 |1 is obsolete|| Attachment #27348|0 |1 is obsolete|| --- Comment #25 from Hin-Tak Leung 2012-08-30 14:04:53 UTC --- Created attachment 28106 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28106 stage*-gcc/c-lang.o - tgz'ed stage*-gcc/c-lang.o -rw-r--r-- root/system 533880 2012-08-30 10:28 stage1-gcc/c-lang.o -rw-r--r-- root/system 12112 2012-08-30 11:18 stage2-gcc/c-lang.o -rw-r--r-- root/system 176168 2012-08-30 13:18 stage3-gcc/c-lang.o
[Bug bootstrap/54419] New: [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 Bug #: 54419 Summary: [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: drepper@gmail.com, ia...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 Bootstrapping revision 190787 fails on x86_64-apple-darwin10 with: libtool: compile: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include -I/opt/gcc/work/libstdc++-v3/../libgcc -I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include -I/opt/gcc/work/libstdc++-v3/libsupc++ -std=gnu++11 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -frandom-seed=random.lo -g -O2 -c ../../../../../work/libstdc++-v3/src/c++11/random.cc -fno-common -DPIC -o random.o /var/tmp//ccZpDauf.s:28:no such instruction: `rdrand %eax' Note that on darwin10 as is fairly old: GNU assembler version 1.38.
[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #26 from Hin-Tak Leung 2012-08-30 14:19:16 UTC --- (In reply to comment #22) > The sentence about newer versions is there for a reason. In fact, on > Tru64 UNIX the situation is even worse: gmp 4.3.2 make check fails for > me, so I'm currently staying with gmp 4.2.1, mpfr 2.3.2, and mpc 0.8. > > Before using *any* version of gmp/mpfr/mpc with gcc (or for any other > purpose), make sure that they pass make check, as prominently stated in > e.g. the gmp announcements. > > Rainer You are quite right about that - 'make check' is okay for me for gmp 4.x and 5.x, but mpfr 3.1.x fails (3.0.x and 2.4.x okay), mpc 0.8 & 1.0 are okay *if* mpfr is reverted back to 3.0.x . So I have wiped the faulty libraries, make check the older versions and only install if pass; but the stage compare still fails between 2 and 3 with just plain "make" (attached). I am currently retrying with make bootstrap4-lean - I know I have finished 4.6.1 correctly *once*, I just don't know how :-(.
[Bug c++/54420] New: Segmentation in decl_mangling_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54420 Bug #: 54420 Summary: Segmentation in decl_mangling_context Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lukeocam...@gmail.com Created attachment 28107 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28107 Preprocessed source file Discovered when compiling llvm+lldb. Preprocessed file attached. Stack trace: #0 0x0058f3b3 in decl_mangling_context (decl=0x2bf38508) at ../.././gcc/cp/mangle.c:759 #1 decl_mangling_context (decl=0x2bf38508) at ../.././gcc/cp/mangle.c:749 #2 0x005963a4 in write_name (decl=0x2bf38508, ignore_local_scope=ignore_local_scope@entry=0) at ../.././gcc/cp/mangle.c:795 #3 0x005931b4 in write_class_enum_type (type=) at ../.././gcc/cp/mangle.c:2424 #4 write_type (type=type@entry=0x2bf4e7e0) at ../.././gcc/cp/mangle.c:1903 #5 0x00596db9 in mangle_special_for_type (type=0x2bf4e7e0, code=0xd3042e "TV") at ../.././gcc/cp/mangle.c:3445 #6 0x0051062e in get_vtable_name (type=0x2bf4e7e0) at ../.././gcc/cp/class.c:709 ...
[Bug middle-end/54409] [4.8 Regression] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54409 Martin Jambor changed: What|Removed |Added Component|c |middle-end --- Comment #7 from Martin Jambor 2012-08-30 14:24:12 UTC --- This is a bug in inlining, not the c front-end, therefore I'm changing the component to middle-end (we really should have "ipa" component, though).
[Bug c++/54420] Segmentation fault in decl_mangling_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54420
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf
2012-08-30 14:33:01 UTC ---
gcc-4.8 is also affected.
Reduced:
class __lambda
{
virtual bool is_sub ();
};
[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #27 from Hin-Tak Leung 2012-08-30 14:56:46 UTC --- FWIW, I just filed the MFPR 3.1.x "make check" issue: https://gforge.inria.fr/tracker/index.php?func=detail&aid=14806&group_id=136&atid=619
[Bug rtl-optimization/50427] IRA fails to detect conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427 Catherine Gasnier changed: What|Removed |Added CC||lalhee at wanadoo dot fr --- Comment #2 from Catherine Gasnier 2012-08-30 15:31:15 UTC --- Hi, I had exactly the same problem, where IRA did not see the dependency between a register and one of it subreg. In our back, we also have hard registers in HImode, with adjacent register sequences used for SImode and DImode. For me, the issue was the way I defined the macro REGMODE_NATURAL_SIZE. I've had a look at your code and you defined it roughly the same way as I did: #define REGMODE_NATURAL_SIZE(MODE) (PSImode == (MODE) ? 2*UNITS_PER_WORD : UNITS_PER_WORD) This seems to be wrong. I think this macro is useful only if the natural size for a specific mode is smaller than UNIT_PER_WORD, which is not your case. You should try not to define this macro.
[Bug rtl-optimization/50427] IRA fails to detect conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427 Catherine Gasnier changed: What|Removed |Added CC||lalhee at wanadoo dot fr --- Comment #2 from Catherine Gasnier 2012-08-30 15:31:15 UTC --- Hi, I had exactly the same problem, where IRA did not see the dependency between a register and one of it subreg. In our back, we also have hard registers in HImode, with adjacent register sequences used for SImode and DImode. For me, the issue was the way I defined the macro REGMODE_NATURAL_SIZE. I've had a look at your code and you defined it roughly the same way as I did: #define REGMODE_NATURAL_SIZE(MODE) (PSImode == (MODE) ? 2*UNITS_PER_WORD : UNITS_PER_WORD) This seems to be wrong. I think this macro is useful only if the natural size for a specific mode is smaller than UNIT_PER_WORD, which is not your case. You should try not to define this macro. --- Comment #3 from Catherine Gasnier 2012-08-30 15:31:54 UTC --- Hi, I had exactly the same problem, where IRA did not see the dependency between a register and one of it subreg. In our back, we also have hard registers in HImode, with adjacent register sequences used for SImode and DImode. For me, the issue was the way I defined the macro REGMODE_NATURAL_SIZE. I've had a look at your code and you defined it roughly the same way as I did: #define REGMODE_NATURAL_SIZE(MODE) (PSImode == (MODE) ? 2*UNITS_PER_WORD : UNITS_PER_WORD) This seems to be wrong. I think this macro is useful only if the natural size for a specific mode is smaller than UNIT_PER_WORD, which is not your case. You should try not to define this macro.
[Bug target/54421] New: Extra movdqa when accessing quadwords in a 128-bit SSE register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54421
Bug #: 54421
Summary: Extra movdqa when accessing quadwords in a 128-bit SSE
register
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jeremie.det...@loria.fr
Dear all,
I've come across a strange behavior with GCC 4.7.1 (compiling to an
SSE2-capable processor) when trying to access the high and low 64-bit words of
a 128-bit SSE register, as in the following testcase:
8<
#include
#include
int test(const __m128i x)
{
union { __m128i v; uint64_t ui[2]; } c;
c.v = x;
return !(c.ui[0] | c.ui[1]);
}
>8
When compiling with -O2 or -O3, I obtain the following assembly code:
8<
test:
.LFB519:
.cfi_startproc
movdqa %xmm0, -40(%rsp)
movq-40(%rsp), %rax
movdqa %xmm0, -24(%rsp)
movq%rax, %rdx
orq -16(%rsp), %rdx
sete%al
movzbl %al, %eax
ret
.cfi_endproc
>8
Note the two movdqa instructions storing %xmm0 to the stack: the first one to
-40(%rsp), followed by an access the low 64 bits of %xmm0 at the same address,
and the second one to -24(%rsp), followed by an access the high 64 bits at
-16(%rsp). Obviously, one of the two movdqa's is useless.
Also note that replacing the union-based type-punning by a memcpy produces the
same assembly code.
This behavior was also reproduced with GCC 4.4.7, 4.5.3, and 4.6.3. However, it
does not happen with GCC 4.1.2. I haven't been able to narrow it down any
further.
A short investigation (given my very limited understanding of the internals of
GCC) suggests that the problem originates from the first Dead-Store Elimination
(dse1) pass. After the cse2 pass, the RTL looks correct:
8<
[...]
(insn 6 3 7 2 (set (mem/c:V2DI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [0 c.v+0 S16 A128])
(reg/v:V2DI 65 [ x ])) test.c:7 1096 {*movv2di_internal}
(expr_list:REG_DEAD (reg/v:V2DI 65 [ x ])
(nil)))
(insn 7 6 8 2 (set (reg:DI 67 [ c.ui ])
(mem/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [0 c.ui+0 S8 A128]))
test.c:8 62 {*movdi_internal_rex64}
(nil))
(insn 8 7 9 2 (set (reg:DI 68 [ c.ui+8 ])
(mem/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -8 [0xfff8])) [0 c.ui+8 S8 A64]))
test.c:8 62 {*movdi_internal_rex64}
(nil))
[...]
>8
Here, if I'm not mistaken, the V2DImode register containing x is stored at
-16(%frame_ptr), and its low and high 64-bit parts are accessed at
-16(%frame_ptr) and -8(%frame_ptr), respectively.
However, this changes after the next pass (dse1):
8<
[...]
(insn 24 3 25 2 (set (reg:DI 72)
(subreg:DI (reg/v:V2DI 65 [ x ]) 0)) test.c:7 -1
(nil))
(insn 25 24 6 2 (set (reg:DI 73)
(reg:DI 72)) test.c:7 -1
(expr_list:REG_DEAD (reg:DI 72)
(nil)))
(insn 6 25 7 2 (set (mem/c:V2DI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [0 c.v+0 S16 A128])
(reg/v:V2DI 65 [ x ])) test.c:7 1096 {*movv2di_internal}
(expr_list:REG_DEAD (reg/v:V2DI 65 [ x ])
(nil)))
(insn 7 6 8 2 (set (reg:DI 67 [ c.ui ])
(reg:DI 73)) test.c:8 62 {*movdi_internal_rex64}
(expr_list:REG_DEAD (reg:DI 73)
(nil)))
(insn 8 7 9 2 (set (reg:DI 68 [ c.ui+8 ])
(mem/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -8 [0xfff8])) [0 c.ui+8 S8 A64]))
test.c:8 62 {*movdi_internal_rex64}
(nil))
[...]
>8
Here, two extra instructions (24 and 25) were added to access the low part of x
directly, without bothering to store it in memory first. This is confirmed by
the dse1 dump, which reads as follows:
8<
[...]
**scanning insn=7
mem: (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0]))
after canon_rtx address: (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0]))
gid=0 offset=-16
processing const load gid=0[-16..-8)
trying to replace DImode load in insn 7 from V2DImode store in insn 6
deferring rescan insn with uid = 7.
deferring rescan insn with uid = 24.
deferring rescan insn with uid = 25.
-- replaced the loaded MEM with (reg 73)
mems_found = 0, cannot_delete = true
[...]
>8
Then, in pass subreg2, GCC decides to split the V2DImode register into two
DImode subregs. This generates a truckload of extra instructions, whose
operands eventually get spilled to memory in the reload pass. This is where I
think the extra movqda is coming from.
Thanks a lot for your help!
Cheers,
Jérémie.
[Bug middle-end/54394] [4.8 Regression] fatigue2 -flto run time regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54394 --- Comment #4 from Martin Jambor 2012-08-30 15:32:53 UTC --- (In reply to comment #3) > > You can try whether it fixes your regression too. > > Yes, it does. Thanks. Great, thanks. > > Did you check if you get the same run time with -flto and -fwhole-program? If > yes, it would probably mean that -flto is not working as it should on darwin. > How could I check that? With the patch, -fwhole-program is only 1% slower than -flto on my i686 desktop (the x86_64 machine is currently running a bootstrap). -flto can provide a "better-than-fwhole-program" when you use a linker plugin. I do not know what is the status of that on darwin (whether it works at all or what minimum ld version you need, etc.), you'll have to search yourself.
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388 --- Comment #9 from Benjamin Kosnik 2012-08-30 15:36:18 UTC --- BTW, we definitely need a comment on why this particular code is so tricky. // NB: Interesting use of comma operator semantics. at the very least... ;)
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388 --- Comment #10 from Florian Weimer 2012-08-30 15:39:21 UTC --- (In reply to comment #9) > BTW, we definitely need a comment on why this particular code is so tricky. > > // NB: Interesting use of comma operator semantics. > > at the very least... > > ;) Can the compiler warn about the original (buggy) code?
[Bug target/54252] [4.7/4.8 Regression] Bad alignment code generated for Neon loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252 --- Comment #8 from Eric Batut 2012-08-30 15:52:20 UTC --- The original bug instance is fixed on trunk (rev 190803). I had what I think is another instance of the same bug, where the error message is "alignment of array elements is greater than element size", and this is also fixed by rev 190803. (In reply to comment #7) > Fixed now I believe on trunk.
[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53787 --- Comment #11 from Martin Jambor 2012-08-30 15:58:40 UTC --- The aggregate functions and their use in inlining/ipa-cp heuristics is in, at least with my PHI predicate computing patch which I re-submitted today we even get a predicate for known loop iterations for function init today. This means that even today the function in your app should be inlined much more likely. In order to propagate stuff without inlining, IPA-CP must be enhanced which is something I am still only working on.
[Bug tree-optimization/54422] New: Merge adjacent stores of elements of a vector (or loads)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54422
Bug #: 54422
Summary: Merge adjacent stores of elements of a vector (or
loads)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
Hello,
#include
void f1(__m128d*dd,__m128d e){
double*d=(double*)dd;
d[0]=e[0];
d[1]=e[1];
}
void f2(__m128d*dd,__m128d e){
_mm_storeu_pd((double*)dd,e);
}
void f3(__m128d*dd,__m128d e){
__builtin_memcpy(dd,&e,16);
}
for this code, gcc -O3 -mavx2 generates:
for f2:
vmovupd%xmm0, (%rdi)
(it could possibly have guessed that the alignment was right, but I don't mind
today)
for f1:
vmovlpd%xmm0, (%rdi)
vmovhpd%xmm0, 8(%rdi)
(this is my main issue, could it merge those into a vmovupd?)
for f3:
vmovdqa%xmm0, -40(%rsp)
movq-40(%rsp), %rax
vmovapd%xmm0, -24(%rsp)
movq%rax, (%rdi)
movq-16(%rsp), %rax
movq%rax, 8(%rdi)
(I hope the sse memcpy patch at
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00336.html will eventually help
with that)
At tree level, for f1, we have:
_3 = BIT_FIELD_REF ;
MEM[(double *)dd_1(D)] = _3;
_6 = BIT_FIELD_REF ;
MEM[(double *)dd_1(D) + 8B] = _6;
merging those 2 looks like it might be possible (though I am not familiar with
that part of the compiler, maybe only the backend can handle it). Note that I
am interested in both the aligned and unaligned cases (if f1 takes a double*
argument instead of a __m128d*), and in both loads and stores.
Most relevant other bugs I found were: PR 41464, PR 23684, PR 47059.
[Bug other/54423] New: building trunk on Darwin 12.1 fails in building libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54423 Bug #: 54423 Summary: building trunk on Darwin 12.1 fails in building libraries Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: ne...@intrepid.com Building the trunk on Mac OS X 10.8.1 (Darwin 12.1.0) fails. Configuring libraries fails with the following error (e.g. libatomic): configure:3477: checking for C compiler default output file name configure:3499: /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/xgcc -B/eng/upc/dev/nenad/gcc-trunk/bld/./gcc/ -B/usr/local/x86_64-apple-darwin12.1.0/bin/ -B/usr/local/x86_64-apple-darwin12.1.0/lib/ -isystem /usr/local/x86_64-apple-darwin12.1.0/include -isystem /usr/local/x86_64-apple-darwin12.1.0/sys-include-g -O2 conftest.c >&5 Undefined symbols for architecture x86_64: "start", referenced from: -u command line option ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status The above uses the following link lines (produces with -v switch): /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/collect2 -dynamic -arch x86_64 -macosx_version_min 10.8.1 -weak_reference_mismatches non-weak -o a.out -L/eng/upc/dev/nenad/gcc-trunk/bld/./gcc /var/folders/z7/83zx0wdj4cx644rg7p7kgwb8gn/T//cc6kpstu.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v -idsym -dsym collect2 version 4.8.0 20120828 (experimental) /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/collect-ld -dynamic -arch x86_64 -macosx_version_min 10.8.1 -weak_reference_mismatches non-weak -o a.out -L/eng/upc/dev/nenad/gcc-trunk/bld/./gcc /var/folders/z7/83zx0wdj4cx644rg7p7kgwb8gn/T//cc6kpstu.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v This test links if I add "-lcrt1.o" on the command line. I have the latest Xcode loaded and my Mac is up to date.
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 --- Comment #3 from Jonathan Wakely 2012-08-30 16:40:48 UTC --- I don't know of any workaround so disabling the test seems like a good option
[Bug target/54252] [4.7/4.8 Regression] Bad alignment code generated for Neon loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252 --- Comment #9 from ramrad01 at arm dot com 2012-08-30 16:48:12 UTC --- On 30/08/12 16:52, eric.batut at allegorithmic dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252 > > --- Comment #8 from Eric Batut > 2012-08-30 15:52:20 UTC --- > The original bug instance is fixed on trunk (rev 190803). > I had what I think is another instance of the same bug, where the error > message > is "alignment of array elements is greater than element size", and this is > also > fixed by rev 190803. Good to hear that this fixes the original bug instance on trunk. I intend to do a backport to 4.7 next week if there are no more problems reported with this. Thanks, Ramana
[Bug middle-end/54417] lto1: internal compiler error: in edge_badness, at ipa-inline.c:793 with -profile-generate/profile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54417 Andrew Pinski changed: What|Removed |Added Component|lto |middle-end Summary|lto1: internal compiler |lto1: internal compiler |error: in edge_badness, at |error: in edge_badness, at |ipa-inline.c:793|ipa-inline.c:793 with ||-profile-generate/profile-u ||se --- Comment #1 from Andrew Pinski 2012-08-30 16:56:30 UTC --- I had the same issue with -fprofile-generate/-fprofile-use with an extra param set. I should be submitting the patch soon.
[Bug c++/54424] New: Compiler crash with -std=gnu++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54424
Bug #: 54424
Summary: Compiler crash with -std=gnu++0x
Classification: Unclassified
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nadia.cavall...@gmail.com
Setting up a MinGW/Qt 4.8.2 only environment...
In file included from ..\..\..\..\Qt\4.8.2\include/QtCore/qtconcurrentrun.h:1,
from ..\..\..\..\Qt\4.8.2\include/QtCore/QtCore:59,
from ..\..\..\..\Qt\4.8.2\include\QtGui/QtGui:3,
from
C:\L\ecs-traffico\ecs-traffico\ecst-configurator\configuratormainwin.cpp:9:
..\..\..\..\Qt\4.8.2\include/QtCore/../../src/corelib/concurrent/qtconcurrentrun.h:113:
internal compiler error: Segmentation fault
the exact version of GCC: gcc version 4.4.0 (GCC)
the system type: Windows 7
the exact command line passed to the gcc program triggering the bug :
g++ -c -std=gnu++0x -Wno-write-strings -g -frtti -fexceptions -mthreads -Wall
-DQT_LARGEFILE_SUPPORT -DDEBUG_MEM=1 -DVS_ENABLE_DEBUG -DVS_WINDOWS
-DDEBUG_MEM=1 -DVS_ENABLE_DEBUG -DVS_WINDOWS -DRS_NO_FPARSER -DRS_NO_QCADCMD
-DQT_DLL -DQT_QT3SUPPORT_LIB -DQT3_SUPPORT -DQT_XML_LIB -DQT_GUI_LIB
-DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT
-DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -I"..\..\..\..\Qt\4.8.2\include\QtCore"
-I"..\..\..\..\Qt\4.8.2\include\QtGui" -I"..\..\..\..\Qt\4.8.2\include\QtXml"
-I"..\..\..\..\Qt\4.8.2\include\Qt3Support" -I"..\..\..\..\Qt\4.8.2\include"
-I".\corelib\qt" -I".\ecst-clib" -I".\qcadlib\engine" -I".\qcadlib\debug"
-I".\qcadlib\math" -I".\qcadlib\gui" -I".\qcadlib\qcadcmd"
-I".\qcadlib\information" -I".\qcadlib\modification" -I".\qcadlib\filters"
-I".\qcadlib\fileio" -I".\qcadlib\actions" -I".\qcadlib\creation"
-I"..\..\..\..\Qt\4.8.2\include\ActiveQt" -I".moc" -I".ui"
-I"..\..\..\..\Qt\4.8.2\mkspecs\win32-g++" %1
Section code of error:
template
auto run(Functor functor, const Arg1 &arg1)
-> typename QtPrivate::QEnableIf::Value,
QFuture >::Type
{
typedef decltype(functor(arg1)) result_type;
return (new StoredFunctorCall1(functor,
arg1))->start();
}
only with option "-std=gnu++0x"
[Bug c++/54425] New: Rvalue/Lvalue overload resolution of templated function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54425
Bug #: 54425
Summary: Rvalue/Lvalue overload resolution of templated
function
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
Code below is rejected by 4.8.0. FWIW - it is accepted by clang32 and latest
VC.
-
template void f(T& t) {};
template void f(T&& t) {};
int main() {
int lv{11};
f(lv); // error: ambigues overload
}
-
[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #28 from Hin-Tak Leung 2012-08-30 17:32:35 UTC --- (In reply to comment #22) > > There are two curious things: > > 1. why does the 2nd stage drops to only about 600 byte. (I assume 20-30k is > > normal). > > That's certainly completely unexpected. I'd ask you to rebuild > cc1-checksum.o for stage2 and stage3 (move the .o's aside, run make -n > cc1-checksum.o, then manually add -v -save-temps to the compilation > line. Then attach a tarball with the .c and output files and the gcc -v > output to see if there are any obvious diffences between the compilations. *.c is the same - the difference in size comes from -gtoggle (added to stage 2).
[Bug target/54418] [4.8 Regression] [SH] Invalid operands for opcode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-30 AssignedTo|unassigned at gcc dot |olegendo at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 Hin-Tak Leung changed: What|Removed |Added CC||htl10 at users dot ||sourceforge.net --- Comment #9 from Hin-Tak Leung 2012-08-30 17:54:25 UTC --- Thread issue? Many of the newer mpfr make check also takes a long time/time out if it is left to the default tls enabled: https://gforge.inria.fr/tracker/?func=detail&atid=619&aid=14806&group_id=136
[Bug fortran/54426] New: [4.8 Regression] FAIL: gfortran.dg/common_6.f90 -O (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54426
Bug #: 54426
Summary: [4.8 Regression] FAIL: gfortran.dg/common_6.f90 -O
(internal compiler error) on powerpc-apple-darwin9
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: bur...@net-b.de
Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
Build: powerpc-apple-darwin9
On powerpc-apple-darwin9 compiling gfortran.dg/common_6.f90 gives an ICE after
revision 190710:
...
common ///g/! { dg-error "Syntax error" }
1
Error: Syntax error in COMMON statement at (1)
f951: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
A reduced test is
! somme comment
common /b/x/c/ ! { dg-error "Syntax error" }
common y/d/ ! { dg-error "Syntax error" }
common /e//f/ ! { dg-error "Syntax error" }
end
where the first comment line is needed to get the ICE. The backtrace is
#0 resolve_common_vars (sym=, named_common=) at ../../rel_work/gcc/fortran/resolve.c:911
#1 0x0007772c in resolve_common_blocks (common_root=0x41105370) at
../../rel_work/gcc/fortran/resolve.c:960
#2 0x000889f0 in resolve_types (ns=0x4182c000) at
../../rel_work/gcc/fortran/resolve.c:14209
#3 0x0007bfc0 in gfc_resolve (ns=0x4182c000) at
../../rel_work/gcc/fortran/resolve.c:14322
#4 0x000717f8 in gfc_parse_file () at ../../rel_work/gcc/fortran/parse.c:4398
#5 0x000aeb3c in gfc_be_parse_file () at
../../rel_work/gcc/fortran/f95-lang.c:191
#6 0x00589190 in compile_file () at ../../rel_work/gcc/toplev.c:546
#7 0x0058ab74 in toplev_main (argc=2, argv=0xbfffda74) at
../../rel_work/gcc/toplev.c:1863
#8 0x2024 in start ()
If I revert the patch for gcc/fortran/match.c, the ICE goes away without
regression (full gfortran test on powerpc-apple-darwin9). I did not find the
logic for this part of the patch at
http://gcc.gnu.org/ml/fortran/2012-08/msg00180.html.
[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005 --- Comment #13 from Benjamin Kosnik 2012-08-30 19:25:03 UTC --- Author: bkoz Date: Thu Aug 30 19:24:58 2012 New Revision: 190810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190810 Log: 2012-08-30 Benjamin Kosnik PR libstdc++/54005 continued * include/std/atomic: Use __atomic_lock_free with * include/bits/atomic_base.h: Same. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_base.h trunk/libstdc++-v3/include/std/atomic
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 Dominique d'Humieres changed: What|Removed |Added Target|x86_64-apple-darwin10 |x86_64-apple-darwin10 ||i686-pc-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-30 Host|x86_64-apple-darwin10 |x86_64-apple-darwin10 ||i686-pc-linux-gnu Summary|[4.8 Regression] Compiling |[4.8 Regression] Compiling |libstdc++-v3/src/c++11/rand |libstdc++-v3/src/c++11/rand |om.cc fails on |om.cc fails on platforms |x86_64-apple-darwin10 |not knowing rdrand Ever Confirmed|0 |1 Build|x86_64-apple-darwin10 |x86_64-apple-darwin10 ||i686-pc-linux-gnu --- Comment #1 from Dominique d'Humieres 2012-08-30 19:41:12 UTC --- It also fails on i686-pc-linux-gnu (see http://gcc.gnu.org/ml/gcc-regression/2012-08/txt9.txt).
[Bug rtl-optimization/50427] IRA fails to detect conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427 --- Comment #4 from Peter A. Bigot 2012-08-30 19:55:41 UTC --- Thanks for the suggestion. At the time this bug was reported, REGMODE_NATURAL_SIZE was not used as the target supported only 16-bit registers, so I don't believe that macro has anything to do with the behavior I noted. The current mspgcc back-end needs to support registers that are normally considered 16-bit, but can also hold 20-bit values (which must expand to 32-bits when in memory). I believe the use is proper and necessary for this situation. However, the back-end has a large number of other patches that were required to support this architecture, and it's possible that those contribute to why it works.
[Bug c++/54427] New: Expose more vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427 Bug #: 54427 Summary: Expose more vector extensions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gli...@gcc.gnu.org Hello, for gcc's vector extension to be really useful, we need a way to access a large enough subset of operations on vectors in a target-independent way. C exposes comparisons (< <= > >= == !=) and shifts (<< >>), but C++ doesn't. Either these operators should be implemented in the C++ front-end as well, or some builtins should be provided with the same role (__builtin_vec_less?).
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #2 from Ulrich Drepper 2012-08-30 20:19:35 UTC --- The instruction is generated by the compiler. If you try to compile a new compiler you have to make sure the tools used are recent enough to understand the output of the compiler.
[Bug c/54428] New: ICE in gimplify_expr, at gimplify.c:7591
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54428 Bug #: 54428 Summary: ICE in gimplify_expr, at gimplify.c:7591 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: kyle.nieme...@gmail.com Created attachment 28108 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28108 preprocessed file I get the compiler error "internal compiler error: in gimplify_expr, at gimplify.c:7591" on the line: rt[i] = f[i] - s_val * cpow(w[i], K) * b[i]; System information: -gcc version: GNU C (GCC) version 4.7.1 (x86_64-apple-darwin12.0.0) -system type: x86_64-apple-darwin12.0.0 -gcc build options: ../configure --enable-languages=c,c++,fortran --prefix=/usr/local/Cellar/gcc/4.7.1/gcc --datarootdir=/usr/local/Cellar/gcc/4.7.1/share --bindir=/usr/local/Cellar/gcc/4.7.1/bin --program-suffix=-4.7 --with-gmp=/usr/local/Cellar/gmp/5.0.5 --with-mpfr=/usr/local/Cellar/mpfr/3.1.1 --with-mpc=/usr/local/Cellar/libmpc/1.0 --with-system-zlib --enable-stage1-checking --enable-plugin --enable-lto --disable-multilib --disable-nls -command: gcc -c -o obj/cf.o cf.c -O0 -g3 -fbounds-check -Wunused-variable -Wunused-parameter -Wall -pedantic -ftree-vrp -std=c99 -Wextra -fno-strict-aliasing -fwrapv -v -save-temps -I. -compiler output: cf.c: In function 'cf': cf.c:290:30: internal compiler error: in gimplify_expr, at gimplify.c:7591 I've attached the preprocessed file cf.i. Strangely, when compiled with "gcc -c -o obj/cf.o cf.c -O3 -ffast-math -std=c99 -I.", there is no error (and the results are correct).
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #3 from Dominique d'Humieres 2012-08-30 20:37:59 UTC --- > The instruction is generated by the compiler. If you try to compile a new > compiler you have to make sure the tools used are recent enough to understand > the output of the compiler. Well, I think the compiler should check that the tools (or the CPU) support the output it emits. Isn't it the purpose of the configure stages? Concerning pre darwin12, there very little thing the user can do about which instructions as support.
[Bug tree-optimization/54422] Merge adjacent stores of elements of a vector (or loads)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54422 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-30 Ever Confirmed|0 |1
[Bug c++/54425] Rvalue/Lvalue overload resolution of templated function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54425 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-08-30 21:51:07 UTC --- I can see the same problem with gcc 4.8.0 20120819 (experimental) (Let me add that the test example should remove the invalid semicolons after each function definition). This should be DR 1164: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1164
[Bug target/54418] [4.8 Regression] [SH] Invalid operands for opcode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418 --- Comment #2 from Oleg Endo 2012-08-30 22:18:34 UTC --- Unfortunately I was not able to reproduce this case without the -fopenmp option, and that option requires threads, which are not available on the sh-sim config I've got here for testing. Kaz, could you please try out the following? Index: gcc/config/sh/sh.md === --- gcc/config/sh/sh.md(revision 190781) +++ gcc/config/sh/sh.md(working copy) @@ -1043,13 +1043,19 @@ ;; SImode unsigned integer comparisons ;; - +;; Usually comparisons of 'unsigned int >= 0' are optimized away completely. +;; However, especially when optimizations are off (e.g. -O0) such comparisons +;; might remain and we have to handle them. If the '>= 0' case wasn't +;; handled here, something else would just load a '0' into the second operand +;; and do the comparison. We can do slightly better by just setting the +;; T bit to '1'. (define_insn_and_split "cmpgeusi_t" [(set (reg:SI T_REG) (geu:SI (match_operand:SI 0 "arith_reg_operand" "r") -(match_operand:SI 1 "arith_reg_or_0_operand" "rN")))] +(match_operand:SI 1 "arith_reg_or_0_operand" "r")))] "TARGET_SH1" "cmp/hs%1,%0" - "&& satisfies_constraint_Z (operands[0])" + "&& satisfies_constraint_Z (operands[1])" [(set (reg:SI T_REG) (const_int 1))] "" [(set_attr "type" "mt_group")]) Just in case, I'll also test this as usually on sh-sim.
[Bug target/54429] New: [SH] SImode values get ferried through FPUL and FP regs for -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54429
Bug #: 54429
Summary: [SH] SImode values get ferried through FPUL and FP
regs for -O0
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: olege...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
I've noticed that, for some reason, when compiling code with -O0 SImode values
get ferried through FPUL reg and FP regs, like ..
lds r1,fpul
fstsfpul,fr1
mov r7,r4
fldsfr1,fpul
sts fpul,r5
.. which is really just:
mov r1,r5
mov r7,r4
In sh_hard_regno_mode_ok, I've tried doing:
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 190780)
+++ gcc/config/sh/sh.c(working copy)
@@ -11706,6 +11706,9 @@
if (FP_REGISTER_P (regno) && mode == SFmode)
return true;
+ if (FP_REGISTER_P (regno) && GET_MODE_CLASS (mode) != MODE_FLOAT)
+return false;
+
if (mode == V2SFmode)
{
if (((FP_REGISTER_P (regno) && (regno - FIRST_FP_REG) % 2 == 0)
.. and it makes the confusing FP reg usage go away. Somehow, I don't
understand why it would make sense to allow any integer modes in FP regs on SH.
No useful integer operations can be done with integer values in FP regs
anyway. The only purpose that I see, is to allow spilling of GP regs to FP
regs, which doesn't seem beneficial.
I've checked CSiBE results with the fix above. It causes a few increases and
decreases in the teem lib. The increases are, because GP regs are not spilled
to FP regs anymore and have to go to the stack, which causes some unlucky
displacement address changes. The decreases are because of the same, but where
displacement addresses are lucky. Also, weird cases disappear where FP regs
are pushed/popped in a function but are otherwise unused.
Kaz, do you happen to know why the sh_hard_regno_mode_ok function is the way it
is? I think The FP reg check after the V16SFmode check ...
if (FP_REGISTER_P (regno))
{
if (mode == SFmode
|| mode == SImode
would also become obsolete if the change above was applied?
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #49 from Oleg Endo 2012-08-30 22:54:23 UTC --- Kaz, if you have some time, could you please gather some CSiBE runtime numbers for '-mpretend-cmove' and without it? I've compared the result-size of the CSiBE set and with -mpretend-cmove there's a total decrease of 948 bytes, with a few opposite cases. My idea was to obsolete the -mpretend-cmove option, and instead tie its behavior the new option -mzdcbranch, which generally is supposed to control any kind of zero-displacement-branch handling.
[Bug c++/54430] New: [C++11] Range Based For Loop lhs scoping issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430
Bug #: 54430
Summary: [C++11] Range Based For Loop lhs scoping issue
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@koios.de
The scope of the iterating variable begins too early, i.e. it is already
available in the expression of the rhs.
This is a problem if the rhs expression includes the same identifier which is
shadowed by this issue.
Simple case:
int i[] = { };
for (int i : i);
fails to compile because the rhs 'i' will be the same as the lhs 'i' which is
not a valid expression for the range-based for-loop.
The range-based for-loop is equivalent to some for-construct. According to the
standard the above should compile because the scope of the lhs begins inside
the body of this substituted for-loop.
Just for completeness: The Evil case:
class MyType {
std::vector vec;
public:
const std::vector& foo() { return vec; }
};
MyType * t = new MyType;
for (MyType * t : t->foo());
this will not refuse to compile since everything is well-formed. The real
problem is that foo isn't called on the previously defined t but on the new
uninitialized t.
Re: [Bug other/54398] New: Incorrect ARM assembly when building with -fno-omit-frame-pointer -O2
On 29 Aug 2012, at 01:21, asharif at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398 > > Bug #: 54398 > Summary: Incorrect ARM assembly when building with >-fno-omit-frame-pointer -O2 >Classification: Unclassified > Product: gcc > Version: 4.6.4 >Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: other >AssignedTo: unassig...@gcc.gnu.org >ReportedBy: asha...@gcc.gnu.org > > > Created attachment 28096 > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28096 > Reduced test case > > Please see the attached cpp and h files. > Please report bugs as per http://gcc.gnu.org/bugs/ paying special attention to http://gcc.gnu.org/bugs/#dontwant Thanks, Ramana
[Bug other/54398] Incorrect ARM assembly when building with -fno-omit-frame-pointer -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398 --- Comment #1 from Ramana Radhakrishnan 2012-08-30 23:32:42 UTC --- On 29 Aug 2012, at 01:21, asharif at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398 > > Bug #: 54398 > Summary: Incorrect ARM assembly when building with >-fno-omit-frame-pointer -O2 >Classification: Unclassified > Product: gcc > Version: 4.6.4 >Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: other >AssignedTo: unassig...@gcc.gnu.org >ReportedBy: asha...@gcc.gnu.org > > > Created attachment 28096 > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28096 > Reduced test case > > Please see the attached cpp and h files. > Please report bugs as per http://gcc.gnu.org/bugs/ paying special attention to http://gcc.gnu.org/bugs/#dontwant Thanks, Ramana
[Bug c++/54431] New: [C++11] g++ crashes when compiling the following file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54431
Bug #: 54431
Summary: [C++11] g++ crashes when compiling the following file
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m1010...@gmail.com
$ cat y.cpp
template
struct foo
{
public:
void bar()
{
[this]{bar();}();
}
};
int main()
{
foo ss;
ss.bar();
}
$ g++ -v -save-temps -std=c++11 y.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120721/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--enable-multilib --disable-libssp --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.1 20120721 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -E -quiet -v -D_GNU_SOURCE
y.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o y.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include
/usr/local/include
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -fpreprocessed y.ii -quiet
-dumpbase y.cpp -mtune=generic -march=x86-64 -auxbase y -std=c++11 -version -o
y.s
GNU C++ (GCC) version 4.7.1 20120721 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1 20120721 (prerelease), GMP version 5.0.5,
MPFR version 3.1.1, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.7.1 20120721 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1 20120721 (prerelease), GMP version 5.0.5,
MPFR version 3.1.1, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8466381cd327359656bc3ec3a9c33398
y.cpp: In lambda function:
y.cpp:15:1: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug rtl-optimization/54369] Delayed-branch pass in reorg.c removes too many instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54369
Steve Ellcey changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Steve Ellcey 2012-08-31 00:30:01
UTC ---
I think I see where delete_related_insns is going wrong. We call it
with a JUMP instruction that we want to remove because we are just
jumping to the next instruction (a label) which we would get to anyway
without the jump, then after delete_related_insns removes the jump it
checks the label it was jumping to, and if it finds no uses it calls
delete_related_insns with that label. When delete_related_insns
is called with a label, it assumes it can remove all the code after
that label as unreachable. But the code after the label can be reached
by the default fall-through code sequence. So after removing a jump and
finding a label with no uses we should call delete_insn with that label,
not delete_related_insns.
So my proposed fix would be:
diff --git a/gcc/jump.c b/gcc/jump.c
index 9721fe1..fa3d65a 100644
--- a/gcc/jump.c
+++ b/gcc/jump.c
@@ -1207,7 +1207,7 @@ delete_related_insns (rtx insn)
/* This can delete NEXT or PREV,
either directly if NEXT is JUMP_LABEL (INSN),
or indirectly through more levels of jumps. */
- delete_related_insns (lab);
+ delete_insn (lab);
else if (tablejump_p (insn, NULL, &lab_next))
{
/* If we're deleting the tablejump, delete the dispatch table.
[Bug rtl-optimization/54369] Delayed-branch pass in reorg.c removes too many instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54369 --- Comment #3 from chaoyingfu at gcc dot gnu.org 2012-08-31 00:38:39 UTC --- The fall-through path of this jump has a barrier (resulted from __builtin_unreachable), and the target of this jump has a return instruction. The algorithm in reorg.c may be more conservative to keep this jump for code correctness. Just another solution to this issue. Thanks!
[Bug libobjc/54432] New: Memory leak when linking libobjc with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54432
Bug #: 54432
Summary: Memory leak when linking libobjc with gcc
Classification: Unclassified
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: karlk...@gmail.com
Very simple test case.
Created a main.m file with contents:
`int main(){ return 1; }`
Compile with gcc:
`gcc main.m -o main -lobjc`
Run valgrind:
`valgrind main`
Get memory leak:
==27005== HEAP SUMMARY:
==27005== in use at exit: 8,485 bytes in 133 blocks
==27005== total heap usage: 145 allocs, 12 frees, 11,053 bytes allocated
==27005==
==27005== LEAK SUMMARY:
==27005== definitely lost: 16 bytes in 1 blocks
==27005== indirectly lost: 16 bytes in 1 blocks
==27005== possibly lost: 0 bytes in 0 blocks
==27005== still reachable: 8,453 bytes in 131 blocks
==27005== suppressed: 0 bytes in 0 blocks
If I don't link libobjc then I get no memory leaks. Not sure if this is a gcc
or valgrind bug.
[Bug libobjc/54432] Memory leak when linking libobjc with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54432
--- Comment #1 from Karl Kirch 2012-08-31 02:06:50
UTC ---
Another test case.
Looks like I end up with lost memory for every class I define.
#include
@interface Test : Object
{}
@end
@implementation Test
@end
int main()
{
id t = [[Test alloc] init];
[t free];
return 0;
}
and Valgrind gives me
==28397== HEAP SUMMARY:
==28397== in use at exit: 10,136 bytes in 150 blocks
==28397== total heap usage: 169 allocs, 19 frees, 12,808 bytes allocated
==28397==
==28397== LEAK SUMMARY:
==28397==definitely lost: 32 bytes in 2 blocks
==28397==indirectly lost: 16 bytes in 1 blocks
==28397== possibly lost: 0 bytes in 0 blocks
==28397==still reachable: 10,088 bytes in 147 blocks
==28397== suppressed: 0 bytes in 0 blocks
[Bug libobjc/54432] Memory leak when linking libobjc with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54432 --- Comment #2 from Karl Kirch 2012-08-31 02:10:38 UTC --- GCC info gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)
[Bug libobjc/54432] Memory leak when linking libobjc with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54432 --- Comment #3 from Karl Kirch 2012-08-31 02:11:48 UTC --- GCC info gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)
[Bug c/54433] New: bogus -Wmissing-format-attribute warnings when "first to check" is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54433
Bug #: 54433
Summary: bogus -Wmissing-format-attribute warnings when "first
to check" is wrong
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com
For code like the following, GCC tries to convince me that any function taking
a ptr-to-char should be given the format attribute.
This is due to an incorrect fix for bug 1017 (the comments of which finally
made me realize the bug in my own code - it should be 2, not 0. Sigh, can't you
just autodetect the '...'? You give an error if any other nonzero number is
given)
((The correct fix is to check whether the ptr-to-char argument is being passed
to an attribute'd function. This seems to be almost, but not quite, entirely
unlike what happens when -Wmissing-format-attribute gives a correct warning.))
Bad: 4.3.6 .. 4.7.0
// compile with -Wmissing-format-attribute
#include
#include
__attribute__((format(printf, 1, 0) ))
void my_log(const char * fmt, ...)
{
va_list ap;
va_start(ap, fmt);
vfprintf(stderr, fmt, ap);
va_end(ap);
}
void not_a_log(const char *string __attribute__((unused)) )
{
my_log("this should not be a warning\n");
}
[Bug c++/50545] [C++0x][DR 1172] SFINAE does not handle an explicit type conversion (functional notation) with a braced-init-list well if target type is not dependent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50545 --- Comment #2 from Jason Merrill 2012-08-31 02:50:33 UTC --- Author: jason Date: Fri Aug 31 02:50:28 2012 New Revision: 190830 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190830 Log: PR c++/50545 PR c++/51222 * pt.c (instantiation_dependent_r): New. (instantiation_dependent_expression_p): New. (value_dependent_expression_p): Use it. SCOPE_REF is always dependent. * semantics.c (finish_decltype_type): Use it. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype40.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype41.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype42.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c
[Bug c++/51222] [C++11][SFINAE] Unevaluated combined delete new expression completely broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51222 --- Comment #6 from Jason Merrill 2012-08-31 02:50:35 UTC --- Author: jason Date: Fri Aug 31 02:50:28 2012 New Revision: 190830 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190830 Log: PR c++/50545 PR c++/51222 * pt.c (instantiation_dependent_r): New. (instantiation_dependent_expression_p): New. (value_dependent_expression_p): Use it. SCOPE_REF is always dependent. * semantics.c (finish_decltype_type): Use it. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype40.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype41.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype42.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c
[Bug c/54428] ICE in gimplify_expr, at gimplify.c:7591
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54428 Marek Polacek changed: What|Removed |Added CC||polacek at redhat dot com --- Comment #1 from Marek Polacek 2012-08-31 05:16:38 UTC --- Reproduced. Happens with 4.7/trunk, but not 4.6 and older. Only -std=c99 is needed, with -ffast-math the ICE does not happen.
[Bug c/54428] ICE in gimplify_expr, at gimplify.c:7591
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54428
--- Comment #2 from Marek Polacek 2012-08-31
05:46:07 UTC ---
Reduced. Note that the typedef is needed to trigger ICE.
typedef double _Complex fftw_complex;
extern fftw_complex *fftw_alloc_complex (int);
int
cf (int n)
{
int K = 75;
int nf = 1024;
int i;
fftw_complex *w = fftw_alloc_complex (nf);
fftw_complex *f = fftw_alloc_complex (nf);
double S[K * sizeof (double)];
double s_val = S[n];
fftw_complex *b = fftw_alloc_complex (nf);
fftw_complex *rt = fftw_alloc_complex (nf);
for (i = 0; i < nf; ++i)
{
rt[i] = f[i] - s_val * __builtin_cpow (w[i], K) * b[i];
}
}
[Bug fortran/54426] [4.8 Regression] FAIL: gfortran.dg/common_6.f90 -O (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54426 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-invalid-code CC||burnus at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #1 from Tobias Burnus 2012-08-31 06:19:12 UTC --- I think one needs something like the following. It needs some refining as the symtree name might be mangled for modules (__, cf. match.c's gfc_get_common). --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -2890,6 +2890,9 @@ gfc_undo_symbols (void) needs to be removed to stop the resolver looking for a (possibly) dead symbol. */ + if (p->common_block->head == p && !p->common_next) + gfc_delete_symtree (&p->ns->common_root, p->common_block->name); + if (p->common_block->head == p) p->common_block->head = p->common_next; else
[Bug c/54428] [4.7/4.8 Regression] ICE in gimplify_expr, at gimplify.c:7591
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54428
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-08-31
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.7.2
Summary|ICE in gimplify_expr, at|[4.7/4.8 Regression] ICE in
|gimplify.c:7591 |gimplify_expr, at
||gimplify.c:7591
Ever Confirmed|0 |1
--- Comment #3 from Jakub Jelinek 2012-08-31
06:57:24 UTC ---
Slightly more reduced:
typedef double _Complex C;
C
foo (C x, C y, double *s, double z, C w)
{
return y - z * __builtin_cpow (x, 75) * w;
}
