[Bug c++/57545] [4.7/4.8/4.9 Regression] Generation of debug symbols leads to internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57545 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/57532] [4.8/4.9 regression] operator broken when used on rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57532 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Howard Brodale brodhow at all2easy dot net changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #12 from Howard Brodale brodhow at all2easy dot net --- store the incremented v back into v is not quite right either. The pointer arithmetic *++arr[0][0] is incrementing the head pointer of the string array element one char past 'a' and not actually storing the shortened string back in there. If it was storing the shortened string there then the 'a' would be lost or written over which it is not. printf(%c\n,*++arr[0][0]);//works fine and prints s printf(%c\n,*--arr[0][0]);//works fine does print a as me s - the 1st ++; incrementing past 'a' a - the first --; dcrementing back to 'a' as - as prints now as expected as df ce me yu we - and here again, too, as is showing as expected. Take out the -- operation and these ass will be ss. 'a' is not lost nor written over by any storing back into v, here or no storing is going on. Just pointer that array arr gets moved over to point at the next character. char *arr2 = this is a test\n; int len_arr2 = 0; len_arr2 = strlen(++arr2); printf(length of arr2 is %i\n, len_arr2); printf(%c\n, *arr2--); len_arr2 = strlen(arr2); printf(length of arr2 is %i\n, len_arr2); puts(arr2); outputs: length of arr2 is 14 - ++; moving past the 't', one character less in string his is a test - 't' is missing now length of arr2 is 15 - --; moving back over the 't', one character more this is a test - 't' is back now; if storing in v happened then 't' would've been lost and would be not recoverable. Now, I have also recovered more knowledge about pointer arithmentic, with character strings. 'a' is not being destoyed or lost in the original context. Its just being ignored.
[Bug c++/57437] [4.7/4.8/4.9 Regression] C++11: mutable lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/57526] [4.8/4.9 Regression] use of X before deduction of auto error for seemingly good code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57526 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798 Rich Felker bugdal at aerifal dot cx changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #2 from Rich Felker bugdal at aerifal dot cx --- This does seem to be real, so please reopen it. The problem is that the final command line to the linker looks like: ... $(objs) -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed $(endfiles) Assuming the main program itself does not do any division or call raise, the first -lgcc does not pull in __div0, and the -lc does not pull in raise. However, if any function from libc which does get pulled in performs division, then a reference to __div0 is generated, and the second -lgcc pulls in __div0, which contains a reference to raise. This reference is never resolved. It seems the intent is that link_gcc_c_sequence uses --start-group and --end-group to avoid this problem when -static is used. However, this does not cover the case where no libc.so exists at all, and libc.a is all that's available. I wonder why the --start-group logic is only used for static linking and not unconditionally, since it should be a no-op for shared libraries anyway. FYI, I have received new reports of this bug from musl users, one who wanted to have libc.so be used but who installed it in the wrong location causing libc.a to get used instead, but the rest were users doing purely static-linked systems with no shared libraries at all.
[Bug c++/57043] [4.7/4.8/4.9 Regression] converting overloaded complex function pow in C++11 is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57043
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Jason Merrill jason at gcc dot gnu.org ---
OK, this is puzzling.
The issue is that GCC can't tell that the first pow is more specialized than
the second; deduction happens fine, but when we substitute in Tp(1) for Tp(2)
and Up we still have complextypename promote_2Tp(1), Tp(1)::type for the
return type, which looks different from complexTp(1), so deduction fails and
we decide it isn't more specialized.
I can't figure out what interpretation of the standard clang/EDG are using to
make this work. Are they actually instantiating promote_2? That doesn't seem
to be it, as they also accept the following, which seems clearly unordered to
me:
templatetypename D struct complex { };
template class T struct promote_1 { typedef T type; };
templatetypename T, typename U struct promote_2 { typedef T type; };
templatetypename Tp
complextypename promote_1Tp::type
pow(const complexTp x, const complexTp y);
templatetypename Tp, typename Up
complextypename promote_2Tp, Up::type
pow(const complexTp x, const complexUp y);
complexdouble (*powcc)(const complexdouble, const complexdouble) = pow;
[Bug plugins/57852] lib/plugin-support.exp incorrectly sets PLUGINCC to compilers in prev-gcc breaks testing on lean bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57852 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Please set PLUGIN_CC to the final build of the compilers in the gcc subdirectory. No, that would be wrong, PLUGINCC should be set to the compiler that was used to build the compiler, otherwise configuration mismatches can arise, for example if you don't bootstrap.
[Bug tree-optimization/57858] New: AVX2: ymm used for div, not for sqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858
Bug ID: 57858
Summary: AVX2: ymm used for div, not for sqrt
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
in the following example div uses ymm registries while sqr only xmm ones
gcc version 4.9.0 20130630 (experimental) [trunk revision 200570] (GCC)
cat avx2sqrt.cc
#includemath.h
double div() {
double s=0;
for (int i=0; i!=1024; ++i) s+=1./(i+1);
return s;
}
double sqr() {
double s=0;
for (int i=0; i!=1024; ++i) s+=sqrt(i+1);
return s;
}
c++ -std=c++11 -Ofast -S avx2sqrt.cc -march=corei7-avx -mavx2
-ftree-vectorizer-verbose=1 -Wall ; cat avx2sqrt.s
_Z3divv:
.LFB3:
.cfi_startproc
vmovdqa.LC1(%rip), %ymm6
xorl%eax, %eax
vxorpd%xmm1, %xmm1, %xmm1
vmovdqa.LC0(%rip), %ymm0
vmovdqa.LC2(%rip), %ymm5
vmovapd.LC3(%rip), %ymm2
jmp.L2
.p2align 4,,10
.p2align 3
.L3:
vmovdqa%ymm4, %ymm0
.L2:
vpaddd%ymm6, %ymm0, %ymm4
vpaddd%ymm5, %ymm0, %ymm0
addl$1, %eax
vextracti128$0x1, %ymm0, %xmm3
vcvtdq2pd%xmm0, %ymm0
vcvtdq2pd%xmm3, %ymm3
vdivpd%ymm0, %ymm2, %ymm0
vdivpd%ymm3, %ymm2, %ymm3
vaddpd%ymm0, %ymm3, %ymm0
cmpl$128, %eax
vaddpd%ymm0, %ymm1, %ymm1
jne.L3
vhaddpd%ymm1, %ymm1, %ymm1
vperm2f128$1, %ymm1, %ymm1, %ymm0
vaddpd%ymm0, %ymm1, %ymm0
vzeroupper
ret
.cfi_endproc
.LFE3:
.size_Z3divv, .-_Z3divv
.p2align 4,,15
.globl_Z3sqrv
.type_Z3sqrv, @function
_Z3sqrv:
.LFB4:
.cfi_startproc
movl$1, %eax
vmovsd.LC4(%rip), %xmm1
vxorpd%xmm0, %xmm0, %xmm0
jmp.L6
.p2align 4,,10
.p2align 3
.L7:
vcvtsi2sd%eax, %xmm1, %xmm1
vsqrtsd%xmm1, %xmm1, %xmm1
.L6:
addl$1, %eax
vaddsd%xmm1, %xmm0, %xmm0
cmpl$1025, %eax
jne.L7
rep; ret
.cfi_endproc
.LFE4:
.size_Z3sqrv, .-_Z3sqrv
[Bug middle-end/57859] New: -ftrapv does not trap on signed overflows for struct fields (32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57859
Bug ID: 57859
Summary: -ftrapv does not trap on signed overflows for struct
fields (32-bit mode)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code (which has a signed integer overflow) doesn't trap when
compiled at -O1 or above with -ftrapv on x86_64-linux. This applies to the
current gcc trunk, as well as gcc-4.6, gcc-4.7, and gcc-4.8.
$ gcc-trunk -v
gcc version 4.9.0 20130708 (experimental) [trunk revision 200751] (GCC)
$ gcc-trunk -m32 -O0 -ftrapv small.c
$ a.out
Aborted (core dumped)
$ gcc-trunk -m32 -O1 -ftrapv small.c
$ a.out
$ gcc-4.8 -m32 -O1 -ftrapv small.c
$ a.out
$ gcc-4.7 -m32 -O1 -ftrapv small.c
$ a.out
$ gcc-4.6 -m32 -O1 -ftrapv small.c
$ a.out
$
---
struct S
{
int f;
};
int
main ()
{
struct S s;
for (s.f = 1; s.f 0; ++s.f)
;
return 0;
}
---
The following code does trap in 32-bit mode (but still not in 64-bit):
int
main ()
{
int i;
for (i = 1; i 0; ++i)
;
return 0;
}
[Bug tree-optimization/57860] New: wrong code for bitwise ops with long long literal on x86_64-linux (32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57860
Bug ID: 57860
Summary: wrong code for bitwise ops with long long literal on
x86_64-linux (32-bit mode)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O2
and -O3 in 32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130708 (experimental) [trunk revision 200751] (GCC)
$ gcc-trunk -m32 -O2 reduced.c
$ a.out
0
$ gcc-trunk -m32 -O3 reduced.c
$ a.out
0
$ gcc-trunk -m32 -O0 reduced.c
$ a.out
1
$ gcc-4.8 -m32 -O2 reduced.c
$ a.out
1
$
int printf (const char *, ...);
int a, *b = a, c, d, e, *f = e, g, *h = d, k[1] = {1};
int
foo (int p)
{
for (;; g++)
{
for (; c; c--);
*f = *h = p ((0x1LL ^ a) *b);
if (k[g])
return 0;
}
}
int
main ()
{
foo (1);
printf (%d\n, d);
return 0;
}
[Bug c++/57850] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #3 from Andrey Ponomarenko aponomarenko at rosalab dot ru --- Please do not remove this option! I know that it's private option for debugging GCC only, but it's used in the ABI Compliance Checker tool: http://ispras.linuxbase.org/index.php/ABI_compliance_checker This tool is used by the army of maintainers of almost all Linux distributions to verify ABI changes in system libraries. The tool is also the core of the http://upstream-tracker.org/ service for tracking upstream changes in APIs of system libraries. If you remove this option then ABI Compliance Checker and upstream-tracker.org will stop working and DLL hell will return. Is there an alternative way to create translation unit dump of the header file by the new GCC 4.8? Is it possible to make this option working like in GCC=4.7? Thank you!
[Bug tree-optimization/57861] New: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57861
Bug ID: 57861
Summary: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk produces wrong code for the following testcase on
x86_64-linux when compiled at -O3 in 32-bit mode. This is a regression from
4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130708 (experimental) [trunk revision 200751] (GCC)
$ gcc-trunk -m32 -O3 reduced.c
$ a.out
1
$ gcc-trunk -m32 -O2 reduced.c
$ a.out
0
$ gcc-4.8 -m32 -O3 reduced.c
$ a.out
0
$
int printf (const char *, ...);
short a = 1, f;
int b, c, d, *g = b, h, i, j;
unsigned int e;
static int
foo (char p)
{
int k;
for (c = 0; c 2; c++)
{
i = (j = 0) || p;
k = i * p;
if (e k)
{
short *l = f;
a = d h;
*l = 0;
}
}
return 0;
}
int
main ()
{
*g = foo (a);
printf (%d\n, a);
return 0;
}
[Bug c++/57850] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #4 from Andrey Ponomarenko aponomarenko at rosalab dot ru --- It's also used for maintaining binary compatibility of glibc: http://sourceware.org/glibc/wiki/Testing/ABI_checker and by the API Sanity Checker tool for generating unit tests for C/C++ libraries: http://ispras.linuxbase.org/index.php/API_Sanity_Checker
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
Francesco Zappa Nardelli francesco.zappa.nardelli at gmail dot com changed:
What|Removed |Added
CC||francesco.zappa.nardelli@gm
||ail.com
--- Comment #16 from Francesco Zappa Nardelli francesco.zappa.nardelli at
gmail dot com ---
Dear all
a possibly related issue. Consider
struct S1 {
long f;
};
volatile struct S1 g;
struct S1 func_1 () {
return g;
}
void main () {
func_1 ();
}
This program, if compiled with a recent gcc svn:
$ gcc -v
Target: x86_64-unknown-linux-gnu
gcc version 4.9.0 20130625 (experimental) (GCC)
correctly loads the long at g.f at -O0. However the assembly generated at -O2:
func_1:
movqg(%rip), %rax
ret
main:
rep; ret
does not perform the volatile load access, which, as far as I understand, is
incorrect.
-francesco
[Bug libgcc/57851] [patch] unwinding via signal trampoline for kfreebsd*-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57851 --- Comment #2 from Petr.Salinger at seznam dot cz --- Posted in http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00304.html
[Bug lto/57602] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 --- Comment #6 from Igor Zamyatin izamyatin at gmail dot com --- Jan, have you had a chance to look at the problem?
[Bug c/57862] New: invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 Bug ID: 57862 Summary: invalid read struct uint32_t member (ARMV5) Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mendola at gmail dot com Created attachment 30481 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30481action=edit The preprocessed file # uname -a Linux tqma28 2.6.35.3 #1 PREEMPT Sun Sep 11 17:38:39 CEST 2011 armv5tejl GNU/Linux # gcc-4.7 -v -save-temps main.c -march=armv5t Using built-in specs. COLLECT_GCC=gcc-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.7/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv4t --with-float=soft --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-march=armv5t' '-mfloat-abi=soft' '-mtls-dialect=gnu' /usr/lib/gcc/arm-linux-gnueabi/4.7/cc1 -E -quiet -v -imultilib . -imultiarch arm-linux-gnueabi main.c -march=armv5t -mfloat-abi=soft -mtls-dialect=gnu -fpch-preprocess -o main.i ignoring nonexistent directory /usr/local/include/arm-linux-gnueabi ignoring nonexistent directory /usr/lib/gcc/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/arm-linux-gnueabi/4.7/include /usr/local/include /usr/lib/gcc/arm-linux-gnueabi/4.7/include-fixed /usr/include/arm-linux-gnueabi /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-march=armv5t' '-mfloat-abi=soft' '-mtls-dialect=gnu' /usr/lib/gcc/arm-linux-gnueabi/4.7/cc1 -fpreprocessed main.i -quiet -dumpbase main.c -march=armv5t -mfloat-abi=soft -mtls-dialect=gnu -auxbase main -version -o main.s GNU C (Debian 4.7.2-5) version 4.7.2 (arm-linux-gnueabi) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=15631 GNU C (Debian 4.7.2-5) version 4.7.2 (arm-linux-gnueabi) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=15631 Compiler executable checksum: da7c3c2f0b4be4af23076cf3c1dfbf58 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-march=armv5t' '-mfloat-abi=soft' '-mtls-dialect=gnu' as -v -march=armv5t -mfloat-abi=soft -meabi=5 -o main.o main.s GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Debian) 2.22 COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.7/:/usr/lib/gcc/arm-linux-gnueabi/4.7/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.7/:/usr/lib/gcc/arm-linux-gnueabi/ LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.7/:/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../:/lib/arm-linux-gnueabi/:/lib/:/usr/lib/arm-linux-gnueabi/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-march=armv5t' '-mfloat-abi=soft' '-mtls-dialect=gnu' /usr/lib/gcc/arm-linux-gnueabi/4.7/collect2 --sysroot=/ --build-id --no-add-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.3 -X --hash-style=both -m armelf_linux_eabi /usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi/crt1.o /usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi/crti.o /usr/lib/gcc/arm-linux-gnueabi/4.7/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabi/4.7 -L/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi -L/usr/lib/gcc/arm-linux-gnueabi/4.7/../../.. -L/lib/arm-linux-gnueabi -L/usr/lib/arm-linux-gnueabi main.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabi/4.7/crtend.o /usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi/crtn.o This is the following output executing it: # ./a.out myInAddr.s_addr: 513 theIpHeader-daddr: 513 1.2.3.4 1.2.0.0 and that 1.2.0.0 should be 1.2.3.4. The same code works fine on ARMV7 architectures or x86 I believe that the culprit is in the assignment: myInAddr.s_addr = theIpHeader-daddr; note that replacing that assignment with: memcpy(myInAddr.s_addr, (theIpHeader-daddr),
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- The infamous PR18501 *** This bug has been marked as a duplicate of bug 18501 ***
[Bug tree-optimization/18501] [4.7/4.8/4.9 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||gang.chen at asianux dot com --- Comment #63 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 57856 has been marked as a duplicate of this bug. ***
[Bug c++/51786] [c++0x] Invalid declaration with decltype accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51786 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/54366] [meta-bug] decltype issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54366 Bug 54366 depends on bug 51786, which changed state. Bug 51786 Summary: [c++0x] Invalid declaration with decltype accepted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51786 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/57854] Would like to have a warning for virtual overrides without C++11 override keyword
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Thiago Macieira from comment #0) I would like a new (optional) warning that would point out every C++ virtual override that is done without the C++11 keyword that indicates an override. By necessity, this warning would only be permitted in C++11 mode. Hi Thiago, I am so grateful for KDE that I would like to help here if possible. But I would like to ask the C++ maintainer whether this is something that would be accepted in mainline G++ and whether G++ has the capabilities to detect this easily. Jason, what do you think? Perhaps the same issues that made [[base_check]] to be dropped would affect the implementation of this warning? I don't know the specifics.
[Bug c++/57854] Would like to have a warning for virtual overrides without C++11 override keyword
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Thiago Macieira from comment #0) It should be in -Weffc++. Not unless a new C++11 edition of Effective C++ recommends using override on all overriding functions, and not unless we update -Weffc++ to correspond to something other than the first edition. This seems like something that would fit better into a plugin than the core compiler.
[Bug tree-optimization/57858] AVX2: ymm used for div, not for sqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- I'll look at this.
[Bug c++/57854] Would like to have a warning for virtual overrides without C++11 override keyword
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #2) (In reply to Thiago Macieira from comment #0) It should be in -Weffc++. Not unless a new C++11 edition of Effective C++ recommends using override on all overriding functions, and not unless we update -Weffc++ to correspond to something other than the first edition. This seems like something that would fit better into a plugin than the core compiler. We could add a new option -Wbase-check, no? Or we could also write a plugin and distribute it with GCC. I think it is something that could be generally used and an useful example of how to write plugins (and a testcase testing the plugin infrastructure).
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- This has all the indications of a mis-aligned memory access. Since you're on Linux, please make sure that the 'User faults' field in /proc/cpu/alignment shows a value of 2 (fixup) or 3 (fixup+warn). You can 'echo 3 /proc/cpu/alignment' in your startup scripts to ensure this setting, or you can hack it into the kernel source's arch/arm/mm/alignment.c (which is what I do).
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #2 from Gaetano Mendola mendola at gmail dot com --- I had 0. Putting 2 or 3 fixed the problem. Now my question is: who is faulty? Kernel configuration on this platform, the architecture, the compiler or even me ? BTW, compiling that code with clang even with 0 in /proc/cpu/alignment gives the right result.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|critical|normal
[Bug libstdc++/32354] libstdc++.so.6 missing RPATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354 Mark R. Bannister chapter34 at yahoo dot com changed: What|Removed |Added CC||chapter34 at yahoo dot com --- Comment #11 from Mark R. Bannister chapter34 at yahoo dot com --- I've also hit this problem on Solaris 10 building gcc 4.8.0 and it's been wasting an awful lot of time. I intend to use $ORIGIN in my RPATH but could not find a way to get an RPATH into libstdc++. Having tried LDFLAGS, CFLAGS and CXXFLAGS which get the RPATH into everything else ok *except* libstdc++, I am now going to try LD_RUN_PATH as suggested in #9. However, why has this been closed as RESOLVED INVALID? There needs to be a way of getting RPATHs successfully through to the built objects in a consistent and configurable way, and we don't have that today. Btw, re #8, see: http://technicalprose.blogspot.co.uk/2013/06/editing-dtrpath-on-solaris-elf-objects.html
[Bug c++/57863] New: std::vector::emplace_back() internal compiler error when passing wrong number of arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57863
Bug ID: 57863
Summary: std::vector::emplace_back() internal compiler error
when passing wrong number of arguments
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Passing wrong number of arguments into std::vector::emplace_back() causes an
internal compiler error:
#include vector
struct Xyz
{
Xyz(int, int);
};
int main() {
std::vectorXyz v;
v.emplace_back(1); // internal compiler error here
}
This is how I compile it:
/usr/local/ots/2/bin/g++ -v -c -o
/home/max/otsquant/build/Linux-x86_64-64.g++-debug/obj-mt/test-c++/test.o
-pthread -m64 -I/home/max/otsquant/src/c++ -D_GLIBCXX_USE_C99_MATH
-D__STDC_FORMAT_MACROS -D_GLIBCXX_USE_CLOCK_MONOTONIC
-DBOOST_THREAD_DONT_PROVIDE_INTERRUPTIONS -I/usr/local/ots/2/icu-50.1/include
-I/usr/local/ots/2/boost-1.53.0/include -I/usr/local/ots/2/include/python2.7
-g -Wall -Wextra -Wno-missing-field-initializers -Winit-self -Wcast-align
-Wmissing-include-dirs -Wpointer-arith -Wwrite-strings -Wno-non-virtual-dtor
-Wno-multichar -march=native -fdiagnostics-show-option -Werror=return-type
-Werror=format -Werror=format-extra-args -Werror=reorder -Werror=uninitialized
-std=gnu++11 -Werror=narrowing -fmessage-length=0 -falign-functions -MD -MP
-MF /home/max/otsquant/build/Linux-x86_64-64.g++-debug/obj-mt/test-c++/test.d
/home/max/otsquant/src/c++/test-c++/test.cc
Using built-in specs.
COLLECT_GCC=/usr/local/ots/2/bin/g++47
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.3-src/configure --prefix=/usr/local/ots/2
--program-suffix=47 --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --enable-checking=release --disable-multilib
--with-gmp-include=/usr/local/ots/2/include
--with-mpfr-include=/usr/local/ots/2/include
--with-mpc-include=/usr/local/ots/2/include
--with-ppl-include=/usr/local/ots/2/include
--with-cloog-include=/usr/local/ots/2/include
--with-binutils-include=/usr/local/ots/2/include
--with-gmp-lib=/usr/local/ots/2/lib64 --with-mpfr-lib=/usr/local/ots/2/lib64
--with-mpc-lib=/usr/local/ots/2/lib64 --with-ppl-lib=/usr/local/ots/2/lib64
--with-cloog-lib=/usr/local/ots/2/lib64
--with-binutils-lib=/usr/local/ots/2/lib64 --enable-languages=c,c++,fortran,lto
--enable-plugin --enable-initfini-array --enable-gold=default
Thread model: posix
gcc version 4.7.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-o'
'/home/max/otsquant/build/Linux-x86_64-64.g++-debug/obj-mt/test-c++/test.o'
'-pthread' '-m64' '-I' '/home/max/otsquant/src/c++' '-D'
'_GLIBCXX_USE_C99_MATH' '-D' '__STDC_FORMAT_MACROS' '-D'
'_GLIBCXX_USE_CLOCK_MONOTONIC' '-D' 'BOOST_THREAD_DONT_PROVIDE_INTERRUPTIONS'
'-I' '/usr/local/ots/2/icu-50.1/include' '-I'
'/usr/local/ots/2/boost-1.53.0/include' '-I'
'/usr/local/ots/2/include/python2.7' '-g' '-Wall' '-Wextra'
'-Wno-missing-field-initializers' '-Winit-self' '-Wcast-align'
'-Wmissing-include-dirs' '-Wpointer-arith' '-Wwrite-strings'
'-Wno-non-virtual-dtor' '-Wno-multichar' '-march=native'
'-fdiagnostics-show-option' '-Werror=return-type' '-Werror=format'
'-Werror=format-extra-args' '-Werror=reorder' '-Werror=uninitialized'
'-std=gnu++11' '-Werror=narrowing' '-fmessage-length=0' '-falign-functions'
'-MD' '-MP' '-MF'
'/home/max/otsquant/build/Linux-x86_64-64.g++-debug/obj-mt/test-c++/test.d'
'-shared-libgcc'
/usr/local/ots/2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1plus -quiet -v
-I /home/max/otsquant/src/c++ -I /usr/local/ots/2/icu-50.1/include -I
/usr/local/ots/2/boost-1.53.0/include -I /usr/local/ots/2/include/python2.7 -MD
/home/max/otsquant/build/Linux-x86_64-64.g++-debug/obj-mt/test-c++/test.d -MF
/home/max/otsquant/build/Linux-x86_64-64.g++-debug/obj-mt/test-c++/test.d -MP
-MQ /home/max/otsquant/build/Linux-x86_64-64.g++-debug/obj-mt/test-c++/test.o
-D_GNU_SOURCE -D_REENTRANT -D _GLIBCXX_USE_C99_MATH -D __STDC_FORMAT_MACROS -D
_GLIBCXX_USE_CLOCK_MONOTONIC -D BOOST_THREAD_DONT_PROVIDE_INTERRUPTIONS
/home/max/otsquant/src/c++/test-c++/test.cc -march=corei7 -mcx16 -msahf
-mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4
-mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1
-mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet -dumpbase
test.cc -m64 -auxbase-strip
/home/max/otsquant/build/Linux-x86_64-64.g++-debug/obj-mt/test-c++/test.o -g
-Wall -Wextra -Wno-missing-field-initializers -Winit-self -Wcast-align
-Wmissing-include-dirs -Wpointer-arith -Wwrite-strings -Wno-non-virtual-dtor
-Wno-multichar -Werror=return-type -Werror=format -Werror=format-extra-args
-Werror=reorder -Werror=uninitialized -Werror=narrowing -std=gnu++11 -version
[Bug c++/57863] std::vector::emplace_back() internal compiler error when passing wrong number of arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57863 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 57086 ***
[Bug c++/57086] Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57086 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||maxim.yegorushkin at gmail dot com --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 57863 has been marked as a duplicate of this bug. ***
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Gaetano Mendola from comment #2) who is faulty? Kernel configuration on this platform, the architecture, the compiler or even me ? All of the above. The architecture for getting mis-alignment very very wrong, the kernel for not enforcing correct handling of alignment faults, the compiler for sometimes generating mis-aligned accesses where the original code had none (there are PRs about that affecting at least ARM and I believe also SPARC), and your code for (apparently) having a load from a mis-aligned address where portable code should use memcpy() (the fact that memcpy() didn't help you is a consequence of one of those PRs). My ARMv5TE box' /proc/cpu/alignment currently reads User: 100669 all of which come from gcc's own test suite. That's just so wrong.
[Bug target/57848] internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-09 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- This issue can be reproduces on linux too.
[Bug tree-optimization/57864] New: [4.7 Regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57864 Bug ID: 57864 Summary: [4.7 Regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:862 Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: j-1fabfe3bb3efc0eaf9750936b80a1c20 at sharpwave dot de Created attachment 30482 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30482action=edit Reduced testcase, crashes 4.7.3 when compiled with -O3 -m64 The attached reduced testcase produces an ICE on 4.7.3 when compiled with -O3. -O2 is fine, as is 4.7.2 and 4.8.0. Compilation with -m32 likewise passes. $ /opt/gccs/4.7.3/bin/g++--4.7.3 -c -O3 -m64 testcase.cpp testcase.cpp: In function ‘void _ZL3fn1P1Xib.constprop.0(X*, bool)’: testcase.cpp:18:1: internal compiler error: in bitmap_set_replace_value, at tree-ssa-pre.c:862 This seems to be related to bug 55888 and bug 55107. Full details: $ /opt/gccs/4.7.3/bin/g++--4.7.3 -v -c -O3 -m64 testcase.cpp Using built-in specs. COLLECT_GCC=/opt/gccs/4.7.3/bin/g++--4.7.3 Target: x86_64-unknown-linux-gnu Configured with: ../src/gcc-4.7.3/configure --prefix=/opt/gccs/4.7.3 --program-suffix=--4.7.3 --enable-languages=c,c++ --disable-bootstrap Thread model: posix gcc version 4.7.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-O3' '-m64' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/gccs/4.7.3/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1plus -quiet -v -D_GNU_SOURCE testcase.cpp -quiet -dumpbase testcase.cpp -m64 -mtune=generic -march=x86-64 -auxbase testcase -O3 -version -o /tmp/ccm58ig9.s GNU C++ (GCC) version 4.7.3 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /opt/gccs/4.7.3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /opt/gccs/4.7.3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3 /opt/gccs/4.7.3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/x86_64-unknown-linux-gnu /opt/gccs/4.7.3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/backward /opt/gccs/4.7.3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include /opt/gccs/4.7.3/include /opt/gccs/4.7.3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include-fixed /usr/include End of search list. GNU C++ (GCC) version 4.7.3 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 4073671a6c09c56d7812f3b7ae137fde testcase.cpp: In function ‘void _ZL3fn1P1Xib.constprop.0(X*, bool)’: testcase.cpp:18:1: internal compiler error: in bitmap_set_replace_value, at tree-ssa-pre.c:862 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/57865] New: Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 Bug ID: 57865 Summary: Broken _save64gpr and _rest64gpr usage Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Created attachment 30483 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30483action=edit Test case. The 64-bit GPR save and restore sequence is broken and destroys the link register saved on the stack: powerpc-eabi-gcc -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=double -Os -S test.c diff -u test-4.7.2.s test-4.8.1.s --- test-4.7.2.s2013-07-09 13:09:56.418360402 +0200 +++ test-4.8.1.s2013-07-09 13:31:59.097519823 +0200 @@ -6,7 +6,7 @@ f: stwu 1,-56(1) mflr 0 - addi 11,1,-88 + addi 11,1,-80 stw 0,60(1) bl _save64gpr_29 mr 29,3 @@ -15,16 +15,16 @@ stw 6,24(1) bl g lwz 5,16(1) + lwz 6,24(1) + evmergelo 31,3,4 stw 3,8(1) stw 4,12(1) mr 3,29 - lwz 6,24(1) mr 4,30 - evldd 31,8(1) bl h - addi 11,1,-88 + addi 11,1,-80 efdctsiz 3,31 b _rest64gpr_29_x .size f, .-f - .ident GCC: (GNU) 4.7.2 + .ident GCC: (GNU) 4.8.1 .gnu_attribute 4, 2
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 --- Comment #18 from Mathias Gaunard mathias at gaunard dot com --- I'm not competent enough to make my own builds of GCC with patches, and I unfortunately do not have much time to contribute to this either. If someone can give me binaries for debian x86-64 I can do some tests though.
[Bug other/57866] New: Erroneous constant folding of SSE intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57866 Bug ID: 57866 Summary: Erroneous constant folding of SSE intrinsics Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: artem.alimarin at gmail dot com Created attachment 30484 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30484action=edit Tiny C++ bug reproducer The expected output of the resulting program: ok = 1 The real output with -O3: ok = 0 When compiled with -O0 the output is as expected. With -O3 the ADDSD instruction is not generated. As the result the MXCSR flags are not set correctly. Apparently the optimizer performs incorrect constant folding with SSE built-ins. Compilation: [artem@desktop ~]$ g++ -v -O3 -o sse sse.cpp Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) COLLECT_GCC_OPTIONS='-v' '-O3' '-o' 'sse' '-shared-libgcc' '-mtune=generic' /usr/libexec/gcc/x86_64-redhat-linux/4.4.7/cc1plus -quiet -v -D_GNU_SOURCE sse.cpp -quiet -dumpbase sse.cpp -mtune=generic -auxbase sse -O3 -version -o /tmp/cchr9Wzi.s ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include-fixed ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../x86_64-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/x86_64-redhat-linux /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/backward /usr/local/include /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include /usr/include End of search list. GNU C++ (GCC) version 4.4.7 20120313 (Red Hat 4.4.7-3) (x86_64-redhat-linux) compiled by GNU C version 4.4.7 20120313 (Red Hat 4.4.7-3), GMP version 4.3.1, MPFR version 2.4.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 223f8a064e7bf286655580f46ccd9b7c COLLECT_GCC_OPTIONS='-v' '-O3' '-o' 'sse' '-shared-libgcc' '-mtune=generic' as -V -Qy -o /tmp/ccZ96kdM.o /tmp/cchr9Wzi.s GNU assembler version 2.20.51.0.2 (x86_64-redhat-linux) using BFD version version 2.20.51.0.2-5.36.el6 20100205 COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-O3' '-o' 'sse' '-shared-libgcc' '-mtune=generic' /usr/libexec/gcc/x86_64-redhat-linux/4.4.7/collect2 --eh-frame-hdr --build-id -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o sse /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../.. /tmp/ccZ96kdM.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crtn.o
[Bug tree-optimization/57858] AVX2: ymm used for div, not for sqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch --- actually the code for div and sqr is different already for standard SSE c++ -std=c++11 -Ofast -S avx2sqrt.cc -ftree-vectorizer-verbose=1 -Wall ; cat avx2sqrt.s .L2: movdqa%xmm0, %xmm1 addl$1, %eax movdqa%xmm0, %xmm4 cmpl$256, %eax paddd%xmm5, %xmm1 pshufd$238, %xmm1, %xmm0 cvtdq2pd%xmm1, %xmm1 movapd%xmm3, %xmm7 paddd%xmm6, %xmm4 cvtdq2pd%xmm0, %xmm0 divpd%xmm0, %xmm7 movapd%xmm7, %xmm0 movapd%xmm3, %xmm7 divpd%xmm1, %xmm7 addpd%xmm7, %xmm0 addpd%xmm0, %xmm2 jne.L3 movapd%xmm2, -24(%rsp) movsd-16(%rsp), %xmm0 addsd%xmm2, %xmm0 ret .cfi_endproc .LFE3: .size_Z3divv, .-_Z3divv .p2align 4,,15 .globl_Z3sqrv .type_Z3sqrv, @function _Z3sqrv: .LFB4: .cfi_startproc movl$1, %eax movsd.LC4(%rip), %xmm1 xorpd%xmm0, %xmm0 jmp.L6 .p2align 4,,10 .p2align 3 .L7: cvtsi2sd%eax, %xmm1 sqrtsd%xmm1, %xmm1 .L6: addl$1, %eax addsd%xmm1, %xmm0 cmpl$1025, %eax jne.L7 rep; ret .cfi_endproc
[Bug libgomp/57867] New: SIGSEGV on libgomp into a GDB session
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57867 Bug ID: 57867 Summary: SIGSEGV on libgomp into a GDB session Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: velteyn at gmail dot com CC: jakub at gcc dot gnu.org Created attachment 30485 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30485action=edit the gdb session with the SIGSEGV Strange problem here. Attempting to debug (GDB 7.5) a GNU program compiled with gcc 4.7.2 The program is SPRING RTS and I used the last MINGW 32 on windows xp pro 32 the problem is on the file attach The problem is NOT present when I run the program normally (not into a gdb sesson)
[Bug c++/57868] New: misleading location for invalid variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57868
Bug ID: 57868
Summary: misleading location for invalid variadic template
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi all,
It's a detail, agreed, but below the location for the error could use
improvement:
$ cat parameter-pack.cc
template typename... A, typename... B
struct foo
{};
With g++-mp-4.9:
parameter-pack.cc:2:8: error: parameter pack 'A' must be at the end of the
template parameter list
struct foo
^
g++-mp-4.9: 1
For the records, this is what clang++-mp-3.3 says:
parameter-pack.cc:1:23: error: template parameter pack must be the last
template parameter
template typename... A, typename... B
^
1 error generated.
[Bug other/57866] Erroneous constant folding of SSE intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57866 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- There is no constant folding going on, the compiler simply sees the addition as dead code. To work around it, you would need to introduce a use of result, which would disable this tree optimization, but then you would get constant propagation indeed at the RTL level, so you also need to hide the constants from the compiler (with volatile or some asm). gcc has a -ftrapping-math option. It is not obvious whether it should preserve existing exceptions or only avoid introducing new ones (it may be split in 2 options at some point). But in any case, that support is incomplete, both in the middle-end and the x86 back-end. My advice would be to write such sensitive code in an inline asm.
[Bug tree-optimization/57858] AVX2: ymm used for div, not for sqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- -fno-tree-pre lets it vectorize sqr as well. PRE creates a jump to the middle of the loop body, which is nice but prevents vectorization.
[Bug middle-end/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #9 from Charles L. Wilcox zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net --- So, given a month has gone by, should I expect any response or action on this bug-report?
[Bug c++/53094] constexpr vector subscripting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094 --- Comment #15 from Marc Glisse glisse at gcc dot gnu.org --- r200822 | glisse | 2013-07-09 17:58:36 +0200 (Tue, 09 Jul 2013) | 11 lines 2013-07-09 Marc Glisse marc.gli...@inria.fr PR c++/53094 gcc/cp/ * semantics.c (cxx_eval_bit_field_ref): Handle VECTOR_CST. gcc/testsuite/ * g++.dg/cpp0x/constexpr-53094-1.C: Adjust. * g++.dg/ext/vector24.C: New testcase.
[Bug c++/53000] Conditional operator does not behave as standardized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000 --- Comment #25 from Marc Glisse glisse at gcc dot gnu.org --- (not a complete fix) r200821 | glisse | 2013-07-09 17:55:49 +0200 (Tue, 09 Jul 2013) | 9 lines 2013-07-09 Marc Glisse marc.gli...@inria.fr PR c++/53000 gcc/cp/ * call.c (build_conditional_expr_1): Preserve xvalues. gcc/testsuite/ * g++.dg/cpp0x/decltype17.C: Adjust.
[Bug c++/53094] constexpr vector subscripting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |glisse at gcc dot gnu.org --- Comment #16 from Marc Glisse glisse at gcc dot gnu.org --- Fixed, I guess. Please open a new PR if there are other vector operations that work in regular code but not in constexpr.
[Bug middle-end/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Maybe Uros can help.
[Bug tree-optimization/57864] [4.7 Regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57864 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Created attachment 30486 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30486action=edit slightly reduced test case in plain C Doesn't depend on C++, this plain C version also ICEs 4.7.3.
[Bug middle-end/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #11 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Paolo Carlini from comment #10) Maybe Uros can help. On an x86 target using the legacy x87 instructions and the 80-bit registers, a load of a 64-bit or 32-bit value in memory into the 80-bit registers counts as a format conversion and an signaling NaN input will turn into a quiet NaN in the register format.
Trouble running GCC compiled program using XOP intrinsic instructions?
Hi,
I'm getting a seg-fault running this code.
#include emmintrin.h
#include x86intrin.h
#include stdio.h
#include stdint.h
void print_2_64_bit_ints(const char * label, __m128i m64_r)
{
int *val = (int *) m64_r;
printf(%s: %d %d\n, label, val[0], val[1]);
}
int main()
{
__m128i HADDQinput = _mm_set_epi8(4, 3, 2, 1, 8, 7, 5, 3, 7, 6, 5, 4, 9,
0, 3, 3);
//__m128i RESULT = _mm_haddq_epi8(HADDQinput);
//_mm_empty();
//print_2_64_bit_ints(Result , RESULT);
return 0;
}
The GCC compiler flags used are -msse3 -msse4 -mxop -mavx and I'm compiling
this with GCC-TDM 4.7.1-2.
If I run the code through GDB it gets up to this line
__m128i HADDQinput = _mm_set_epi8(4, 3, 2, 1, 8, 7, 5, 3, 7, 6, 5, 4, 9, 0,
3, 3);
and it crashes on line 603 in emmintrin.h. I also noticed that this only
occurs if the header x86intrin.h is included otherwise the program exits
fine. I'm using an AMD-8150 FX (Bulldozer) processor with these instructions
available according to CPU-Z (CPUID)
MMX(+), SSE(1,2,3,3S,4.1,4.2,4A), x86-64, AMD-V, AES,AVX,XOP
Someone told me that the fault occurs due to an Intel instruction 'vmovd
xmm0..' using WinDbg.
thanks,
Andrew
--
View this message in context:
http://gcc.1065356.n5.nabble.com/Trouble-running-GCC-compiled-program-using-XOP-intrinsic-instructions-tp952132.html
Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug c++/57831] [4.7/4.8/4.9 Regression] pointer to member function inaccessible through using statement (or ICE)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57831 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.4 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.7.4/4.8.2/4.9.
[Bug c++/57751] [4.7/4.8/4.9 Regression] ICE in cxx_eval_indirect_ref, at cp/semantics.c:7648
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57751 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.4 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.7.4/4.8.1/4.9.
[Bug c++/57545] [4.7/4.8/4.9 Regression] Generation of debug symbols leads to internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57545 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.7.4/4.8.2/4.9.
[Bug c++/57532] [4.8/4.9 regression] operator broken when used on rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57532 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.8.2/4.9.
[Bug c++/57526] [4.8/4.9 Regression] use of X before deduction of auto error for seemingly good code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57526 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.2 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.8.2/4.9.
[Bug c++/57437] [4.7/4.8/4.9 Regression] C++11: mutable lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.4 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.7.4/4.8.2/4.9.
[Bug c++/54367] [meta-bug] lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 57437, which changed state. Bug 57437 Summary: [4.7/4.8/4.9 Regression] C++11: mutable lambdas http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #12 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #11) (In reply to Paolo Carlini from comment #10) Maybe Uros can help. On an x86 target using the legacy x87 instructions and the 80-bit registers, a load of a 64-bit or 32-bit value in memory into the 80-bit registers counts as a format conversion and an signaling NaN input will turn into a quiet NaN in the register format. Also, using -msse2 -mfpmath=sse on 32bit target won't help, since 32bit ABI mandates that FP values are returned in x87 register. Your test will work when compiled with -msse2 -mfpmath=sse -mno-fp-ret-in-387. But note that -mno-fp-ret-in-387 is a compiler option that changes ABI. The ABI is just wrong for the underlying x87 hardware as far as NaNs are concerned.
[Bug c++/57658] [4.9 Regression] ICE in tsubst_copy, at cp/pt.c:12213
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57658 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/54367] [meta-bug] lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 57658, which changed state. Bug 57658 Summary: [4.9 Regression] ICE in tsubst_copy, at cp/pt.c:12213 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57658 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/57415] [4.9 Regression] New PPC testsuite failure C++ compound literarl expr unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57415 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/57751] [4.7/4.8/4.9 Regression] ICE in cxx_eval_indirect_ref, at cp/semantics.c:7648
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57751 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks! Jason, 4.8.1 is already out, I guess you mean 4.8.2.
[Bug middle-end/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks Uros, you are providing plenty of detaild which I largely ignored. Thus, realistically, do you think this issue is largely unfixable?
[Bug c++/57471] [4.9 Regression] Bizarre error for template parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57471 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug debug/57389] ICE in dbx_reg_number, at dwarf2out.c:10507 on powerpc-spe target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57389 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #7 from Janis Johnson janis at gcc dot gnu.org --- I'm getting the ICE described in the submitter's description in 13 C tests for powerpc-none-eabispe, and the patch in comment 5 fixes it.
[Bug libitm/56801] Internal Compiler Error when compiling relaxed transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56801 --- Comment #3 from Mike Spear spear at cse dot lehigh.edu --- Patrick, I just tried again, with gcc --version: gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 Result: $ gcc -std=gnu11 -g -O2 -fgnu-tm -pthread -c testcase.c -o testcase.o testcase.c: In function 'slabs_adjust_mem_requested': testcase.c:29:6: internal compiler error: in expand_call_tm, at trans-mem.c:2280 Could it be a Ubuntu thing?
[Bug c++/57869] New: [C++11] Casting a object pointer to a function pointer should not warn about a forbidden conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57869 Bug ID: 57869 Summary: [C++11] Casting a object pointer to a function pointer should not warn about a forbidden conversion Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.kruegler at googlemail dot com gcc 4.9.0 20130616 (experimental) diagnoses a warning for the following code compiled with the flags: -Wall -pedantic -std=c++11 //- void* po = 0; void (*pf)() = reinterpret_castdecltype(pf)(po); // #2 static_assert(sizeof(po) = sizeof(pf), Conversion not supported); //- main.cpp|2|warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object [enabled by default] Given that 5.2.10 p8 says: Converting a function pointer to an object pointer type or vice versa is conditionally-supported. and since to my knowledge gcc supports such conversions (without that ::dlopen wouldn't work), the warning should be removed in the context of C++11.
[Bug tree-optimization/57864] [4.7 Regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57864 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- The ICE on 4.7 branch started with the PR55107 backport in r195755.
[Bug c++/57870] New: Internal compiler error in use of emplace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57870
Bug ID: 57870
Summary: Internal compiler error in use of emplace
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyakubovich at gmail dot com
In the following code, S lacks a constructor that accepts an int. Subsequently,
g++ crashes on use of emplace:
#include queue
struct S {
int x;
friend bool operator(S const, S const) { return false; }
};
int main() {
std::priority_queueS q;
q.emplace(1);
return 0;
}
A similar problem occurs with use of std::vector, however a correct error is
first issued:
#include vector
struct S {
int x;
};
int main() {
std::vectorS q;
q.emplace(q.begin(), 1);
return 0;
}
[Bug middle-end/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #14 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Paolo Carlini from comment #13) Thanks Uros, you are providing plenty of detaild which I largely ignored. Thus, realistically, do you think this issue is largely unfixable? This issue is unfortunately unfixable. x87 and x86-32 ABI are just not designed to handle all details of IEEE 754 standard.
[Bug c++/57870] Internal compiler error in use of emplace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57870 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 57086 ***
[Bug c++/57086] Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57086 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||eyakubovich at gmail dot com --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 57870 has been marked as a duplicate of this bug. ***
[Bug middle-end/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, thanks.
[Bug target/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 Charles L. Wilcox zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net changed: What|Removed |Added Attachment #30239|0 |1 is obsolete|| --- Comment #16 from Charles L. Wilcox zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net --- Created attachment 30487 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30487action=edit Expanded unit-test code to set signaling-NaN values via 'union' aliasing. Adding code to demonstrate how to generate a signaling-NaN using the existing ABI along with the return through the x87 register restriction.
[Bug target/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #17 from Charles L. Wilcox zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net --- Okay... so why not avoid the x87 restriction and use aliasing to load the correct value? I've updated my example to show how I was doing exactly this for some unit-test code I created.
[Bug target/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #18 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Charles L. Wilcox from comment #17) Okay... so why not avoid the x87 restriction and use aliasing to load the correct value? Load to x87 stack? The very moment sNaN gets loaded (using fldl or flds) will be converted to qNaN. You can do some trick here (and the compiler can pass FP value in integer registers), but there is no guarantee that the value won't move through x87 stack registers.
[Bug c++/57471] [4.9 Regression] Bizarre error for template parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57471 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed by r200852.
[Bug c++/57869] [C++11] Casting a object pointer to a function pointer should not warn about a forbidden conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57869 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-07-09 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Seems easy to fix. We got this (outdated) comment: if (pedantic (complain tf_warning)) /* Only issue a warning, as we have always supported this where possible, and it is necessary in some cases. DR 195 addresses this issue, but as of 2004/10/26 is still in drafting. */ warning (0, ISO C++ forbids casting between pointer-to-function and pointer-to-object); thus it seems just matter of suppressing he warning for c++11 (and c++1y) and updating the comment.
[Bug fortran/57871] New: gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871 Bug ID: 57871 Summary: gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1) Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: john.harper at vuw dot ac.nz gfortran 4.8.1 -freal-4-real-16 gives real(16) kind with selected_real_kind(1) but it ought to give real(8) because that is the smallest decimal precision available with that compiler option. Same problem with -freal-4-real-10 giving real(10) instead of real(8). Evidence: cayley[~/Jfh] % cat testprecision.f90 implicit none integer,parameter:: p1 = selected_real_kind(1), dp = kind(1d0) print *,'kind(1.0_p1)',kind(1.0_p1),'precision(1.0_p1)',precision(1.0_p1) print *,'kind(1.0_dp)',kind(1.0_dp),'precision(1.0_dp)',precision(1.0_dp) end cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -freal-4-real-16 -Wall -Wextra -fno-strict-aliasing -fwrapv testprecision.f90 cayley[~/Jfh] % ./a.out kind(1.0_p1) 16 precision(1.0_p1) 33 kind(1.0_dp) 8 precision(1.0_dp) 15 cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -freal-4-real-10 -Wall -Wextra -fno-strict-aliasing -fwrapv testprecision.f90 cayley[~/Jfh] % ./a.out kind(1.0_p1) 10 precision(1.0_p1) 18 kind(1.0_dp) 8 precision(1.0_dp) 15 cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -v Using built-in specs. COLLECT_GCC=/local/scratch/gf/bin/gfortran COLLECT_LTO_WRAPPER=/local/scratch/gf/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /local/scratch/gcc-4.8-20130530/configure --prefix=/local/scratch/gf --enable-languages=c,fortran --disable-libada --with-local-prefix=/local/scratch --with-gmp=/local/scratch Thread model: posix gcc version 4.8.1 20130530 (prerelease) (GCC) cayley[~/Jfh] %
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 Chen Gang gang.chen at asianux dot com changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #7 from Chen Gang gang.chen at asianux dot com --- (In reply to Manuel López-Ibáñez from comment #6) The infamous PR18501 *** This bug has been marked as a duplicate of bug 18501 *** Thanks.
[Bug tree-optimization/18501] [4.7/4.8/4.9 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #64 from Chen Gang gang.chen at asianux dot com --- (In reply to Manuel López-Ibáñez) Firstly, thank you very much for keeping tracing this bug almost 10 years, and provided your suggestions as much as possible. What you have done is valuable to developers (at least to me); at least the developers can easily and quickly know about this gcc common issue in time, and they will notice about it and think another ways to process this issue in their own projects (e.g. firstly compile with -O0 to see warnings). And sorry for I am not quite familiar with gcc compilier implementation, so at least now, I can not fix this issue, although of cause this issue really can be fixed (just as what you said). Thanks again.
[Bug c++/57402] [4.9 Regression] ICE: in make_decl_rtl, at varasm.c:1147 when initializing variable-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57402 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed by r200860.
[Bug target/12081] Gcc can't be compiled with -mregparm=3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081 --- Comment #24 from Stefan Kristiansson stefan.kristiansson at saunalahti dot fi --- (In reply to Uroš Bizjak from comment #23) (In reply to Mikael Pettersson from comment #22) FWIW, the updated patch for gcc 4.9 bootstraps and regtests cleanly on several hosts (x86_64, sparc64, powerpc64, armv5tel, m68k). Please post the patch to gcc-patches@ mailing list for a review. Done: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00400.html
[Bug regression/57766] [4.9 Regression]: gcc.sum c-c++-common/cilk-plus/AN/sec_implicit_ex.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57766 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Balaji V. Iyer from comment #2) This issue should be fixed in SVN revision 200581. Thanks, Balaji V. Iyer. Confirmed; fixed at 200581. Thanks.
[Bug c++/54170] Call to lambda elided
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170 James Y Knight foom at fuhm dot net changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #13 from James Y Knight foom at fuhm dot net --- Possibly should be backported to 4.7 branch?
[Bug c/57872] New: ICE occurs for cross-compile of PPC target with e500v2 core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57872
Bug ID: 57872
Summary: ICE occurs for cross-compile of PPC target with e500v2
core
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: super.lzh at gmail dot com
Created attachment 30488
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30488action=edit
Preprocessed file
[Issue]
When I use gcc-4.8.1 to cross-compile below C program for PPC target with
e500v2 core, following ICE appears, same C file can be compiled correctly for
targets with e500mc/e5500/x86 core.
$ powerpc-poky-linux-gnuspe-gcc -m32 -mcpu=8548 -mabi=spe -mspe
-mfloat-gprs=double -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
--sysroot=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/p1022ds -O2
-pipe -g -feliminate-unused-debug-types -g -O2 -fno-strict-aliasing -pipe -Wall
-I../../../../../include -I../../../../../include -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed -L../../../../../lib my_test.c -lm -o my_test
my_test.c: In function 'create_Result_file':
my_test.c:43:1: internal compiler error: in change_address_1, at
emit-rtl.c:2019
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$
More observation: during my trial, when the array size is equal to 4096 or
smaller than 4096, compile can pass, otherwise build will fail.
[Source file]
#include float.h
#include stdio.h
#include stdlib.h
#include string.h
#include errno.h
#include limits.h
#include unistd.h
#include fcntl.h
#include errno.h
#include sys/signal.h
#include math.h
#define M_PIl 3.1415926535897932384626433832795029L
int create_Result_file()
{
int i, nbVal;
double tabR[2], Inc;
char *F_name;
int fp;
F_name = result_file;
nbVal = 2;
Inc = (2 * M_PIl) / nbVal;
for (i = 0; i nbVal; i++) {
tabR[i] = hypot(cos(Inc * i), sin(Inc * i));
}
fp = open(F_name, O_RDWR | O_CREAT | O_TRUNC, 0777);
if (!fp) {
printf(error opening file);
close(fp);
return -1;
} else {
for (i = 0; i nbVal; i++) {
write(fp, tabR[i], sizeof(double));
}
close(fp);
return 0;
}
}
int main(int argc, char *argv[])
{
create_Result_file();
return 0;
}
[Preprocessed file]
Attached my_test.i
[gcc version]
$ powerpc-poky-linux-gnuspe-gcc -v
Using built-in specs.
COLLECT_GCC=powerpc-poky-linux-gnuspe-gcc
COLLECT_LTO_WRAPPER=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/libexec/ppce500v2-poky-linux-gnuspe/gcc/powerpc-poky-linux-gnuspe/4.8.1/lto-wrapper
Target: powerpc-poky-linux-gnuspe
Configured with:
/local/home/b19537/workspace/poky-os/p1022ds/tmp/work-shared/gcc-4.8.1-r0/gcc-4.8.1/configure
--build=x86_64-linux --host=x86_64-linux --target=powerpc-poky-linux-gnuspe
--prefix=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr
--exec_prefix=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr
--bindir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/bin/ppce500v2-poky-linux-gnuspe
--sbindir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/bin/ppce500v2-poky-linux-gnuspe
--libexecdir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/libexec/ppce500v2-poky-linux-gnuspe
--datadir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/share
--sysconfdir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/etc
--sharedstatedir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/com
--localstatedir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/var
--libdir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/lib/ppce500v2-poky-linux-gnuspe
--includedir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/include
--oldincludedir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/include
--infodir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/share/info
--mandir=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/local/home/b19537/workspace/poky-os/p1022ds/tmp/sysroots/x86_64-linux
--with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu
--enable-libstdcxx-pch --program-prefix=powerpc-poky-linux-gnuspe-
--without-local-prefix --enable-lto --enable-libssp --disable-bootstrap
--disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu
--enable-linker-build-id --with-ppl=no
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #6 from Dongsheng Song dongsheng.song at gmail dot com --- Linux gcc 4.4.5 (Debian GNU/Linux 6.0), gcc 4.4.7 (Red Hat Enterprise Linux Server release 6.4) failed too.
[Bug c++/54170] Call to lambda elided
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org --- The patch does seem safe enough for 4.7, even though I usually prefer not to backport C++11 fixes to older release series.
[Bug c++/54170] Call to lambda elided
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.0 |4.7.4 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.7.4.
