[Bug c/70090] New: add non-constant variant of __builtin_object_size for _FORTIFY_SOURCE and -fsanitize=object-size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70090
Bug ID: 70090
Summary: add non-constant variant of __builtin_object_size for
_FORTIFY_SOURCE and -fsanitize=object-size
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: danielmicay at gmail dot com
Target Milestone: ---
The __builtin_object_size intrinsic is primarily used for _FORTIFY_SOURCE,
where it's used for both the compile-time and runtime checks. However,
_FORTIFY_SOURCE would be better served by a more flexible intrinsic able to
return a runtime value when possible.
For example, consider this code:
void *p = malloc(n);
if (!p) {
return 1;
}
memset(p, 0, m);
It would be straightforward to catch cases where m > n by replacing
__builtin_object_size with a new __builtin_runtime_object_size intrinsic taking
advantage of the alloc_size attribute for runtime values. It would still return
a constant sentinel when the value is unknown. The fortified functions would
use __builtin_constant_p and perform the runtime check if the value is not
constant, falling through to the old code with the compile-time checks and fast
paths when it's constant. This would make _FORTIFY_SOURCE significantly more
useful for dynamic allocations by covering simple cases where the memory is
used right away.
The same code could also be used to improve -fsanitize=object-size.
[Bug fortran/45076] [OOP] gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45076 --- Comment #6 from Dominique d'Humieres --- > This PR seems fixed for 4.9.3, 5.3.0, and trunk (6.0). The change occurred > between revisions r201916 (2013-08-22, broken) and r202111 (2013-08-30). > Could someone checks that the PR is actually fixed? PING! Is anybody familiar with gov testing?
[Bug c++/70091] New: Codegen emits dead load on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70091
Bug ID: 70091
Summary: Codegen emits dead load on x86-64
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deaeod at gmail dot com
Target Milestone: ---
Code (http://goo.gl/MA8I0I):
struct bitfield {
void and_assign() volatile {
_raw = _and(_raw, 1); // this reads twice from _raw
//mov eax, DWORD PTR [rsp-24]
//mov eax, DWORD PTR [rsp-24]
//and eax, 1
//mov DWORD PTR [rsp-24], eax
_raw = _raw & 1; // this reads once from _raw
//mov eax, DWORD PTR [rsp-24]
//and eax, 1
//mov DWORD PTR [rsp-24], eax
}
static unsigned _and(unsigned lhs, unsigned rhs) {
return lhs & rhs;
}
unsigned _raw;
};
void test_device() {
volatile bitfield tcc;
tcc.and_assign();
}
I tested this snippet with g++ 4.8.2 and 4.9.0 on x86-64 only, so im not sure
if this bug applies to other targets. g++ 4.8.2 does not emit two loads from
_raw in any case, 4.9 and later behave as described in the comments. Note that
optimization level does not influence the generated code.
[Bug c++/70092] New: Enhance -Wunused-but-set-parameter when the parameter is also read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70092
Bug ID: 70092
Summary: Enhance -Wunused-but-set-parameter when the parameter
is also read
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hadrien-gcc at psydk dot org
Target Milestone: ---
I found a bogus piece of code in a real program, here is a simplified version:
bool getValue(int value) {
value = 42;
value++;
return true;
}
The bug comes from the missing & in the parameter declaration, the fix is:
bool getValue(int& value) ...
I build with -Wall and -Wextra, and I was wondering why
-Wunused-but-set-parameter could not catch this error.
If I remove the "value++;" line, it triggers the warning as expected. If I put
back the line, of if I rewrite it "value = value + 1;", the warning disappears.
I think it would be helpful if -Wunused-but-set-parameter was able to catch
this pattern.
Command line:
g++ -fPIC -std=c++11 -Wall -Wextra *.cpp -o exe
g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
[Bug c/70093] New: Instancing function with VM type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093
Bug ID: 70093
Summary: Instancing function with VM type cases internal
compiler error in 'assign_stack_temp_for_type'.
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sasho648 at gmail dot com
Target Milestone: ---
Consider this example:
int main(int argc, char **argv)
{
struct {int _[argc];} fn() { }
fn(); //comment to trigger error on the next line
__typeof__(fn()) *p;
}
At the time local function 'fn' is instanced (either explicitly or using
'__typeof__') the following error is displayed:
internal compiler error: in assign_stack_temp_for_type, at function.c:793
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 --- Comment #1 from sasho648 at gmail dot com --- As a comment - I'll add that this feature looks fascinating and my personal opinion is that code like this should be allowed. I even suggest a way of allowing the return VM type access to the function parameters or locals. This way we could write self-contained functions which can directly return VLA (with size varying on each instance) without the need of the caller to maintain storage life-time (compared to 'malloc').
[Bug c/70089] ARM/THUMB unnecessarily typecasts some rvalues on memory store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70089 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Earnshaw --- dup *** This bug has been marked as a duplicate of bug 70088 ***
[Bug c/70088] New: ARM/THUMB unnecessarily typecasts some rvalues on memory store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70088 Bug ID: 70088 Summary: ARM/THUMB unnecessarily typecasts some rvalues on memory store Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aik at aol dot com.au Target Milestone: --- When a multiplication is part of an rvalue for memory storage, gcc is casting/wrapping variables smaller than the native width (32bit) to the destination pointer's dereference type and expanding back to 32bit (via LSL+LSR, LSL+ASR, or AND), even if the [r]value is not used for anything more than being stored to memory. Since memory stores smaller than the native register width ignore the higher bits, this behaviour is unnecessary and results in bloat inside of hotspots. Additionally, there is a strange behaviour where if one logical-ORs a variable with a constant which is negative (if the type were signed) and smaller than the native register width, gcc will emit code to sign extend (even in unsigned cases), making the code inefficient. For example: // typeof(m) = unsigned short * // typeof(x) = unsigned short *m++ = x|0x4000U; *m++ = x|0x8000U; This is trivially translated to ARM assembly as: ; r0: &m ; r1: x ORR r2, r1, #0x4000 ; t1 = x|0x4000U ORR r1, r1, #0x8000 ; t2 = x|0x8000U STRH r2, [r0], #2; *m++ = t1 STRH r1, [r0], #2; *m++ = t2 However, gcc is generating the following instead: ; r0: &m ; r1: x MVN r3, r1, lsl #17 ; t2 = x|0x8000 MVN r3, r3, lsr #17 ORR r1, r1, #0x4000 ; t1 = x|0x4000U STRH r1, [r0, #0]; m[0] = t1 STRH r3, [r0, #2]; m[1] = t2 In that instance, it's not too awful (just one extra instruction). However, when these sign-extended values become impossible to generate in two instructions, gcc will resort to using a literal pool to fetch the OR constant. The C code: *m++ = x|0x4100U; *m++ = x|0x8100U; The trivial interpretation: ORR r2, r1, #0x4100 ; t1 = x|0x4100U ORR r1, r1, #0x8100 ; t2 = x|0x8100U STRH r2, [r0], #2; *m++ = t1 STRH r1, [r0], #2; *m++ = t2 The generated assembly (instruction sorted for readability): ORR ip, r1, #0x4100 ; t1 = x|0x4100U LDR r3, =0x8100 ; t2 = x|0x8100 ORR r3, r1, r3 STRH ip, [r0, #4]; m[2] = t1 STRH r3, [r0, #6]; m[3] = t2 Not only is this slower (due to the extra instruction and the memory access), but it also takes up more memory (and the more constants you have that require a memory load for sign-extension, the worse it gets). --- Comment #1 from Richard Earnshaw --- *** Bug 70089 has been marked as a duplicate of this bug. ***
[Bug c/70089] ARM/THUMB unnecessarily typecasts some rvalues on memory store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70089 --- Comment #2 from aik at aol dot com.au --- Oh, darn. Sorry - the page had timed out on me the first time and I thought it hadn't gone through. The first attempt at the post actually lacked some information and I had included the wrong attachment (was meant for a fellow programmer), I believe. Is there any way to remove the other report I filed (or otherwise mark it so that this is the one being focused on?
[Bug c++/70094] New: Missed optimization when passing a constant struct argument by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70094
Bug ID: 70094
Summary: Missed optimization when passing a constant struct
argument by value
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: robryk at gmail dot com
Target Milestone: ---
Function baz in the code listing below gets compiled into something that writes
to the stack. This is unnecessary: one can just load the argument into rdi with
movabs and get rid of stack adjustments and memory accesses:
---snip---
[robryk@sharya-rana gccbug]$ cat > bug.cc
struct foo {
int a;
int b;
int c;
};
void bar(foo);
void baz() {
foo f;
f.a = 1;
f.b = 2;
f.c = 3;
bar(f);
}
[robryk@sharya-rana gccbug]$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5.3.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC)
[robryk@sharya-rana gccbug]$ g++ bug.cc -O2 -c -o bug.o
[robryk@sharya-rana gccbug]$ objdump -d bug.o
bug.o: file format elf64-x86-64
Disassembly of section .text:
<_Z3bazv>:
0: 48 83 ec 18 sub$0x18,%rsp
4: be 03 00 00 00 mov$0x3,%esi
9: c7 04 24 01 00 00 00movl $0x1,(%rsp)
10: c7 44 24 04 02 00 00movl $0x2,0x4(%rsp)
17: 00
18: 48 8b 3c 24 mov(%rsp),%rdi
1c: e8 00 00 00 00 callq 21 <_Z3bazv+0x21>
21: 48 83 c4 18 add$0x18,%rsp
25: c3 retq
---snip---
I've verified that Clang performs the optimization I was talking about and
that, according to gcc.godbolt.org, a snapshot of gcc 6 misses this
optimization too.
For comparison, the code Clang produces (according to godbolt):
movabsq $8589934593, %rdi # imm = 0x20001
movl$3, %esi
jmp bar(foo) # TAILCALL
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #10 from Mikael Pettersson --- This wrong-code was fixed by PR68184, which is fixed in gcc-5 and gcc-6, but not yet in gcc-4.9.
[Bug c++/68184] [4.9 Regression] Exception from a virtual function does not get caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68184 Markus Trippelsdorf changed: What|Removed |Added CC||maysam.kind at gmail dot com --- Comment #11 from Markus Trippelsdorf --- *** Bug 69874 has been marked as a duplicate of this bug. ***
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Markus Trippelsdorf --- (In reply to Mikael Pettersson from comment #10) > This wrong-code was fixed by PR68184, which is fixed in gcc-5 and gcc-6, but > not yet in gcc-4.9. Thanks. Closing as dup. *** This bug has been marked as a duplicate of bug 68184 ***
[Bug fortran/33430] Improve -finit-*: Initialization of derived types, equivalenced variables, allocated arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33430 Dominique d'Humieres changed: What|Removed |Added CC||fritzoreese at gmail dot com --- Comment #3 from Dominique d'Humieres --- Patch proposed at https://gcc.gnu.org/ml/fortran/2016-03/msg00014.html.
[Bug fortran/32317] [bounds checking] No warning on bad arguments with explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #11 from Dominique d'Humieres --- > Considering that this PR is (IMO) based on wrong expectations and did not > have any activity for more than six years, I'll close it as WONTFIX without > (prompt) feedback. No feedback, closing as WONTFIX.
[Bug fortran/27766] [meta-bug] -fbounds-check related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766 Bug 27766 depends on bug 32317, which changed state. Bug 32317 Summary: [bounds checking] No warning on bad arguments with explicit interface https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug c++/70095] New: [C++14] Link error on partially specialized variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70095
Bug ID: 70095
Summary: [C++14] Link error on partially specialized variable
template
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to link on GCC trunk:
template struct Foo;
template int variable_template = 0;
template int variable_template> = 0;
template int get_variable_template() { return
variable_template; }
int main() {
get_variable_template>();
}
> ~/code/gcc/prefix/bin/g++ -std=c++14 test/worksheet.cpp
Undefined symbols for architecture x86_64:
"_variable_template", referenced from:
int get_variable_template >() in ccPzxGMc.o
(maybe you meant: int get_variable_template >())
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
Live example: http://melpon.org/wandbox/permlink/eFOhrTWIfIeelZnu
Curiously, explicitly specializing `variable_template>` fixes the
issue.
[Bug rtl-optimization/70061] [6 Regression] ICE: SIGSEGV in delete_insn_chain() with unused label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70061 --- Comment #3 from Richard Henderson --- Created attachment 37875 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37875&action=edit proposed patch Thanks, Jeff, the errant stack adjustment was a good hint. The problem is that we are emitting copy sequences to edges without caring for deferred popping of arguments. Thus when we began emitting code for the first block, which in this case starts with a label, we had 32 bytes of pending stack adjustment, which emit_label flushed. The ICE is due to the label not being the first insn in the BB. There are two equivalent ways to fix this: we can either save/restore inhibit_defer_pop around these sequences, or we can manually flush any pending stack adjustment. This patch does the latter. Just starting full testing.
[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364
--- Comment #12 from Louis Dionne ---
The following code still fails to compile on GCC trunk:
template
struct tuple {
Xn storage_;
constexpr tuple(Xn const& xn)
: storage_(xn)
{ }
template
constexpr tuple(tuple const& other)
: storage_(other.storage_)
{ }
template
constexpr tuple(tuple& other)
: tuple(const_cast(other))
{ }
};
template
struct wrapper { T value; };
template
constexpr wrapper wrap(T t) { return {t}; }
constexpr wrapper> t = wrap(tuple{2});
static_assert(t.value.storage_ == 2, "");
The error is
prog.cc:27:5: error: non-constant condition for static assertion
static_assert(t.value.storage_ == 2, "");
^
prog.cc:27:5: error: accessing uninitialized member 'tuple::storage_'
Note that if the `static_assert` is changed to a runtime assertion, and if `t`
is not made `constexpr`, this code will trigger a runtime error. I'm pretty
sure
the above is triggered by the current bug.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 --- Comment #2 from sasho648 at gmail dot com --- The bug occurs at the most simple 'gcc test_code.c' command.
[Bug c++/70096] New: [Invalid codegen] Read of uninitialized value in ref-qualified pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70096
Bug ID: 70096
Summary: [Invalid codegen] Read of uninitialized value in
ref-qualified pointer to member function
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code has a codegen issue that causes the read of an uninitialized
value, which can lead to a segfault in some circumstances:
struct Holder {
void operator()() & { int read = data; }
int data;
};
template
void test() {
Holder h{42};
F Holder::* fptr = &Holder::operator();
(h.*fptr)();
}
int main() {
test();
}
> g++ -std=c++11 test/worksheet.cpp
> valgrind --leak-check=full --track-origins=yes ./a.out
==44102== Memcheck, a memory error detector
[...]
==44102== Use of uninitialised value of size 8
==44102==at 0x10EE6: Holder::operator()() & (in ./a.out)
==44102==by 0x10F26: void test() (in ./a.out)
==44102==by 0x10ED2: main (in ./a.out)
==44102== Uninitialised value was created by a stack allocation
==44102==at 0x10F2A: void test() (in ./a.out)
I'm not sure, but I think it has something to do with the fact that we're
using `F = void() &` (note the ref-qualifier) and the reading of the `this`
pointer. I'm not sure at all, but just pointing out a possible direction.
Live example: http://melpon.org/wandbox/permlink/kzRh8PNguwrP11lB
[Bug c++/70097] New: Cannot assign ref-qualified non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70097
Bug ID: 70097
Summary: Cannot assign ref-qualified non-static member function
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to compile on GCC trunk:
struct F { void member() & { } };
using Member = void()&;
Member F::* fptr = &F::member;
The error is:
[...]: error: cannot convert ‘void (F::*)() &’ to ‘void (F::*)()’ in
initialization
Member F::* fptr = &F::member;
^~
Live example: http://melpon.org/wandbox/permlink/kizV7mkIaHTnMTkd
[Bug target/70079] missed constant propagation in memcpy expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70079 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #1 from Bernd Schmidt --- Does the combiner have anything to say about what it tried to match?
[Bug target/70098] New: PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098
Bug ID: 70098
Summary: PowerPC64: eigen hits ICE in reload
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
I hit the following ICE when building eigen:
# g++ -O3 -c test2.cpp
test2.cpp: In function ‘void fn3(Matrix)’:
test2.cpp:59:1: error: unable to generate reloads for:
}
^
(jump_insn 17 12 18 2 (parallel [
(set (pc)
(if_then_else (ne (reg:DI 3 3)
(const_int 1 [0x1]))
(label_ref 25)
(pc)))
(set (reg:DI 156 [ _4 ])
(plus:DI (reg:DI 3 3)
(const_int -1 [0x])))
(clobber (reg:CC 172))
(clobber (reg:DI 173))
]) test2.cpp:46 775 {*ctrdi_internal1}
(expr_list:REG_UNUSED (reg:DI 173)
(expr_list:REG_UNUSED (reg:CC 172)
(expr_list:REG_DEAD (reg:DI 3 3)
(int_list:REG_BR_PROB 2900 (nil)
-> 25)
test2.cpp:59:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3552
0x10a711b3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x1093d313 curr_insn_transform
../../gcc/gcc/lra-constraints.c:3552
0x1093e4df lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:4494
0x10923513 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2286
0x108c3ffb do_reload
../../gcc/gcc/ira.c:5396
0x108c3ffb execute
../../gcc/gcc/ira.c:5580
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #1 from Anton Blanchard --- Created attachment 37876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37876&action=edit Test case
[Bug c++/70099] New: Function found by ADL, but shouldn't be visible at point of definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70099
Bug ID: 70099
Summary: Function found by ADL, but shouldn't be visible at
point of definition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
The following fragment compiles on g++ 5.3.0:
struct X { };
namespace foo {
template
void bar() { T{} < T{}; }
void operator<(const X&, const X&) {}
}
int main() {
foo::bar();
}
But foo::operator<(const X&, const X&) isn't visible at the point of the
definition of bar, and isn't in one of the associated namespaces of X, per
[temp.dep.res].
[Bug c++/70096] [6 Regression] [Invalid codegen] Read of uninitialized value in ref-qualified pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70096 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.9.3, 5.3.1 Keywords||wrong-code Last reconfirmed||2016-03-05 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 Summary|[Invalid codegen] Read of |[6 Regression] [Invalid |uninitialized value in |codegen] Read of |ref-qualified pointer to|uninitialized value in |member function |ref-qualified pointer to ||member function Known to fail||6.0 --- Comment #1 from Markus Trippelsdorf --- Only happens without optimization as seen in the bogus runtime error: markus@x4 /tmp % g++ -O0 -fsanitize=undefined hold.cpp markus@x4 /tmp % ./a.out hold.cpp:9:12: runtime error: member call on misaligned address 0x7ffe0d1d54da for type 'struct Holder', which requires 4 byte alignment 0x7ffe0d1d54da: note: pointer points here 00 00 fa ff ff ff ff ff ff ff 2a 00 00 00 ee 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ hold.cpp:2:36: runtime error: member access within misaligned address 0x7ffe0d1d54da for type 'struct Holder', which requires 4 byte alignment 0x7ffe0d1d54da: note: pointer points here 00 00 fa ff ff ff ff ff ff ff 2a 00 00 00 ee 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ markus@x4 /tmp % g++ -O1 -fsanitize=undefined hold.cpp markus@x4 /tmp % ./a.out markus@x4 /tmp %
[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058 --- Comment #6 from Jerry DeLisle --- (In reply to kargl from comment #5) > (In reply to Jerry DeLisle from comment #4) > > The problem does not exist on Linux for sure. Not sure if this is a TDM > > distribution problem, a Windows problem, a MingW problem, or gfortran. > > > > I am going to have to get set up on Windows so this may take a while. > > From the backtrace in comment #3, > > (gdb) backtrace > #0 in strcmp () from C:\WINDOWS\system32\msvcrt.dll > #1 in libgfortran_64-3!clog10l () > #2 in libgfortran_64-3!clog10l () > #3 in libgfortran_64-3!_gfortran_unpack1_char4 () > #4 in libgfortran_64-3!_gfortran_unpack1_char4 () > #5 in libgfortran_64-3!_gfortran_st_open () > > I doubt that this is a gfortran problem. It is highly unlikely that > OPEN uses a complex*16 log10 function that calls itself. No kidding Steve. This could be linking against the wrong library. Another possibility I suppose is memory corruption and the prgram is jumping into never never land. We do not really no the creators of or the integrity of the TDM distribution. Out of curiosity I am going to try to set it up in a sandbox and see what I can find.
[Bug c++/70099] Function found by ADL, but shouldn't be visible at point of definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70099 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-05 Ever confirmed|0 |1
[Bug c++/70100] New: internal compiler error: in execute, at cfgexpand.c:6066
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70100
Bug ID: 70100
Summary: internal compiler error: in execute, at
cfgexpand.c:6066
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: shadewind at gmail dot com
Target Milestone: ---
Created attachment 37877
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37877&action=edit
Preprocessed source
Internal Compiler error as follows:
FAILED: /usr/local/bin/g++-5-Wall -Werror -Wno-missing-braces -std=c++11 -g
-I../include -MMD -MT examples/database/CMakeFiles/database.dir/main.cpp.o -MF
examples/database/CMakeFiles/database.dir/main.cpp.o.d -o
examples/database/CMakeFiles/database.dir/main.cpp.o -c
../examples/database/main.cpp
In file included from ../include/rapidcheck/state/gen/ExecCommands.h:46:0,
from ../include/rapidcheck/state.h:9,
from ../examples/database/main.cpp:2:
../include/rapidcheck/state/gen/ExecCommands.hpp: In member function
'rc::Gen >
rc::state::gen::detail::ExecOneOf::operator()(const Args& ...) const
[with Args = {DatabaseModel}; Cmd = Open; Cmds = {Close, Put, BeginWrite,
ExecuteWrite, Get}; typename Cmd::CommandType =
rc::state::Command]':
../include/rapidcheck/state/gen/ExecCommands.hpp:39:14: internal compiler
error: in execute, at cfgexpand.c:6066
Gen operator()(const Args &... args) const {
^
../include/rapidcheck/state/gen/ExecCommands.hpp:39:14: internal compiler
error: Abort trap: 6
g++-5: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
Included is preprocessed output.
[Bug translation/60149] Message with percent character incorrectly marked c-format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60149 Göran Uddeborg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Göran Uddeborg --- In the current po file, 6.1-b20160131, this message is correctly marked no-c-format.
[Bug target/70079] missed constant propagation in memcpy expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70079 --- Comment #2 from Paolo Bonzini --- Yes, until combine there is the equivalent of addl$512, %ecx;; 4 andl$-8, %ecx ;; 4.5 shrl$3, %ecx ;; 5 and combine is able to merge insn 4.5 and 5 into just the shrl. However, this optimization would require combine to merge together a lot of instructions. Even with some munging of the expander, the best you could get is probably four: leaq8(%rdi), %rdi ;; rdi = b' = b + 8 leaq-8(%rdi), %rcx ;; i1: rcx = b' - 8 andq$-8, %rdi ;; i2: rdi = b' & -8 subq%rdi, %rcx ;; i3: rcx = b' - 8 - (b' & -8) = (b' & 7) - 8 shrl$3, %ecx;; i4: rcx = -1 addl$32, %ecx ;; rcx = 31 The constant isn't visible with a subset of them.
[Bug c++/70092] Enhance -Wunused-but-set-parameter when the parameter is also read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70092 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez --- Yes, we want this. *** This bug has been marked as a duplicate of bug 44677 ***
[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364
--- Comment #13 from Louis Dionne ---
Actually, the problem is much worse than I thought. It turns out that with -O1,
the following code does not pass the assertion:
#include
template
struct tuple {
Xn storage_;
constexpr tuple(Xn const& xn)
: storage_(xn)
{ }
template
constexpr tuple(tuple const& other)
: storage_(other.storage_)
{ }
template
constexpr tuple(tuple& other)
: tuple(const_cast(other))
{ }
};
template
struct wrapper { T value; };
template
constexpr wrapper wrap(T t) { return {t}; }
int main() {
wrapper> t = wrap(tuple{2});
assert(t.value.storage_ == 2);
}
Live example: http://melpon.org/wandbox/permlink/nRGrPcbvqYWhzCDt
This is the same code as above, except the `t` variable is not constexpr
anymore.
This seems like a case of invalid codegen. If I make the `wrap` function
non-constexpr,
the problem goes away. Should I create a separate bug report for this?
[Bug c/44677] Warn for variables incremented but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677 Manuel López-Ibáñez changed: What|Removed |Added CC||hadrien-gcc at psydk dot org --- Comment #3 from Manuel López-Ibáñez --- *** Bug 70092 has been marked as a duplicate of this bug. ***
[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058 --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #6) > (In reply to kargl from comment #5) > > (In reply to Jerry DeLisle from comment #4) > > > The problem does not exist on Linux for sure. Not sure if this is a TDM > > > distribution problem, a Windows problem, a MingW problem, or gfortran. > > > > > > I am going to have to get set up on Windows so this may take a while. > > > > From the backtrace in comment #3, > > > > (gdb) backtrace > > #0 in strcmp () from C:\WINDOWS\system32\msvcrt.dll > > #1 in libgfortran_64-3!clog10l () > > #2 in libgfortran_64-3!clog10l () > > #3 in libgfortran_64-3!_gfortran_unpack1_char4 () > > #4 in libgfortran_64-3!_gfortran_unpack1_char4 () > > #5 in libgfortran_64-3!_gfortran_st_open () > > > > I doubt that this is a gfortran problem. It is highly unlikely that > > OPEN uses a complex*16 log10 function that calls itself. > > No kidding Steve. This could be linking against the wrong library. Another > possibility I suppose is memory corruption and the prgram is jumping into > never never land. We do not really no the creators of or the integrity of > the TDM distribution. Out of curiosity I am going to try to set it up in a > sandbox and see what I can find. TDM is 2+ releases behind. Don't waste your time. Paul should report the problem to TDM or install a newer version of gfortran
[Bug libstdc++/70101] New: Allocator-extended priority_queue constructors are badly broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70101
Bug ID: 70101
Summary: Allocator-extended priority_queue constructors are
badly broken
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
None of them is implemented correctly, and several won't compile if actually
used.
template>
explicit
priority_queue(const _Alloc& __a)
: c(__a) { }
should be ": c(__a), comp()" (the standard says that it value-initializes
comp).
template>
priority_queue(const _Compare& __x, const _Alloc& __a)
: c(__x, __a) { }
should be ": c(__a), comp(__x)".
template>
priority_queue(const _Compare& __x, const _Sequence& __c,
const _Alloc& __a)
: c(__x, __c, __a) { }
should be ": c(__c, __a), comp(__x)", and per LWG 2537 should also call
std::make_heap.
template>
priority_queue(const _Compare& __x, _Sequence&& __c, const _Alloc& __a)
: c(__x, std::move(__c), __a) { }
should be ": c(std::move(__c), __a), comp(__x)", and per LWG 2537 should also
call std::make_heap.
template>
priority_queue(const priority_queue& __q, const _Alloc& __a)
: c(__q.c, __a) { }
should be ": c(__q.c, __a), comp(__q.comp)".
template>
priority_queue(priority_queue&& __q, const _Alloc& __a)
: c(std::move(__q.c), __a) { }
should be ": c(std::move(__q.c), __a), comp(std::move(__q.comp))".
[Bug tree-optimization/70102] New: Tree re-association prevents SLP vectorization at -Ofast.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70102 Bug ID: 70102 Summary: Tree re-association prevents SLP vectorization at -Ofast. Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vekumar at gcc dot gnu.org Target Milestone: --- The following test case failed to vectorize in gcc -Ofast. (---snip---) subroutine test (x,y,z) integer x,y,z real*8 a(5,x,y,z),b(5,x,y,z) real*8 c c = 0.0d0 do k=1,z do j=1,y do i=1,x do l=1,5 c = c + a(l,i,j,k)*b(l,i,j,k) enddo enddo enddo enddo write(30,*)'c ==',c return end (---snip---) Vectorizer dump (---snip---) test.f:9:0: note: original stmt _95 = _92 + _112; test.f:9:0: note: Build SLP for _152 = _150 * _151; test.f:9:0: note: Build SLP failed: different operation in stmt _152 = _150 * _151; test.f:9:0: note: original stmt _95 = _92 + _112; test.f:9:0: note: Build SLP for _55 = _53 * _54; test.f:9:0: note: Build SLP failed: different operation in stmt _55 = _53 * _54; test.f:9:0: note: original stmt _95 = _92 + _112; test.f:1:0: note: vectorized 0 loops in function (---snip---) Re-association pass changes one of the tree expression and it prevents from SLP block vectorization. Before (---snip---) # VUSE <.MEM_7> _90 = *A.18_37[_89]; # VUSE <.MEM_7> _91 = *A.20_40[_89]; _92 = _90 * _91; # VUSE <.MEM_7> c.21_93 = cD.3439; c.22_94 = _92 + c.21_93; _109 = _87 + 2; # VUSE <.MEM_7> _110 = *A.18_37[_109]; # VUSE <.MEM_7> _111 = *A.20_40[_109]; _112 = _110 * _111; c.22_114 = c.22_94 + _112; _129 = _87 + 3; (---snip---) After tree-reassoc (---snip---) # VUSE <.MEM_7> _90 = *A.18_37[_89]; # VUSE <.MEM_7> _91 = *A.20_40[_89]; _92 = _91 * _90; # VUSE <.MEM_7> c.21_93 = cD.3439; _109 = _87 + 2; # VUSE <.MEM_7> _110 = *A.18_37[_109]; # VUSE <.MEM_7> _111 = *A.20_40[_109]; _112 = _111 * _110; _31 = _112 + _92; <== new statement _129 = _87 + 3; (---snip---)
[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 --- Comment #14 from Jason Merrill --- Author: jason Date: Sun Mar 6 06:47:22 2016 New Revision: 234013 URL: https://gcc.gnu.org/viewcvs?rev=234013&root=gcc&view=rev Log: PR c++/67364 * constexpr.c (cxx_eval_store_expression): Replace CONSTRUCTOR_ELTS in nested CONSTRUCTORs, too. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-06 Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Confirmed. Also fails without LRA, in a similar way.
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #3 from Segher Boessenkool --- That pseudo 156 is assigned a floating point reg (33, i.e. f1) by IRA. That won't end well; this is a jump_insn so is required to work without reloads.
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
[Bug tree-optimization/70103] New: gcc reports bad dependence and bails out of vectorization for one of the bwaves loops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70103 Bug ID: 70103 Summary: gcc reports bad dependence and bails out of vectorization for one of the bwaves loops. Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vekumar at gcc dot gnu.org Target Milestone: --- flux_lam.f:68:0: note: dependence distance = 0. flux_lam.f:68:0: note: dependence distance == 0 between MEM[(real(kind=8)D.18[0:D.3627] *)ev_197(D) clique 1 base 12][_244] and MEM[(real(kind=8)D.18[0:D.3627] *)ev_197(D) clique 1 base 12][_244] flux_lam.f:68:0: note: READ_WRITE dependence in interleaving. flux_lam.f:68:0: note: bad data dependence. Looking at vector dumps, if we have CSEd the load, then there is no dependency issue here. MEM[(real(kind=8)D.18[0:D.3627] *)ev_197(D) clique 1 base 12][_244] = _272 _323 = MEM[(real(kind=8)D.18[0:D.3627] *)ev_197(D) clique 1 base 12][_244]; ---snip--- MEM[(real(kind=8)D.18[0:D.3627] *)ev_197(D) clique 1 base 12][_244] = _272; # VUSE <.MEM_273> _274 = MEM[(real(kind=8)D.18[0:D.3605] *)u.105_58][_219]; # VUSE <.MEM_273> _275 = MEM[(real(kind=8)D.18[0:D.3605] *)u.105_58][_224]; _276 = _274 - _275; _277 = ((_276)); t1_278 = _277 / dy2_68; _279 = _195 + 3; # VUSE <.MEM_273> _280 = MEM[(real(kind=8)D.18[0:D.3605] *)u.105_58][_252]; # VUSE <.MEM_273> _281 = MEM[(real(kind=8)D.18[0:D.3605] *)u.105_58][_254]; _282 = _280 - _281; _283 = ((_282)); _284 = _283 / dy2_68; _285 = t1_278 + _284; _286 = ((_285)); _287 = _286 * 5.0e-1; # VUSE <.MEM_273> _288 = MEM[(real(kind=8)D.18[0:D.3601] *)v.107_60][_206]; # VUSE <.MEM_273> _289 = MEM[(real(kind=8)D.18[0:D.3601] *)v.107_60][_203]; _290 = _288 - _289; _291 = ((_290)); _292 = _291 / _64; _293 = _287 + _292; _294 = ((_293)); _295 = t0_210 * _294; # .MEM_296 = VDEF <.MEM_273> MEM[(real(kind=8)D.18[0:D.3627] *)ev_197(D) clique 1 base 12][_279] = _295; # VUSE <.MEM_296> _297 = MEM[(real(kind=8)D.18[0:D.3605] *)u.105_58][_233]; # VUSE <.MEM_296> _298 = MEM[(real(kind=8)D.18[0:D.3605] *)u.105_58][_239]; _299 = _297 - _298; _300 = ((_299)); t2_301 = _300 / dz2_71; _302 = _195 + 4; # VUSE <.MEM_296> _303 = MEM[(real(kind=8)D.18[0:D.3605] *)u.105_58][_261]; # VUSE <.MEM_296> _304 = MEM[(real(kind=8)D.18[0:D.3605] *)u.105_58][_263]; _305 = _303 - _304; _306 = ((_305)); _307 = _306 / dz2_71; _308 = t2_301 + _307; _309 = ((_308)); _310 = _309 * 5.0e-1; # VUSE <.MEM_296> _311 = MEM[(real(kind=8)D.18[0:D.3597] *)w.109_62][_206]; # VUSE <.MEM_296> _312 = MEM[(real(kind=8)D.18[0:D.3597] *)w.109_62][_203]; _313 = _311 - _312; _314 = ((_313)); _315 = _314 / _64; _316 = _310 + _315; _317 = ((_316)); _318 = t0_210 * _317; # .MEM_319 = VDEF <.MEM_296> MEM[(real(kind=8)D.18[0:D.3627] *)ev_197(D) clique 1 base 12][_302] = _318; _320 = _195 + 5; _321 = _246 + _247; _322 = ((_321)); # VUSE <.MEM_319> _323 = MEM[(real(kind=8)D.18[0:D.3627] *)ev_197(D) clique 1 base 12][_244]; ---snip---
[Bug tree-optimization/70103] gcc reports bad dependence and bails out of vectorization for one of the bwaves loops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70103 vekumar at gcc dot gnu.org changed: What|Removed |Added CC||matz at suse dot de, ||richard.guenther at gmail dot com Severity|normal |enhancement --- Comment #1 from vekumar at gcc dot gnu.org --- After discussion with Richard it was concluded that even after we fix this still we still won't be able to vectorize the loop. (Snip) flux_lam.f:68:0: note: not vectorized: relevant stmt not supported: _177 = _176 % _21; flux_lam.f:68:0: note: bad operation or unsupported loop bound. (Snip) The reason is we have % operations. (Snip) : # i_2 = PHI <1(23), _181(28)> _175 = i_2 + _21; _176 = _175 + -2; _177 = _176 % _21; im1_178 = _177 + 1; _179 = i_2 % _21; ip1_180 = _179 + 1; (Snip) that makes indices "wrap" around which is of course something that is hard to vectorize. One would need iteration space splitting to ensure the wrapping doesn't occur in the vectorized iterations. Reporting this bug and marking this as enhancement
