[Bug c++/60994] New: gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994
Bug ID: 60994
Summary: gcc does not recognize hidden/shadowed enumeration as
valid nested-name-specifier
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: momchil.velikov at gmail dot com
gcc version 4.10.0 20140428 (experimental) (GCC)
Compiling (with c++ -c -std=c++11 b.cc) the following program
enum struct A
{
n = 3
};
int
foo()
{
int A;
return A::n;
}
results in the error:
b.cc: In function 'int foo()':
b.cc:10:10: error: 'A' is not a class, namespace, or enumeration
return A::n;
^
According to the C++11 Standard, [basic.lookup.qual] #1
If a :: scope resolution operator in a nested-name-specifier is not preceded
by a decltype-specifier, lookup of the name preceding that :: considers only
namespaces, types, and templates whose specializations are types.
GCC ought not to resolve A to the local variable, but to the enumeration
type. This is very similar to the example in the standard
struct A
{
static int n;
};
int
foo()
{
int A;
return A::n;
}
which is compiled correctly by GCC, though.
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Implicit enum to int conversion is not provided for a scoped enumeration.
[Bug target/60996] New: Bad code (I.e. needless insns) with option momit-leaf-frame-pointer; side-effect on non-leaf functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60996 Bug ID: 60996 Summary: Bad code (I.e. needless insns) with option momit-leaf-frame-pointer; side-effect on non-leaf functions Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meisenmann@fh-salzburg.ac.at Using the option '-momit-leaf-frame-pointer' (with -fno-omit-frame-pointer) has a side-effect on non-leaf functions. The code-snippets afterwards (produced with an i386-elf cross-compiler for an IA32-target) will show the difference: A) Without the option momit-leaf-frame-pointer: Example1: pushl %ebp movl %esp, %ebp pushl %ebx subl $8, %esp movl (%eax), %ebx pushl 12(%ebp) pushl 8(%ebp) pushl %ecx pushl %edx pushl %eax call *12(%ebx) movl -4(%ebp), %ebx leave ret B) Option '-momit-leaf-frame-pointer' used: Example1: pushl %ebp movl %esp, %ebp pushl %ebx subl $8, %esp movl (%eax), %ebx pushl 12(%ebp) pushl 8(%ebp) pushl %ecx pushl %edx pushl %eax call *12(%ebx) addl $24, %esp movl -4(%ebp), %ebx leave ret In this case there'a an additional stack-adjustment (addl $24, %esp) before the final stack-leave instruction. Some other examples with less forwarded call-arguments have shown a few pop-insn instead of an 'add'. These additional instruction(s) directly before reverting the stack-frame has no functional effect, but will consume a few CPU-cycles.
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #1)
Implicit enum to int conversion is not provided for a scoped enumeration.
That said it is strange that gcc also rejects a plain enum:
markus@x4 /tmp % cat foo.cpp
enum A
{
n = 3
};
int
foo()
{
int A;
return A::n;
}
markus@x4 /tmp % g++ -c -std=c++11 -O3 foo.cpp
foo.cpp: In function ‘int foo()’:
foo.cpp:10:10: error: ‘A’ is not a class, namespace, or enumeration
return A::n;
^
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994
--- Comment #3 from Momchil Velikov momchil.velikov at gmail dot com ---
(In reply to Markus Trippelsdorf from comment #1)
Implicit enum to int conversion is not provided for a scoped enumeration.
This is not the reported error.
In fact, the correct output of the compiler would be to report the invalid
implicit conversion. It does not.
With explicit conversion to int, the compiler still gives an error, but the
error message is not helpful and obscures the cause of the problem, i.e.,
compiling this:
enum struct A
{
n = 3
};
int
foo()
{
int A;
return int(A::n);
}
results in:
b.cc: In function 'int foo()':
b.cc:10:10: error: expected primary-expression before 'int'
return int(A::n);
^
b.cc:10:10: error: expected ';' before 'int'
b.cc:10:10: error: expected primary-expression before 'int'
[Bug ipa/60990] [4.9/4.10 Regression] ICE: in try_make_edge_direct_virtual_call, at ipa-prop.c:2796 with -O3 -fno-early-inlining -fno-ipa-cp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60990 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-29 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.1 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r205019.
[Bug bootstrap/60984] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Isn't it --enable-checking=yes vs. --enable-checking=release ? Bet that is the most important change since 4.9.0 branch creation.
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|RESOLVED|NEW Last reconfirmed||2014-04-29 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Momchil Velikov from comment #0) According to the C++11 Standard, [basic.lookup.qual] #1 If a :: scope resolution operator in a nested-name-specifier is not preceded by a decltype-specifier, lookup of the name preceding that :: considers only namespaces, types, and templates whose specializations are types. Confirmed. C++03 said During the lookup for a name preceding the :: scope resolution operator, object, function, and enumerator names are ignored.
[Bug bootstrap/60984] [4.9 Regression] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Priority|P2 |P1 Known to work||4.10.0, 4.9.0 Version|4.9.0 |4.9.1 Summary|AIX: gcc-4.9.0 bootstrap|[4.9 Regression] AIX: |fails in stage-2|gcc-4.9.0 bootstrap fails ||in stage-2 Known to fail||4.9.1
[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org --- Most of the libstdc++ changes are for C++11 allocator support, which is required for conformance. Some changes I made in bits/alloc_traits.h might have negatively affected compile time though.
[Bug c++/60992] [4.9/4.10 Regression] ICE in tsubst_copy, at cp/pt.c:12637
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60992 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-29 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.9.1 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- This first started to be rejected (but no ICE) with r196747, and started to error out + ICE afterwards with r197811.
[Bug rtl-optimization/60901] [4.8/4.9/4.10 Regression] ICE: SIGSEGV in add_to_deps_list with -fsel-sched-pipelining-outer-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901
Andrey Belevantsev abel at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org
--- Comment #3 from Andrey Belevantsev abel at gcc dot gnu.org ---
The ix86_dependencies_evaluation_hook has the following code:
26230 /* Assume that region is SCC, i.e. all immediate
predecessors
26231of non-head block are in the same region. */
26232 FOR_EACH_EDGE (e, ei, bb-preds)
26233 {
The comment is wrong for selective scheduling with pipelining of outer loops
enabled, as the regions then are formed started from the innermost loops and
going up to the outer loops. So there could be a hole in the outer loop
region.
Fixed easily below like this, the comment has also to be adjusted of course.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 895ebbb..3f572fc 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -26233,7 +26233,8 @@ ix86_dependencies_evaluation_hook (rtx head, rtx tail)
{
/* Avoid creating of loop-carried dependencies through
using topological odering in region. */
- if (BLOCK_TO_BB (bb-index) BLOCK_TO_BB (e-src-index))
+ if (rgn == CONTAINING_RGN (e-src-index)
+BLOCK_TO_BB (bb-index) BLOCK_TO_BB
(e-src-index))
add_dependee_for_func_arg (first_arg, e-src);
}
}
[Bug tree-optimization/60971] [4.9/4.10 Regression] Wrong code when coercing unsigned char to bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60971 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32702 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32702action=edit gcc49-pr60971.patch Agreed, but I'd say the bug is in the tailc pass then, it assumes conversion from QImode integer type with 8-bit precision to QImode bool type with 1-bit precision doesn't need any code, when that is not true, during expansion in those cases we apply REDUCE_BIT_FIELD.
[Bug tree-optimization/60997] New: -fopenmp conflicts with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60997 Bug ID: 60997 Summary: -fopenmp conflicts with -floop-interchange Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: grosser at gcc dot gnu.org, jakub at gcc dot gnu.org, mircea.namolaru at inria dot fr Created attachment 32703 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32703action=edit Test for three variants of the matrix product Compiling the attached code with -Ofast gives the following timing at run time [Book15] Fortran/omp_tst% gfc -Ofast omp_tst_4_db_2.f90 [Book15] Fortran/omp_tst% time a.out 94378416668672.000 Elapsed time = 3.73266600 seconds 94378416668672.000 Elapsed time = 0.572250004 seconds 94378416668672.000 Elapsed time = 6.92336698 seconds 94378416668672.000 Elapsed time = 0.477573003 seconds 11.704u 0.030s 0:11.73 100.0%0+0k 0+0io 2pf+0w Adding -floop-interchange at compile time gives [Book15] Fortran/omp_tst% gfc -Ofast omp_tst_4_db_2.f90 -floop-interchange [Book15] Fortran/omp_tst% time a.out 94378416668672.000 Elapsed time = 0.573578995 seconds 94378416668672.000 Elapsed time = 0.568631000 seconds 94378416668672.000 Elapsed time = 0.568514999 seconds 94378416668672.000 Elapsed time = 0.470331997 seconds 2.195u 0.015s 0:02.21 99.5%0+0k 0+0io 0pf+0w i.e., the three variants of the loop are transformed to the fastest one. Adding -fopenmp (and -fexternal-blas -framework vecLib) gives [Book15] Fortran/omp_tst% gfc -Ofast omp_tst_4_db_2.f90 -floop-interchange -fopenmp -fexternal-blas -framework vecLib [Book15] Fortran/omp_tst% time a.out 94378416668672.000 Elapsed time = 1.81436701 seconds 94378416668672.000 Elapsed time = 0.128869001 seconds 94378416668672.000 Elapsed time = 2.00254200 seconds 94378416668672.000 Elapsed time = 2.92049998E-002 seconds 31.030u 0.064s 0:04.00 777.2%0+0k 4+4io 2pf+0w i.e., the loop interchange is prevented by the -fopenmp option. This is probably due to the fact that the -fopenmp option is processed before the graphite optimizations. The last timings are for the MATMUL intrinsic as a reference (using the system BLAS gives a 15 times speed-up).
[Bug libstdc++/59476] gdb pretty-printer cannot print C++11 _Rb_tree_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59476 --- Comment #1 from Pawel Sikora pluto at agmk dot net --- 4.9.0 released with unusable pretty printers :/
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994 --- Comment #5 from Momchil Velikov momchil.velikov at gmail dot com --- Proposed fix: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01938.html
[Bug libstdc++/59476] gdb pretty-printer cannot print C++11 _Rb_tree_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59476 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-29 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Mine.
[Bug tree-optimization/60971] [4.9/4.10 Regression] Wrong code when coercing unsigned char to bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60971 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #32702|0 |1 is obsolete|| --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32704 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32704action=edit gcc49-pr60971.patch Updated patch based on IRC discussion.
[Bug tree-optimization/60997] -fopenmp conflicts with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60997 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- IIRC -fopenmp has similar issues for vectorization (it defeats points-to analysis)
[Bug c/60998] New: [MIPS] -O3 produces infinite while() loop. -O2 produces correct code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60998
Bug ID: 60998
Summary: [MIPS] -O3 produces infinite while() loop. -O2
produces correct code.
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: exmortis at yandex dot ru
1. The compiler toolchain was downloaded from CodeSourcer site:
http://sourcery.mentor.com/public/gnu_toolchain/mips-linux-gnu/mips-2013.11
-36-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2
2. Unpacked to the home dir:
tar jxf mips-2013.11-36-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2
3. Version checking:
chibisov@lazar:~$ ./mips-2013.11/bin/mips-linux-gnu-gcc -v Using built-in
specs.
COLLECT_GCC=./mips-2013.11/bin/mips-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/chibisov/mips-2013.11/bin/../libexec/gcc/mips-linu
x-gnu/4.8.1/lto-wrapper
Target: mips-linux-gnu
Configured with:
/scratch/cmoore/fall2013-linux-final/src/gcc-4.8-2013.11/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=mips-linux-gnu
--enable-threads --disable-libmudflap --disable-libssp
--disable-libstdcxx-pch --with-arch-32=mips32r2 --with-arch-64=mips64r2
--with-float=hard --with-mips-plt --enable-extra-sgxxlite-multilibs
--with-gnu-as --with-gnu-ld --with-specs='%{save-temps: -fverbose-asm}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=11
-D__CS_SOURCERYGXX_REV__=36' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.11-36'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/mips-linux-gnu/libc
--with-build-sysroot=/scratch/cmoore/fall2013-linux-final/install/opt/codeso
urcery/mips-linux-gnu/libc
--with-gmp=/scratch/cmoore/fall2013-linux-final/obj/pkg-2013.11-36-mips-linu
x-gnu/mips-2013.11-36-mips-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/cmoore/fall2013-linux-final/obj/pkg-2013.11-36-mips-lin
ux-gnu/mips-2013.11-36-mips-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/cmoore/fall2013-linux-final/obj/pkg-2013.11-36-mips-linu
x-gnu/mips-2013.11-36-mips-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr
--with-isl=/scratch/cmoore/fall2013-linux-final/obj/pkg-2013.11-36-mips-linu
x-gnu/mips-2013.11-36-mips-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr
--with-cloog=/scratch/cmoore/fall2013-linux-final/obj/pkg-2013.11-36-mips-li
nux-gnu/mips-2013.11-36-mips-linux-gnu.extras/host-libs-i686-pc-linux-gnu/us
r
--with-libelf=/scratch/cmoore/fall2013-linux-final/obj/pkg-2013.11-36-mips-l
inux-gnu/mips-2013.11-36-mips-linux-gnu.extras/host-libs-i686-pc-linux-gnu/u
sr --enable-libgomp --disable-libitm --disable-libssp
--enable-poison-system-directories
--with-build-time-tools=/scratch/cmoore/fall2013-linux-final/install/opt/cod
esourcery/mips-linux-gnu/bin
--with-build-time-tools=/scratch/cmoore/fall2013-linux-final/install/opt/cod
esourcery/mips-linux-gnu/bin SED=sed Thread model: posix gcc version 4.8.1
(Sourcery CodeBench Lite 2013.11-36) chibisov@lazar:~$
4. Minimal test file t.c:
void *memset(void *s, int c, int count)
{
if (count) {
char *d = s;
do {
*d++ = c;
} while (--count);
}
return s;
}
5. The compiler is run with recommended keys (Reporting Bugs from
http://gcc.gnu.org/bugs/#detailed)
chibisov@lazar:~$ ./mips-2013.11/bin/mips-linux-gnu-gcc -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations --save-temps
-O3 -c t.c chibisov@lazar:~$
No warnings or errors are shown.
6. The contents of t.i is the following:
# 1 t.c
# 1 command-line
# 1
/home/chibisov/mips-2013.11/mips-linux-gnu/libc/usr/include/stdc-predef.h
1 3 4 # 30
/home/chibisov/mips-2013.11/mips-linux-gnu/libc/usr/include/stdc-predef.h
3 4 # 1
/home/chibisov/mips-2013.11/mips-linux-gnu/libc/usr/include/bits/predefs.h
1 3 4 # 31
/home/chibisov/mips-2013.11/mips-linux-gnu/libc/usr/include/stdc-predef.h
2 3 4 # 1 command-line 2 # 1 t.c
void *memset(void *s, int c, int count)
{
if (count) {
char *d = s;
do {
*d++ = c;
} while (--count);
}
return s;
}
7. The contents of t.s is the following:
.file 1 t.c
.section .mdebug.abi32
.previous
.nanlegacy
.gnu_attribute 4, 1
.abicalls
.option pic0
# -G value = 0, Arch = mips32r2, ISA = 33
# GNU C (Sourcery CodeBench Lite 2013.11-36) version 4.8.1 (mips-linux-gnu)
# compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version
3.1.1-p2, MPC version 1.0.1
# GGC heuristics: --param ggc-min-expand=100 --param
ggc-min-heapsize=131072
# options passed: -fpreprocessed t.i -meb
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 --- Comment #30 from Dominique d'Humieres dominiq at lps dot ens.fr --- Since at least gcc 4.8.2, -floop-interchange is able to apply it to the test in comment 25 (see also pr60997): [Book15] f90/bug% gfortran-fsf-4.8 -Ofast pr14741.f90 -floop-interchange [Book15] f90/bug% time a.out 0.48877399910.2399826 0.492u 0.007s 0:00.50 98.0%0+0k 0+0io 0pf+0w [Book15] f90/bug% gfortran-fsf-4.8 -Ofast pr14741.f90 [Book15] f90/bug% time a.out 3.9007499910.2399826 3.897u 0.015s 0:03.91 99.7%0+0k 0+0io 1pf+0w However compiling it with -floop-nest-optimize --param loop-block-tile-size=xx, gives the following error (see comment 18) f951: warning: iteration 31 invokes undefined behavior [-Waggressive-loop-optimizations] f951: note: containing loop f951: warning: iteration 31 invokes undefined behavior [-Waggressive-loop-optimizations] f951: note: containing loop pr14741.f90:6:0: warning: iteration 31 invokes undefined behavior [-Waggressive-loop-optimizations] B=0.1D0 ^ f951: note: containing loop pr14741.f90:5:0: warning: iteration 31 invokes undefined behavior [-Waggressive-loop-optimizations] A=0.1D0 ^ f951: note: containing loop for any values of xx I have tested. If I add -fno-aggressive-loop-optimizations, the code segfaults (Access to an undefined portion of a memory object) at run time.
[Bug c++/60999] [4.9 Regression] ICE when static_cast from constexpr in specialization of template-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60999 --- Comment #1 from Deniz Bahadir D.Bahadir at GMX dot de --- Created attachment 32706 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32706action=edit preprocessed source generated by GCC with option '-save-temps'
[Bug bootstrap/60984] [4.9 Regression] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed|2014-04-28 00:00:00 |2014-4-29 Known to work|4.9.0 | Known to fail||4.9.0 --- Comment #6 from David Edelsohn dje at gcc dot gnu.org --- Torbjorn: What release of GCC are you using as the system compiler to bootstrap?
[Bug tree-optimization/61000] New: No loop interchange for inner loop along the slow index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000 Bug ID: 61000 Summary: No loop interchange for inner loop along the slow index Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: grosser at gcc dot gnu.org, mircea.namolaru at inria dot fr Graphite is unable to do the loop interchange when the inner loop is along the slow index of an array: [Book15] Fortran/omp_tst% cat loop.f90 module parms implicit none private integer, parameter, public :: num = 1024 integer, parameter, public :: dp = kind(0.0d0) end module parms program loops use parms implicit none real(kind=dp), dimension(:, :), allocatable :: a, c integer :: i, j, k, n_iter=100 integer(8) :: start, finish, counts allocate(a(num,num),c(num,num)) call random_number(a) c = 0 call system_clock (start, counts) do k=1,n_iter do i=1,num !c(i,1) = 0.5*(a(i,2) - a(i,num)) !c(i,num) = 0.5*(a(i,1) - a(i,num-1)) do j=2,num-1 c(i,j) = 0.5*(a(i,j+1) - a(i,j-1)) end do end do end do call system_clock (finish) print *, sum(abs(c)) ! To ensure computation print *, Elapsed time = , (finish - start) / real(counts, kind=8), seconds c = 0 call system_clock (start, counts) do k=1,n_iter ! do i=1,num !c(i,1) = 0.5*(a(i,2) - a(i,num)) !c(i,num) = 0.5*(a(i,1) - a(i,num-1)) ! end do do j=2,num-1 do i=1,num c(i,j) = 0.5*(a(i,j+1) - a(i,j-1)) end do end do end do call system_clock (finish) print *, sum(abs(c)) ! To ensure computation print *, Elapsed time = , (finish - start) / real(counts, kind=8), seconds end program loops [Book15] Fortran/omp_tst% gfc -Ofast -floop-interchange loop.f90 [Book15] Fortran/omp_tst% time a.out 174350.51293227341 Elapsed time = 2.19437698 seconds 174350.51293227341 Elapsed time = 0.140062999 seconds 2.347u 0.011s 0:02.36 99.5%0+0k 0+0io 30pf+0w This may be a duplicate of pr36011, but the timings are not affected by adding -fno-tree-pre -fno-tree-loop-im. Note that gcc with -floop-interchange is able to optimize the matrix product (see pr14741 and pr60997). This also affects the polyhedron test air.f90. With the following patch --- air.f902009-08-28 14:22:26.0 +0200 +++ air_va.f902014-04-19 13:10:44.0 +0200 @@ -400,8 +400,8 @@ ! ! COMPUTE THE FLUX TERMS ! - DO i = 1 , MXPx - DO j = 1 , MXPy + DO j = 1 , MXPy + DO i = 1 , MXPx ! ! compute vanleer fluxes ! @@ -657,8 +657,8 @@ ENDDO ! ! COMPUTE THE FLUX TERMS - DO i = 1 , MXPx - DO j = 1 , MXPy + DO j = 1 , MXPy + DO i = 1 , MXPx ! ! compute vanleer fluxes ! the execution time goes from 3.2s to 2.7s (with -Ofast, with/without -floop-interchange).
[Bug lto/61001] New: Builtin memcpy and memset cannot be overridden when -flto is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61001 Bug ID: 61001 Summary: Builtin memcpy and memset cannot be overridden when -flto is used Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: eblot.ml at gmail dot com On arm-none-eabi target, when -flto mode is enabled, the linker does not allow to override the builtin definitions for memset and memcpy: /var/folders/g0/7v4by70d4nd052zj7wj7v3m8gn/T//cc3YmscA.ltrans8.ltrans.o: In function `memset': main/src/fastmem.c:94: multiple definition of `memset' /usr/local/Cellar/arm-eabi-gcc49/4.9.0/lib/gcc/arm-eabi/4.9.0/../../../../arm-eabi/lib/libg.a(lib_a-memset.o):memset.c:(.text+0x0): first defined here /var/folders/g0/7v4by70d4nd052zj7wj7v3m8gn/T//cc3YmscA.ltrans8.ltrans.o: In function `memcpy': main/src/fastmem.c:15: multiple definition of `memcpy' /usr/local/Cellar/arm-eabi-gcc49/4.9.0/lib/gcc/arm-eabi/4.9.0/../../../../arm-eabi/lib/libg.a(lib_a-memcpy-stub.o):memcpy-stub.c:(.text+0x0): first defined here This issue has already been reported here: http://permalink.gmane.org/gmane.comp.gcc.help/46588
[Bug lto/61001] Builtin memcpy and memset cannot be overridden when -flto is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61001 --- Comment #1 from Emmanuel Blot eblot.ml at gmail dot com --- Note: binutils version: 2.24
[Bug tree-optimization/60971] [4.9/4.10 Regression] Wrong code when coercing unsigned char to bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60971 --- Comment #6 from Jeffrey A. Law law at redhat dot com --- Jakub, That patch is fine -- it's effectively what I was planning to do today, just in a different location.
[Bug c/46460] warn for shifting more than the bits in the (promoted) type is undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46460 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- We have -fsanitize=shift for this now.
[Bug c/45123] -pedantic warning about string inside __asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45123 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Seems to be fixed since 4.7.
[Bug lto/61001] Builtin memcpy and memset cannot be overridden when -flto is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61001 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- Please copy your testcase here. -fno-builtin-memcmp is not a hack, it is necessary, even without -flto. Without it, linking is not the only thing that may fail. gcc may look at your implementation, recognize that it is doing the same thing as memcmp, and replace it with a call to memcmp...
[Bug tree-optimization/60997] -fopenmp conflicts with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60997 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- IIRC -fopenmp has similar issues for vectorization (it defeats points-to analysis) PR46032? [Book15] f90/bug% g++ -Ofast pr46032.cpp -fopt-info-vec -fgraphite -fgraphite-identity -floop-block -floop-flatten -floop-interchange -floop-strip-mine -ftree-loop-linear -floop-parallelize-all pr46032.cpp:11:34: note: loop vectorized [Book15] f90/bug% g++ -Ofast pr46032.cpp -fopt-info-vec -fopenmp -fgraphite -floop-block -floop-flatten -floop-interchange -floop-strip-mine -ftree-loop-linear pr46032.cpp:11:34: note: loop vectorized pr46032.cpp:11:34: note: loop versioned for vectorization because of possible aliasing pr46032.cpp:11:34: note: loop peeled for vectorization to enhance alignment but [Book15] f90/bug% g++ -Ofast pr46032.cpp -fopt-info-vec -fopenmp -fgraphite-identity [Book15] f90/bug% g++ -Ofast pr46032.cpp -fopt-info-vec -fopenmp -fgraphite -floop-block -floop-flatten -floop-interchange -floop-strip-mine -ftree-loop-linear -floop-parallelize-all [Book15]
[Bug tree-optimization/46032] openmp inhibits loop vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46032 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- See also pr60997.
[Bug lto/61001] Builtin memcpy and memset cannot be overridden when -flto is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61001 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-29 Ever confirmed|0 |1
[Bug fortran/59577] OpenMP: ICE with type(c_ptr) in private()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59577 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- +++ This bug was initially created as a clone of Bug #51024 +++ What is the added value of this PR with respect to pr51024? IMO it should be closed as a duplicate.
[Bug c++/60999] [4.9/4.10 Regression] ICE when static_cast from constexpr in specialization of template-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60999 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-29 Known to work||4.8.2 Target Milestone|--- |4.9.1 Summary|[4.9 Regression] ICE when |[4.9/4.10 Regression] ICE |static_cast from constexpr |when static_cast from |in specialization of|constexpr in specialization |template-class |of template-class Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug c/60998] [MIPS] -O3 produces infinite while() loop. -O2 produces correct code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60998 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You need to build with -fno-tree-loop-distribute-patterns. We detect the loop is doing a memset and replace it with a memset call otherwise. *** This bug has been marked as a duplicate of bug 56888 ***
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||exmortis at yandex dot ru --- Comment #25 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 60998 has been marked as a duplicate of this bug. ***
[Bug fortran/61002] New: Can't divide by 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61002 Bug ID: 61002 Summary: Can't divide by 0 Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com If I have a statement like real(kind(1.0d0)), parameter :: big=1.0d0/0.0d0 the compile fails with an error even when using the option -ffpe-trap= The man page for gcc makes this excellent point -Wno-div-by-zero Do not warn about compile-time integer division by zero. Floating- point division by zero is not warned about, as it can be a legitimate way of obtaining infinities and NaNs. And in fact, all I'm trying to do is obtain infinity.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #26 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Janosch Rux from comment #24) When upgrading our build environment we ran into this. We worked around the way mentioned in the comments. No Problems with: 4.6.3 Broken with: 4.8.2 -ftree-loop-distribute-patterns is on by default at -O3 since GCC 4.6, a change from GCC 4.5 and before which needed explicit enabling of this. More recent GCC may have become more clever in recognizing them though (for example non-zero memset support is quite recent).
[Bug fortran/61002] Can't divide by 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61002 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compile with -fno-range-check. Also f951: warning: command line option '-Wno-div-by-zero' is valid for C/C++/ObjC/ObjC++ but not for Fortran
[Bug bootstrap/60984] [4.9 Regression] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 --- Comment #7 from Torbjörn Gard tgard at opentext dot com --- I used gcc-4.8.2
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #27 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, so looking at this again.
We don't have a cgraph node for builtin_decl_(implicit|explicit)
(BUILT_IN_MEMSET).
But it seems that decl has DECL_ASSEMBLER_NAME_SET_P (not sure if set
correctly though).
So we can use symtab_node_for_asm (DECL_ASSEMBLER_NAME ()) and
eventually get to symtab_alias_target of that and check if it
is equal to the current function.
Index: gcc/tree-loop-distribution.c
===
--- gcc/tree-loop-distribution.c(revision 209892)
+++ gcc/tree-loop-distribution.c(working copy)
@@ -71,6 +71,7 @@ along with GCC; see the file COPYING3.
#include tree-pass.h
#include gimple-pretty-print.h
#include tree-vectorizer.h
+#include cgraph.h
/* A Reduced Dependence Graph (RDG) vertex representing a statement. */
@@ -1084,6 +1085,15 @@ classify_partition (loop_p loop, struct
|| !dominated_by_p (CDI_DOMINATORS,
loop-latch, gimple_bb (stmt)))
return;
+ tree fn = builtin_decl_implicit (BUILT_IN_MEMSET);
+ if (DECL_ASSEMBLER_NAME_SET_P (fn))
+ {
+ symtab_node *n1 = symtab_node_for_asm (DECL_ASSEMBLER_NAME (fn));
+ symtab_node *n2 = symtab_get_node (cfun-decl);
+ if (n1 == n2
+ || (n1-alias symtab_alias_target (n1) == n2))
+ return;
+ }
partition-kind = PKIND_MEMSET;
partition-main_dr = single_store;
partition-niter = nb_iter;
fixes the following testcase:
typedef __SIZE_TYPE__ size_t;
extern void *
memset (void *s, int c, size_t n) __attribute__ ((weak, alias(_memset)));
void *
_memset(void *s, int c, size_t n)
{
char *q = (char *)s;
while (n != 0)
{
*(q++) = c;
n--;
}
}
it won't fix glibc as that uses
asm(.alias );
for the aliases which we don't parse.
It of course also fixes the very direct recursion. At least if
the assembler name of the builtin agrees with that of the function.
Honza, is there a more fancy way of doing this?
[Bug libgcc/61003] New: [4.9 Regression] Segfault in __deregister_frame_info_bases when exiting, on i686-mingw32 with dw2 unwinding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61003 Bug ID: 61003 Summary: [4.9 Regression] Segfault in __deregister_frame_info_bases when exiting, on i686-mingw32 with dw2 unwinding Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: fanael4 at gmail dot com Target: i686-*-mingw32 When targeting i686-mingw32 all programs compiled with GCC with DWARF2 unwinding, including GCC itself, segfault when exiting. The segfaults are null pointer references in __deregister_frame_info_bases, called from atexit handler runner. Tested on 4.9.1 r. 209891. Didn't test the trunk. Backtrace (from Wine, on real Windows it's very similar): #0 0x010b7810 in __deregister_frame_info_bases (begin=0x7ed5bb6f MSVCRT__cexit+127) at ../../../../src/gcc/libgcc/unwind-dw2-fde.c:216 #1 0x05c2fd38 in ?? () #2 0x7ed5bb6f in MSVCRT__cexit () from /usr/bin/../lib32/wine/msvcrt.dll.so #3 0x7ed5be3e in MSVCRT_exit () from /usr/bin/../lib32/wine/msvcrt.dll.so #4 0x004014c3 in __tmainCRTStartup () #5 0x7b86041c in call_process_entry () from /usr/bin/../lib32/wine/kernel32.dll.so #6 0x7b861563 in ExitProcess () from /usr/bin/../lib32/wine/kernel32.dll.so #7 0x7bc80490 in call_thread_func_wrapper () from /usr/bin/../lib32/wine/ntdll.dll.so #8 0x7bc834cf in call_thread_func () from /usr/bin/../lib32/wine/ntdll.dll.so #9 0x7bc8046e in RtlRaiseException () from /usr/bin/../lib32/wine/ntdll.dll.so #10 0x7bc53931 in call_dll_entry_point () from /usr/bin/../lib32/wine/ntdll.dll.so #11 0xf7559b6d in wine_call_on_stack () from /usr/bin/../lib32/libwine.so.1 #12 0xf7559c4e in wine_switch_to_stack () from /usr/bin/../lib32/libwine.so.1
[Bug libgcc/61003] [4.9 Regression] Segfault in __deregister_frame_info_bases when exiting, on i686-mingw32 with dw2 unwinding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61003 --- Comment #1 from Fanael fanael4 at gmail dot com --- Note: I was compiling with -O2, so the line number may not be very indicative. Should I post a backtrace of -O0?
[Bug tree-optimization/60971] [4.9/4.10 Regression] Wrong code when coercing unsigned char to bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60971 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Apr 29 14:44:07 2014 New Revision: 209900 URL: http://gcc.gnu.org/viewcvs?rev=209900root=gccview=rev Log: PR tree-optimization/60971 * tree-tailcall.c (process_assignment): Reject conversions which reduce precision. * c-c++-common/turtore/pr60971.c: New test. Added: trunk/gcc/testsuite/c-c++-common/torture/pr60971.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-tailcall.c
[Bug tree-optimization/60971] [4.9/4.10 Regression] Wrong code when coercing unsigned char to bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60971 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Apr 29 14:45:24 2014 New Revision: 209901 URL: http://gcc.gnu.org/viewcvs?rev=209901root=gccview=rev Log: PR tree-optimization/60971 * tree-tailcall.c (process_assignment): Reject conversions which reduce precision. * c-c++-common/turtore/pr60971.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/torture/pr60971.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-tailcall.c
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #28 from Rich Felker bugdal at aerifal dot cx --- On Tue, Apr 29, 2014 at 02:16:38PM +, rguenth at gcc dot gnu.org wrote: Honza, is there a more fancy way of doing this? The only correct way to fix this is to honor -ffreestanding and never generate references to hosted-C functions (which include memset) when -ffreestanding is used.
[Bug fortran/61002] Can't divide by 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61002 --- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- Thanks, that did the job.
[Bug c++/61004] New: [4.9/4.10 Regression] Spurious warning: dereferencing type-punned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004
Bug ID: 61004
Summary: [4.9/4.10 Regression] Spurious warning: dereferencing
type-punned pointer
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
struct A{};
struct B:A{};
void f(A const);
int main(){
B b;
f(b);
}
g++ -O2 -Wall x.cc -c
x.cc: In function 'int main()':
x.cc:6:6: warning: dereferencing type-punned pointer will break strict-aliasing
rules [-Wstrict-aliasing]
f(b);
^
I think that's perfectly valid C++...
(I don't have a 4.9 handy, I think I've been seeing this since before the
branch, but please check before confirming the bug)
[Bug c++/61004] [4.10 Regression] Spurious warning: dereferencing type-punned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-29 Known to work||4.8.2, 4.9.0 Summary|[4.9/4.10 Regression] |[4.10 Regression] Spurious |Spurious warning: |warning: dereferencing |dereferencing type-punned |type-punned pointer |pointer | Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- 4.9.0 and 4.9.1 are OK
[Bug tree-optimization/60997] -fopenmp conflicts with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60997 --- Comment #3 from Mircea Namolaru mircea.namolaru at inria dot fr --- It is not that -floop-interchange is disabled, but the code received by graphite is different if the option -fopenmp is enabled. In this case the check for data dependencies required by loop-interchange fails. I wil check more in depth if the data dependencies are right in this case or there is a problem with them (but probably not). I guess that the problem is the same for vectorization (but there the data dependencies for vectorization are not checked by graphite).
[Bug c++/51707] [c++11] constexpr constructor cannot initialize const reference member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51707 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.9.0. I'm adding the testcase and closing the bug.
[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #5 from Vittorio Zecca zeccav at gmail dot com --- Running the test case with gfortran 4.9.0 I get a shift larger than HOST_BITS_PER_WIDE_INT (64 on x86-64) in double-int.c:675 m = ((unsigned HOST_WIDE_INT) 2 (prec - 1)) - 1; because prec is 295. Maybe this is connected to the original bug?
[Bug tree-optimization/61000] No loop interchange for inner loop along the slow index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000 --- Comment #1 from Mircea Namolaru mircea.namolaru at inria dot fr --- The built-in heuristics assess that loop interchange is not profitable. Indeed there is a problem, I would expected that the second loop to be found profitable. Need to look more in depth at this.
[Bug debug/41736] missing DW_TAG_template_*_ in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41736 --- Comment #10 from Tom Tromey tromey at gcc dot gnu.org --- Today I noticed another case. If you have a template like: templatetypename R, const char *NAME, typename A [...] ... then NAME is not given a value in the instantiation: 265c5: Abbrev Number: 51 (DW_TAG_template_type_param) 65c6 DW_AT_name: R 65c8 DW_AT_type: 0x3042 265cc: Abbrev Number: 122 (DW_TAG_template_value_param) 65cd DW_AT_name: (indirect string, offset: 0x6768): NAME 65d1 DW_AT_type: 0x66ac 265d5: Abbrev Number: 51 (DW_TAG_template_type_param) 65d6 DW_AT_name: A1 65d9 DW_AT_type: 0x30aa
[Bug debug/49312] Make DW_AT_name contain only simple name, no template-id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49312 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #3 from Tom Tromey tromey at gcc dot gnu.org --- FWIW I am not totally sold on this idea. It's attractive in an abstract way but I am not sure what impact it will have on gdb in practice.
[Bug c++/51707] [c++11] constexpr constructor cannot initialize const reference member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51707 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Apr 29 16:53:27 2014 New Revision: 209905 URL: http://gcc.gnu.org/viewcvs?rev=209905root=gccview=rev Log: 2014-04-29 Paolo Carlini paolo.carl...@oracle.com PR c++/51707 * g++.dg/cpp0x/constexpr-51707.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-51707.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/51707] [c++11] constexpr constructor cannot initialize const reference member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51707 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/55004] [meta-bug] constexpr issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 51707, which changed state. Bug 51707 Summary: [c++11] constexpr constructor cannot initialize const reference member http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51707 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/60984] [4.9 Regression] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 --- Comment #8 from David Edelsohn dje at gcc dot gnu.org --- I reproduced the failure starting with both GCC 4.6.3 and GCC 4.8.1. However, I am seeing some very strange results: r209278 built in /tmp/20140412 SUCCESS r209300 (trunk before branch) built in /tmp/209300 SUCCESS r209304 (branch before DEV-PHASE commit) built in /tmp/209304 SUCCESS r209304 built in /tmp/G49 FAIL I am testing again with /tmp/Z49 This is starting to look like either the build directory name or build path length affects this failure.
[Bug c++/60683] confused by earlier errors, bailing out on incorrect std::initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60683 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- c++/59318
[Bug c++/58582] [c++11] ICE defining and instantiating deleted template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58582 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-29 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug java/61005] New: libgcj.spec openned when not needed (-S on command line)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61005 Bug ID: 61005 Summary: libgcj.spec openned when not needed (-S on command line) Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: 00pebuis at bsu dot edu I get a libgcj.spec no such file or directory error message when cross-compiling on an x86 linux host with an ARM target. I'm using the -S option to emit assembly code and *not* converting to .o or linking. The libgcj.spec file describes how to link, so is unnedeed. It would seem to me that if -S is specified on the command it is just asking for trouble to attempt to open this .spec file. Of course, the *real* problem is in my Linux distro which didn't provide the needed .spec file for cross-compiling.
[Bug bootstrap/60984] [4.9 Regression] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 --- Comment #9 from David Edelsohn dje at gcc dot gnu.org --- Torbjorn: could you try building in a different directory, e.g., /builds/MMDD for the date or some random number?
[Bug java/61005] libgcj.spec openned when not needed (-S on command line)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61005
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
No this .spec file is required as it sets options that are passed to jc1
depending on the target:
*jc1: -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc
-fnon-call-exceptions%{findirect-dispatch:-fPIC} -fkeep-inline-functions
[Bug java/61005] libgcj.spec openned when not needed (-S on command line)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61005 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- Not a bug after all.
[Bug c++/60999] [4.9/4.10 Regression] ICE when static_cast from constexpr in specialization of template-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60999 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||paolo at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r204818.
[Bug pch/60982] Very long compilation of precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60982 --- Comment #5 from Yuriy Chernyshov georgthegreat at gmail dot com --- I've reconfigured gcc, so it wouldn't build precompiled headers and created a gcc-build subfolder (as FAQ said). Now the following command hangs: libtool: compile: /gpfs/data/chernyshov/contrib/gcc-4.8.2/gcc-build/./gcc/xgcc -shared-libgcc -B/gpfs/data/chernyshov/contrib/gcc-4.8.2/gcc-build/./gcc -nostdinc++ -L/gpfs/data/chernyshov/contrib/gcc-4.8.2/gcc-build/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/gpfs/data/chernyshov/contrib/gcc-4.8.2/gcc-build/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/bin/ -B/gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/lib/ -isystem /gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/include -isystem /gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/sys-include -I/gpfs/data/chernyshov/contrib/gcc-4.8.2/libstdc++-v3/../libgcc -I/gpfs/data/chernyshov/contrib/gcc-4.8.2/gcc-build/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/gpfs/data/chernyshov/contrib/gcc-4.8.2/gcc-build/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/gpfs/data/chernyshov/contrib/gcc-4.8.2/libstdc++-v3/libsupc++ -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=random.lo -g -O2 -D_GNU_SOURCE -c ../../../../../libstdc++-v3/src/c++11/random.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o random.o This is just a compilation command, so I consider something is wrong in my environment, but I really can't say what.
[Bug c++/61004] [4.10 Regression] Spurious warning: dereferencing type-punned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r209412.
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf anlauf at gmx dot de --- The ICE is not nice. However, in the meantime you can try something like the following as a workaround: real(8), parameter :: dinf = real (z'7ff8',8) real(8), parameter :: dnan = real (z'7ff0',8) write(*,*) dnan, dinf write(*,'(z16.16,4x,z16.16)') dnan, dinf end which works for me.
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 --- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- Thanks for the suggestion. As a result of another suggestion, I'm using -fno-range-check and defining infinity as 1.0d0/0.0d0.
[Bug bootstrap/61006] libcpp/lex.c: must use 'enum' tag to refer to type raw_str_phase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61006 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is supposed to be compiled with the C++ compiler and not the C compiler now. If clang++ is not being used, that is the issue.
[Bug bootstrap/61006] New: libcpp/lex.c: must use 'enum' tag to refer to type raw_str_phase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61006 Bug ID: 61006 Summary: libcpp/lex.c: must use 'enum' tag to refer to type raw_str_phase Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: spamcop at tgos dot net gcc-4.9.0/libcpp/lex.c:1394 The original line is: raw_str_phase phase = RAW_STR_PREFIX; This is incorrect. It must be: enum raw_str_phase phase = RAW_STR_PREFIX; Because raw_str_phase is an enum type, it isn't typedef'ed and lex.c is a C file (not a C++ file). As a result, when building with clang, it correctly complains: must use 'enum' tag to refer to type 'raw_str_phase'
[Bug c++/61007] New: New strict-aliasing warnings in 4.10.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61007 Bug ID: 61007 Summary: New strict-aliasing warnings in 4.10.0 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: larsbj at gullik dot net Created attachment 32707 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32707action=edit gzipped preprossed code showing the problem In current trunk I get some new strict-aliasing warnings that I did not get with 4.9.0. Shown when compiling attached preprocessed code with: (the operations.ii is from boost release 1.55, boost.filesystem) g++ -O2 -Wall -Wno-unused -std=gnu++11 -c operations.ii ... functional/boost/libs/filesystem/src/operations.cpp:343:40: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] return fs::directory_iterator(p)== end_dir_itr; ^ ... $ g++ --version g++ (GCC) 4.10.0 20140424 (experimental)
[Bug bootstrap/61006] libcpp/lex.c: must use 'enum' tag to refer to type raw_str_phase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61006 --- Comment #2 from spamcop at tgos dot net --- Okay, but looking at the rest of the code, this seems to be the only enum/struct/union that is not correctly typed according to C rules. E.g. all the other variables of enum type have `enum` in the variable declaration and if I just fix this one line, the file compiles as standard C without any problem. So if nothing else than this line is a at least a serve break of style compared to the rest of the file and as far as I can tell the only reason why this file is not standard C and would need a C++ compiler.
[Bug bootstrap/61006] libcpp/lex.c: must use 'enum' tag to refer to type raw_str_phase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61006 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to spamcop from comment #2) Okay, but looking at the rest of the code, this seems to be the only enum/struct/union that is not correctly typed according to C rules. E.g. all the other variables of enum type have `enum` in the variable declaration and if I just fix this one line, the file compiles as standard C without any problem. So if nothing else than this line is a at least a serve break of style compared to the rest of the file and as far as I can tell the only reason why this file is not standard C and would need a C++ compiler. The code was originally written as C code and then moved over to C++ in 4.8; except it was not converted, just compiled as C++ code. Now C++ism are being placed in the code which is why you see the difference here.
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-29 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- The ICE is not nice. Seems related to pr59910.
[Bug c++/61007] New strict-aliasing warnings in 4.10.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61007 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Yes, it happens all over the place in large C++ programs, I am surprised it doesn't show up in the testsuite at all. *** This bug has been marked as a duplicate of bug 61004 ***
[Bug c++/61004] [4.10 Regression] Spurious warning: dereferencing type-punned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||larsbj at gullik dot net --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- *** Bug 61007 has been marked as a duplicate of this bug. ***
[Bug c++/60951] [4.9/4.10 Regression][C++11] ICE with braced-init-list assignment and constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60951 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++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980 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/43245] add option to control discarding qualifiers warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43245 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Potential fix: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg02016.html
[Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29467 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Potential fix: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg02015.html
[Bug c/43395] Gcc warns label as local variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43395 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Potential fix: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg02014.html
[Bug c/56989] wrong location in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56989 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I've sent a patch, but it hasn't shown up on ML yet.
[Bug c++/61008] New: g++ crash in analyze_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61008
Bug ID: 61008
Summary: g++ crash in analyze_functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fab...@ritter-vogt.de
Created attachment 32708
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32708action=edit
-save-temps
After I added the implementation of the BillboardRender constructor,
g++ crashes while compiling.
Command line:
/opt/nspire/Ndless/ndless-sdk/toolchain/install/bin/arm-none-eabi-g++
-mcpu=arm926ej-s -I /home/fabian/.ndless/include -I
/opt/nspire/Ndless/ndless-sdk/bin/../include -fPIC -fno-use-cxa-atexit
-fno-exceptions -fno-rtti -mlong-calls -D _TINSPIRE -std=c++11 -O3 -g -Wall -W
-marm -ffast-math -mcpu=arm926ej-s -fno-math-errno -fno-tree-vectorize
-fomit-frame-pointer -flto -c billboardrenderer.cpp -o billboardrenderer.o
arm-none-eabi-g++ -v:
Using built-in specs.
COLLECT_GCC=arm-none-eabi-g++
COLLECT_LTO_WRAPPER=/opt/nspire/Ndless/ndless-sdk/toolchain/install/lib/gcc/arm-none-eabi/4.9.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.9.0/configure --target=arm-none-eabi
--prefix=/opt/nspire/Ndless/ndless-sdk/toolchain/install --enable-interwork
--enable-multilib --enable-languages=c,c++ --with-system-zlib --with-newlib
--with-headers=../newlib-2.0.0/newlib/libc/include --disable-shared
--with-gnu-as --with-gnu-ld --with-float=soft --disable-werror
Thread model: single
gcc version 4.9.0 (GCC)
Constructor:
BillboardRenderer::BillboardRenderer(std::mapuint8_t, std::tupleunsigned int,
unsigned int, const char* map) : map(map)
{
}
I attached the files it generates with -save-temps.
[Bug tree-optimization/61009] New: Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
Bug ID: 61009
Summary: Incorrect jump threading in dom
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tejohnson at google dot com
Created attachment 32709
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32709action=edit
t.C
We ran into a runtime failure that was tracked down to the jump threading
performed during the dom1 pass. I reproduced it with trunk (updated to
r209902).
I've attached a reduced test case. Build with:
g++ -fno-tree-vrp -O2 -std=c++11 -fno-strict-aliasing t.C -S
Unfortunately it isn't runnable, but the problem is apparent in the resulting
dumps/assembly.
The code initially looks like:
for (int j = 0; j NKF ; ++j) {
int field_idx = idxs[j];
int cmp = doCmp(row_offset, field_idx);
fprintf (stderr, cmp=%d\n,cmp);
if (cmp == 0) {
continue;
}
if (cmp 0) {
is_different = true;
break;
} else {
fprintf (stderr, Incorrect\n);
return false;
}
}
But after dom1 jump threading it looks something like:
for (int j = 0; j NKF ; ++j) {
int field_idx = idxs[j];
int cmp = doCmp(row_offset, field_idx);
fprintf (stderr, cmp=%d\n,cmp);
if (cmp == 0) {
goto L1
}
if (cmp 0) {
is_different = true;
break;
} else {
ERROR:
fprintf (stderr, Incorrect\n);
return false;
}
L1:
++j;
if (j = NKF)
break;
field_idx = idxs[j];
cmp = doCmp(row_offset, field_idx);
fprintf (stderr, cmp=%d\n,cmp);
if (cmp == 0) {
goto L1
}
goto ERROR
}
Notice that after threading, the duplicated code wrongly simplifies away the
check of cmp 0.
I've also attached the dom1 dump. The problematic jump thread is this one:
Registering jump thread: (14, 12) incoming edge; (12, 4) joiner; (4, 5)
nocopy;
Since some of these blocks (12 and 14) were created by the earlier dom
optimizations, I modified tree-ssa-threadupdate.c to dump the cfg when entering
thread_through_all_blocks. The attached dump includes that extra dump.
[Bug c++/61008] g++ crash in analyze_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61008 --- Comment #1 from Fabian Vogt fab...@ritter-vogt.de --- Created attachment 32711 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32711action=edit -save-temps (assembler)
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #1 from Teresa Johnson tejohnson at google dot com --- Created attachment 32710 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32710action=edit t.C.078t.dom1
[Bug c++/61008] g++ crash in analyze_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61008 Fabian Vogt fab...@ritter-vogt.de changed: What|Removed |Added Attachment #32711|0 |1 is obsolete|| --- Comment #2 from Fabian Vogt fab...@ritter-vogt.de --- Created attachment 32712 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32712action=edit Preprocessed source
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Most likely related to bug 60902.
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/14380607
[Bug c++/61008] g++ crash in analyze_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61008 --- Comment #3 from Fabian Vogt fab...@ritter-vogt.de --- Forgot to paste the output: billboardrenderer.cpp:13:51: warning: unused parameter 'block' [-Wunused-parameter] AABB BillboardRenderer::getAABB(const BLOCK_WDATA block, GLFix x, GLFix y, GLFix z) ^ billboardrenderer.cpp:13:64: warning: unused parameter 'x' [-Wunused-parameter] AABB BillboardRenderer::getAABB(const BLOCK_WDATA block, GLFix x, GLFix y, GLFix z) ^ billboardrenderer.cpp:13:73: warning: unused parameter 'y' [-Wunused-parameter] AABB BillboardRenderer::getAABB(const BLOCK_WDATA block, GLFix x, GLFix y, GLFix z) ^ billboardrenderer.cpp:13:82: warning: unused parameter 'z' [-Wunused-parameter] AABB BillboardRenderer::getAABB(const BLOCK_WDATA block, GLFix x, GLFix y, GLFix z) ^ cc1plus: internal compiler error: Segmentation fault 0x91c79f crash_signal ../../gcc-4.9.0/gcc/toplev.c:337 0x6b5252 analyze_functions ../../gcc-4.9.0/gcc/cgraphunit.c:1043 0x6b6204 finalize_compilation_unit() ../../gcc-4.9.0/gcc/cgraphunit.c:2326 0x56bd78 cp_write_global_declarations() ../../gcc-4.9.0/gcc/cp/decl2.c:4611 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make: *** [billboardrenderer.o] Error 1
[Bug c/60809] C99 struct initialiser with embedded self assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com --- I see nothing that says anything about the sequencing of side effects in initialization expressions with respect to the actual initialization itself, or parts thereof - either to require a particular sequencing, or to make it indeterminately sequenced or unsequenced. That may mean it's implicitly unsequenced, but I'd suggest raising this with WG14.
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Andrew Pinski from comment #2) Most likely related to bug 60902. Teresa, could you verify whether r209860 (for PR60902) fixes this one as well?
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #5 from Jeffrey A. Law law at redhat dot com --- I really doubt this is related to 60902.
[Bug testsuite/59778] FAIL: gcc.dg/atomic/c11-atomic-exec-5.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59778 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Mon, 14 Apr 2014, danglin at gcc dot gnu.org wrote: I tend to think the failure of this test on hppa is mainly a testsuite issue. Specifically, the test performs operations that may raise exceptions and the result of these operations are tested: The test expects IEEE semantics for arithmetic results and exceptions (in round-to-nearest). The PA-RISC 2.0 Architecture states that the destination is undefined except in the case when it is one of the source registers for invalid and divide by zero. It also appears based on my testing that the results are not as expected by the test for overflow, underflow and inexact operations. An undefined result hardly makes sense for inexact, at least, even if the processor isn't claiming IEEE floating point First, the TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook needs implementing; this test is always expected to fail for platforms not defining that hook. Without that hook, results not as expected can simply arise from the operation not being properly atomic regarding floating-point exceptions. Then, if you still see failures with that hook defined, if there is an option such as -mieee to enable IEEE semantics (e.g. through enabling traps to the kernel with kernel emulation for the problem cases), then it would be appropriate to use it with dg-additional-options; otherwise, the fenv_exceptions effective-target may need adjusting to exclude the problem targets. But the first step is defining the hook.
[Bug other/60843] Documentation: 4.5 Integers/C99 6.3.1.3 (reduce modulo 2^N)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60843 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 15 Apr 2014, kdevel at vogtner dot de wrote: For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised. Reduce A modulo M usually means find the least integer R in the range [0, M - 1] such that A is congruent R modulo M. But this is not what gcc compiled I don't see the problem. It explicitly says reduced modulo 2^N to be within range of the type, and that unambiguously defines the result value, as there is exactly one result within the range of the type that is equal to the input, modulo 2^N. The qualifier to be within range of the type says that [0, M - 1] is irrelevant, because that isn't the range of the type in question. This is the normal form of modulo arithmetic for signed types, as used for example by -fwrapv (and defined in detail in the first (1994) edition of LIA-1; the second (2012) edition removes the modulo operations, but the underlying wrap_I operation is in LIA-2).
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #6 from Teresa Johnson tejohnson at google dot com --- On Tue, Apr 29, 2014 at 2:46 PM, ppluzhnikov at google dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Andrew Pinski from comment #2) Most likely related to bug 60902. Teresa, could you verify whether r209860 (for PR60902) fixes this one as well? I thought it might be a dup of that too, but I updated today to r209902 and the problem remains. Thanks, Teresa -- You are receiving this mail because: You reported the bug.
[Bug c++/60999] [4.9/4.10 Regression] ICE when static_cast from constexpr in specialization of template-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60999 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|D.Bahadir at GMX dot de| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- I'm finishing testing this, appears to work fine so far: Index: pt.c === --- pt.c(revision 209916) +++ pt.c(working copy) @@ -463,6 +463,7 @@ maybe_begin_member_template_processing (tree decl) if (nsdmi) decl = (CLASSTYPE_TEMPLATE_INFO (DECL_CONTEXT (decl)) + uses_template_parms (DECL_CONTEXT (decl)) ? CLASSTYPE_TI_TEMPLATE (DECL_CONTEXT (decl)) : NULL_TREE);
