[Bug rtl-optimization/66614] LRA might fail to eliminate dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66614
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
this is what I understand from lra in my own words:
lra () consists of a sequence of
for (;;) {
...
lra_eliminate (false, false);
/* Do inheritance only for regular algorithms. */
if (! lra_simple_p)
{
if (flag_ipa_ra)
{
if (live_p)
lra_clear_live_ranges ();
/* As a side-effect of lra_create_live_ranges, we calculate
actual_call_used_reg_set, which is needed during
lra_inheritance. */
lra_create_live_ranges (true, true);
live_p = true;
}
lra_inheritance ();
}
if (live_p)
lra_clear_live_ranges ();
...
}
and it is finally fixated by
lra_eliminate (true, false);
which actually replaces the base register, but keeps the offsets as they are
the RTL transformations are done by lra_eliminate_regs_1 ():
first it is called with subst_p=false, update_p=false, full_p=true,
this replaces the offset relative to from_rtx to to_rtx, but keeps the
previous base register.
then it is repeatedly called with subst_p=false, update_p=true, full_p=false,
which adds some minor corrections to the offset, and again keeps the to be
eliminated base register.
finally it is called with subst_p=true, update_p=false, full_p=false,
this time only the base register is replaced but the offsets are already
relative to the target base register.
lra_create_live_ranges calls process_bb_lives repeatedly
which uses this as a pre-condition of a dead insn which and can be eliminated:
if (dead_insn_p set != NULL_RTX
REG_P (SET_DEST (set)) REGNO (SET_DEST (set)) =
FIRST_PSEUDO_REGISTER
find_reg_note (curr_insn, REG_EH_REGION, NULL_RTX) == NULL_RTX
! may_trap_p (PATTERN (curr_insn))
/* Don't do premature remove of pic offset pseudo as we can
start to use it after some reload generation. */
(pic_offset_table_rtx == NULL_RTX
|| pic_offset_table_rtx != SET_DEST (set)))
now may_trap_p sees the offsets which are not consistent with the base.
[Bug target/63408] [4.8/4.9/5/6 regression] GCC emits incorrect fixed-fp conversion instruction on Cortex-M4 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408 --- Comment #7 from Itay Perl itay at phobotic dot com --- Any news? This bug still prevents us from compiling our code with optimizations. Thanks.
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 --- Comment #11 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #10) Because of the cost model. Combine pass says: Testing the patch: --cut here-- Index: i386.c === --- i386.c (revision 224630) +++ i386.c (working copy) @@ -42533,6 +42533,12 @@ ix86_rtx_costs (rtx x, int code_i, int outer_code_ + rtx_cost (const1_rtx, outer_code, opno, speed)); return true; } + + /* The embedded comparison operand is completely free. */ + if (!general_operand (XEXP (x, 0), GET_MODE (XEXP (x, 0))) + XEXP (x, 1) == const0_rtx) + *total = 0; + return false; case FLOAT_EXTEND: --cut here--
[Bug ipa/66616] New: fipa-cp-clone ignores thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616
Bug ID: 66616
Summary: fipa-cp-clone ignores thunk
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Created attachment 35821
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35821action=edit
test-case
I.
attached test-case g++.dg/ipa/pr60640-5.C (based on g++.dg/ipa/pr60640-3.C)
fails for x86_64, both with and without -m32:
...
FAIL: g++.dg/ipa/pr60640-5.C -std=gnu++11 execution test
PASS: g++.dg/ipa/pr60640-5.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/ipa/pr60640-5.C -std=gnu++14 execution test
PASS: g++.dg/ipa/pr60640-5.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/ipa/pr60640-5.C -std=gnu++98 execution test
...
II.
With -fno-ipa-cp-clone -g, we see that p is gb2 + 16 in main, but once we get
to B::foo, 'this' is gb2:
...
Breakpoint 1, main () at src/gcc/testsuite/g++.dg/ipa/pr60640-5.C:45
45 {
(gdb) n
49p-foo (0);
(gdb) p p
$1 = (A *) 0x600d70 gb2+16
(gdb) s
B::foo (this=0x600d60 gb2, p=0) at
/home/vries/gcc_versions/devel/devel2/src/gcc/testsuite/g++.dg/ipa/pr60640-5.C:33
33 for (int i = 0; i p; i++)
...
By using layout asm and stepi to go from main to 'B::foo', we see that we
actually pass over the 'non-virtual thunk to B::foo(int) ()' which subtracts 16
from the 'this' argument, before landing in 'B::foo':
...
0x400740 _ZThn16_N1B3fooEisub$0x10,%rdi
0x400744 _ZThn16_N1B3fooEi+4 jmp0x400710 B::foo(int)
...
III.
With -fipa-cp-clone, B::foo is cloned and inlined into main. We have at
fixup_cfg4:
...
bb 4:
o_8 = MEM[(struct B *)gb2 + 16B].D.2389.fi;
...
This is supposed to load the '2' from fi. We can see at expand in the static
initializers bit that fi is located at gb2 + 24:
...
(insn 5 2 6 2
(set
(reg/f:DI 87)
(symbol_ref:DI (gb2) [flags 0x2] var_decl 0x7fc7dfed0bd0 gb2))
(nil))
(insn 6 5 7 2
(set
(mem/c:SI
(plus:DI (reg/f:DI 87)
(const_int 24 [0x18]))
[3 MEM[(struct A *)gb2 + 16B].fi+0 S4 A64])
(const_int 2 [0x2]))
(nil))
...
But the o_8 assignment translates to gb2 + 40, in other words, gb2 + 16 + 24:
...
(insn 5 2 6 2
(set
(reg/f:DI 89)
(symbol_ref:DI (gb2) [flags 0x2] var_decl 0x7fc7dfed0bd0 gb2))
(nil))
(insn 6 5 7 2
(set
(reg/v:SI 87 [ o ])
(mem/c:SI
(plus:DI (reg/f:DI 89)
(const_int 40 [0x28]))
[3 MEM[(struct B *)gb2 + 16B].D.2389.fi+0 S4 A64]))
(nil))
...
[Bug c++/66615] New: Ambiguous conversion operators, explicit unambiguous conversion operator and copy initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66615
Bug ID: 66615
Summary: Ambiguous conversion operators, explicit unambiguous
conversion operator and copy initialization
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fynjycfdby at gmail dot com
Target Milestone: ---
The following code is wrongly accepted, the output is an arbitrary number:
-
#include iostream
struct A {
explicit operator int() {
return 42;
}
operator float() {
return 123.0f;
}
operator double() {
return 456.0;
}
};
int main() {
int i = A(); // note copy-initialization
std::cout i std::endl;
}
-
With -Wall it generates a warning:
main.cpp: In function 'int main()':
main.cpp:19:18: warning: 'i' is used uninitialized in this function
[-Wuninitialized]
std::cout i std::endl;
The correct behavior should be failure to compile, because the operator int()
is explicit, and other implicit conversion operators make conversion to int
ambiguous.
I'm using MacPorts g++-mp-5
$ g++-mp-5 -v
Using built-in specs.
COLLECT_GCC=g++-mp-5
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/5.1.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc5/gcc5/work/gcc-5.1.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc5 --includedir=/opt/local/include/gcc5
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-5 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-5
--with-gxx-include-dir=/opt/local/include/gcc5/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc5 5.1.0_1'
Thread model: posix
gcc version 5.1.0 (MacPorts gcc5 5.1.0_1)
[Bug ipa/66616] fipa-cp-clone ignores thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616 --- Comment #1 from vries at gcc dot gnu.org --- r224712 ... $ ./xg++ -v Using built-in specs. COLLECT_GCC=./xg++ Target: x86_64-unknown-linux-gnu Configured with: src/configure --prefix=install --with-cloog=infra --with-ppl=infra --with-gmp=infra --with-mpfr=infra --with-mpc=infra --with-isl=infra --disable-bootstrap --enable-checking=yes,rtl --enable-languages=c,c++ Thread model: posix gcc version 6.0.0 20150621 (experimental) (GCC) ...
[Bug c++/60397] The value of char16_t u'\uffff' is 0xdfff instead of 0xffff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60397 Wesley J. Landaker wjl at icecavern dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||5.1.1 Resolution|--- |FIXED --- Comment #1 from Wesley J. Landaker wjl at icecavern dot net --- I can confirm that this is fixed in GCC 5.1.1. The issue from bug #59873 and bug #53690, also demonstrated in the attached code, is still broken in GCC 5.1.1.
[Bug c++/66615] Ambiguous conversion operators, explicit conversion operator and copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66615 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-21 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.9.2, 5.0, 6.0
[Bug c/66613] error in evaluationg cexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66613 Michael Lehn michael.l...@uni-ulm.de changed: What|Removed |Added CC||michael.l...@uni-ulm.de --- Comment #1 from Michael Lehn michael.l...@uni-ulm.de --- // Terminated with exit code 0. So were is the error?
[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53690 --- Comment #8 from Wesley J. Landaker wjl at icecavern dot net --- This major bug -- with security implications -- is still present in GCC 5.1.1. $ g++ --version g++ (Debian 5.1.1-20) 5.1.1 20150616 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug target/66620] New: bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
Bug ID: 66620
Summary: bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P
(insn)) fails.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
Target Milestone: ---
[root@localhost gcc]# cat lpt_commit.i
struct ubifs_nnode {
int iip;
int level;
int nbranch[4];
};
struct ubifs_nnode *next_pnode_to_dirty(struct ubifs_nnode *nnode)
{
int iip;
while (nnode-level 1) {
for (iip = 0; iip 4; iip++) {
if (nnode-nbranch[iip])
break;
}
nnode = nnode + iip;
}
for (iip = 0; iip 4; iip++)
if (nnode-nbranch[iip])
break;
return nnode + iip;
}
[root@localhost gcc]# /upstream/build-gcc-blackfin/gcc/cc1 -Os
-fno-reorder-blocks lpt_commit.i
next_pnode_to_dirty
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility build_ssa_passes opt_local_passes
free-inline-summary emutls whole-program profile_estimate icf
devirt cp inline pure-const static-var single-use
comdatsAssembling functions:
next_pnode_to_dirty
lpt_commit.i: In function 'next_pnode_to_dirty':
lpt_commit.i:24:1: internal compiler error: in hwloop_optimize, at
config/bfin/bfin.c:3523
}
^
0xd9c8eb hwloop_optimize
../../gcc/gcc/config/bfin/bfin.c:3523
0xe3b0cb optimize_loop
../../gcc/gcc/hw-doloop.c:610
0xe3cb1e reorg_loops(bool, hw_doloop_hooks*)
../../gcc/gcc/hw-doloop.c:674
0xda055f bfin_reorg_loops
../../gcc/gcc/config/bfin/bfin.c:3908
0xda055f bfin_reorg
../../gcc/gcc/config/bfin/bfin.c:4650
0xa3a169 execute
../../gcc/gcc/reorg.c:4030
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.
[root@localhost gcc]# /upstream/build-gcc-blackfin/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/upstream/build-gcc-blackfin/gcc/xgcc
Target: bfin-gchen-elf
Configured with: ../gcc/configure --target=bfin-gchen-elf --disable-nls
--disable-threads --disable-shared --disable-libssp --disable-libquadmath
--disable-libgomp --disable-libatomic --prefix=/upstream/release-blackfin
--without-headers --enable-languages=c,lto
Thread model: single
gcc version 6.0.0 20150620 (experimental) (GCC)
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #25 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #22) Provided that you're right, how would a bug in strlen this explain that gcc always segfaults when it needs to do float arithmetics? I don't know the code of mpfr. It could use __builtin_strlen for stuff like parsing numbers etc. However, the builtin_strlen code looks OK and hasn't been causing trouble elsewhere. So I guess that it just runs on broken data and then causes a buffer overrun. In other words, the actual bug is somewhere else -- a quite common scenario for segfault class of bugs.
[Bug testsuite/66621] New: [4.9/5/6 Regression] Mistakenly unsupported tests in g++.dg/torture/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66621
Bug ID: 66621
Summary: [4.9/5/6 Regression] Mistakenly unsupported tests in
g++.dg/torture/
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
I've noticed that since r208416 a lot of g++.dg/torture/* tests use
{ target c++11 } which makes all of them UNSUPPORTED, because g++.dg/torture/
does not cycle through c++98/c++11/c++14 options.
grep
'\(vshuf.*\|pr\(40991\|47559\|49770\|51598\|53161\|53602\|55260-1\|56768\|59295\)\)\.C'
g++.sum | grep -v ^UNSUPPORTED | wc -l
0
Thus, either all those tests should be changed back to use e.g. // {
dg-additional-options -std=c++11 }
or g++.dg/torture/ needs to cycle through the options too.
[Bug c++/66617] C++11 {brace} initialisation of virtually inherited derived class = failure to override base virtual function, unless all base ctors have same signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617 --- Comment #1 from Daniel Boles db0451 at gmail dot com --- Forgot to add the minimal replication steps mentioned, prepared by a fellow SO users: http://coliru.stacked-crooked.com/a/c4d031382115b59a thanks
[Bug c++/66617] C++11 {brace} initialisation of virtually inherited derived class = failure to override base virtual function, unless all base ctors have same signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617 Daniel Boles db0451 at gmail dot com changed: What|Removed |Added Attachment #35822|0 |1 is obsolete|| --- Comment #2 from Daniel Boles db0451 at gmail dot com --- Comment on attachment 35822 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35822 Original problem pattern I think I got some files mixed up in the first upload. I am about to upload a fixed zip; please refer to that instead. However, the main text is the key thing :-)
[Bug c/66618] New: Failure to diagnose non-constant initializer for static object with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618
Bug ID: 66618
Summary: Failure to diagnose non-constant initializer for
static object with -O1
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
$ uname -a
Linux m5 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux
$ gcc --version | head -n 1
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
$ cat bug.c
int main(void) {
const int not_a_constant = 0;
static int n = not_a_constant; /* constraint violation */
return n; /* avoid unused variable warning */
}
$ gcc -O0 -c -std=c11 -pedantic-errors -Wall -Wextra bug.c
bug.c: In function ‘main’:
bug.c:3:5: error: initializer element is not constant
static int n = not_a_constant; /* constraint violation */
^
$ gcc -O1 -c -std=c11 -pedantic-errors -Wall -Wextra bug.c
$
In the test program bug.c, the object not_a_constant is defined as const,
but its name is not a constant expression. The initializer for a static
expression must be a constant expression; using a non-constant expression is a
constraint violation, requiring a diagnostic (N1570 6.7.9p4).
With -O0, gcc correctly diagnoses this. I see the same problem with -O1,
-O2, and -O3, and with -std=c90, -std=c99, and -std=c11.
This is based on a question posted to Stack Overflow:
http://stackoverflow.com/q/30962512/827263
by user meet. Grzegorz Szpetkowski gets the credit for realizing that the
-O option triggers the bug.
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 --- Comment #15 from Thomas Koenig tkoenig at gcc dot gnu.org --- Is this something which could also have caused wrong-code issues in other circumstances, which we just didn't happen to find until this was exposed by Andre's patch and the test case? In other words, should we backport Mikael's patch?
[Bug c++/66617] New: C++11 {brace} initialisation of virtually inherited derived class = failure to override base virtual function, unless all base ctors have same signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617
Bug ID: 66617
Summary: C++11 {brace} initialisation of virtually inherited
derived class = failure to override base virtual
function, unless all base ctors have same signature
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
Created attachment 35822
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35822action=edit
Original problem pattern
Example steps:
Create the following struct hierarchy:
A C
v
v
B
With
= struct A containing a pure virtual function
= B and C taking public virtual inheritance from A.
Now create struct D inheriting from B and C and implementing the pure virtual
function.
This will not work when D initialises its base classes using the new {brace}
initialisation UNLESS, and only if, all base constructors have the same
function signature/number of arguments.
= Pure virtual function in base generates errors about being unable to
allocate abstract classes B and C
= Non-pure vfunc generates undefined references to the pure vfunc in B and C.
Contructing D using (parentheses) initialisation works fine and leads to the
expected result. This is as simple as replacing the brackets in the
instantiation, nothing more.
Supporting evidence are:
= original thread on StackOverflow, by my handle @underscore_d - containing
original problem code using {brace} initialisation as attached in
virtual2.cpp - with working example (same ctor signatures) virtual3.cpp
http://stackoverflow.com/questions/30967490/virtual-inheritance-pure-v-function-in-base-fails-with-abstract-pure-error?noredirect=1#comment49967008_30967490
= minimal replication steps outlined by fellow SO user @0x499602D2
Attached also is virtual4.cpp, which as mentioned, is merely virtual2.cpp
with the instantiation of the final derived class changed to use (parenthesis)
initialisation instead of {braces}
Using G++ 4.9.2 from MSYS2 64-bit, latest version I was able to find.
Many thanks
Daniel B.
[Bug c++/66617] C++11 {brace} initialisation of virtually inherited derived class = failure to override base virtual function, unless all base ctors have same signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617 --- Comment #3 from Daniel Boles db0451 at gmail dot com --- Created attachment 35824 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35824action=edit 3 cpp files showing various permutations from totally broken braces, to fully working parentheses Revised version as I had saved a wrong file version in the last upload.
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 --- Comment #13 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 35823 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35823action=edit next attempt
[Bug c/66613] error in evaluationg cexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66613 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #2 from Mikhail Maltsev miyuki at gcc dot gnu.org --- Presumably, the problem is the difference in precision. But what is run_C99.bat? And what platform do you use? With current GCC 4.8 branch (x86_64-linux) I get the following result: $ /opt/gcc-4.8-latest/bin/gcc -std=c99 -lquadmath -lm ./test.c -o test_c99 ./test_c99 /**/ SECTION 1 _Complex float zF = 1.F + 2.Fi ; crealf(cexpf(zF)) = -1.131204 cimagf(cexpf(zF)) = 2.471727 _Complex double zD = 1.D + 2.Di ; creal(cexp(zD))= -1.131204E+00 cimag(cexp(zD))= 2.471727E+00 creal(cexp(1.D + 2.Di))= -1.131204 cimag(cexp(1.D + 2.Di))= 2.471727 _Complex long double zL= 1.L + 2.Li creall(cexpl(zL)) = -3.177877E-189 cimagl(cexpl(zL)) = -3.177877E-189 creall(cexpl(1.L + 2.Li)) = -0.00 cimagl(cexpl(1.L + 2.Li)) = -0.00 __complex128 zQ= 1.Q + 2.Qi crealq(cexpq(zQ)) = 0.00 cimagq(cexpq(zQ)) = 0.00 /**/ SECTION 2 alfa = 0.333432674407958984375000 sizeof(alfa))= 4 1.f/3.f = 0.333432674407958984375000 sizeof(1.f/3.f)) = 4 /**/ It is possible that the problem is specific to 4.8.1, but I don't have it installed right now. If someone has, could you check it please.
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 --- Comment #14 from Thomas Koenig tkoenig at gcc dot gnu.org --- (In reply to Mikael Morin from comment #13) Created attachment 35823 [details] next attempt Looks very good (fixes the test case and the variants I have here). Regression-testing next.
[Bug c++/66619] New: Internal compiler error: variable template deduced by template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66619
Bug ID: 66619
Summary: Internal compiler error: variable template deduced by
template argument deduction
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.godfrey99 at gmail dot com
Target Milestone: ---
This bug is two-fold. GCC trunk gives an ICE when val is instantiated with an
lvalue reference:
int y;
templateclass T
T val = y;
int main() {
auto x = valint;
}
##
prog.cc: In function 'int main()':
prog.cc:7:16: internal compiler error: in convert_like_real, at cp/call.c:6485
auto x = valint;
^
0x5a8cd6 convert_like_real
/home/heads/gcc/gcc-source/gcc/cp/call.c:6485
0x5b15a1 initialize_reference(tree_node*, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/call.c:9732
0x5b9188 grok_reference_init
/home/heads/gcc/gcc-source/gcc/cp/decl.c:5008
0x5b9188 check_initializer
/home/heads/gcc/gcc-source/gcc/cp/decl.c:5900
0x5ce24c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/heads/gcc/gcc-source/gcc/cp/decl.c:6619
0x646978 cp_parser_init_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:17316
0x648763 cp_parser_simple_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11608
0x62b2c3 cp_parser_block_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11482
0x62bdd1 cp_parser_declaration_statement
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11109
0x62cb0a cp_parser_statement
/home/heads/gcc/gcc-source/gcc/cp/parser.c:9810
0x62d142 cp_parser_statement_seq_opt
/home/heads/gcc/gcc-source/gcc/cp/parser.c:10088
0x62d273 cp_parser_compound_statement
/home/heads/gcc/gcc-source/gcc/cp/parser.c:10042
0x64538b cp_parser_function_body
/home/heads/gcc/gcc-source/gcc/cp/parser.c:19221
0x64538b cp_parser_ctor_initializer_opt_and_function_body
/home/heads/gcc/gcc-source/gcc/cp/parser.c:19257
0x645eb0 cp_parser_function_definition_after_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:23517
0x646d5e cp_parser_function_definition_from_specifiers_and_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:23429
0x646d5e cp_parser_init_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:17089
0x648763 cp_parser_simple_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11608
0x62b2c3 cp_parser_block_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11482
0x625425 cp_parser_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11379
##
This second example gives an error that doesn't make sense. Instantiate val
with an rvalue reference:
templateclass T
T val = 0;
int main() {
auto x = valint;
}
prog.cc: In function 'int main()':
prog.cc:7:16: error: cannot bind 'int' lvalue to 'int'
auto x = valint;
##
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 6.0.0 20150621 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-std=gnu++1z' '-I' '/usr/local/sprout'
'-I' '/usr/local/boost-1.58.0/include' '-L/usr/local/boost-1.58.0/lib' '-Wall'
'-Wextra' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/cc1plus -quiet
-v -I /usr/local/sprout -I /usr/local/boost-1.58.0/include -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE prog.cc -quiet -dumpbase prog.cc -mtune=generic
-march=x86-64 -auxbase prog -Wall -Wextra -std=gnu++1z -version -o
/tmp/cc38EvaY.s
GNU C++14 (GCC) version 6.0.0 20150621 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 6.0.0 20150621 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
[Bug c++/66255] [6 Regression] ice in retrieve_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66255 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 66607 has been marked as a duplicate of this bug. ***
[Bug c++/66607] ICE instantiating a template on a function reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66607 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 66255 ***
[Bug c++/58063] default arguments evaluated twice per call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #15 from Ville Voutilainen ville.voutilainen at gmail dot com --- *** Bug 61856 has been marked as a duplicate of this bug. ***
[Bug c++/61856] Ternary operator in an NSDMI causes double evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61856 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com --- Fixed by the resolution of PR58063. *** This bug has been marked as a duplicate of bug 58063 ***
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 61856, which changed state. Bug 61856 Summary: Ternary operator in an NSDMI causes double evaluation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61856 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug rtl-optimization/66614] LRA might fail to eliminate dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66614 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-21 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- This happens by design, as lra uses for some reason two steps to eliminate the frame registers, first the offset alone is changed from frame-relative to sp-relative, and then only the base register is changed from frame to sp, not changing the offset at this time. These intermediate values are never seen in any rtl dumps. Nice discovery work. How come may_trap_p is invoked on this semi-broken RTL?
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 --- Comment #10 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to James Almer from comment #9) Created attachment 35804 [details] Preprocessed code where a test instruction is still generated Please look at the attachment. [jamrial@archVM ~]$ gcc -std=c99 -march=haswell -O3 -c hevc_ps.i [jamrial@archVM ~]$ objdump --disassemble hevc_ps.o | grep -B2 -A2 bzhi 5854: c4 62 22 f7 d6 sarx %r11d,%esi,%r10d 5859: c4 62 22 f7 da sarx %r11d,%edx,%r11d 585e: c4 e2 70 f5 f6 bzhi %ecx,%esi,%esi 5863: 45 89 9e 68 33 00 00mov%r11d,0x3368(%r14) 586a: 41 89 c3mov%eax,%r11d -- 589d: 85 f6 test %esi,%esi 589f: 75 0d jne58ae ff_hevc_decode_nal_sps+0x1a6e 58a1: c4 e2 70 f5 d2 bzhi %ecx,%edx,%edx 58a6: 85 d2 test %edx,%edx 58a8: 0f 84 5a 03 00 00 je 5c08 ff_hevc_decode_nal_sps+0x1dc8 [...] Not sure why the new model is not working here. Because of the cost model. Combine pass says: Trying 2631 - 2633: Successfully matched this instruction: (set (reg:CCZ 17 flags) (compare:CCZ (zero_extract:SI (reg:SI 2360 [ D.14992 ]) (umin:SI (zero_extend:SI (subreg:QI (reg:SI 301 [ D.14999 ]) 0)) (const_int 32 [0x20])) (const_int 0 [0])) (const_int 0 [0]))) rejecting combination of insns 2631 and 2633 original costs 12 + 4 = 16 replacement cost 18
