[Bug tree-optimization/66894] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66894
Bug ID: 66894
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk mis-compiles the following code on x86_64-linux-gnu at
-Os and above in both 32-bit and 64-bit modes.
This is a regression from 5.1.x.
It is possibly related to PR 66863, which has just been fixed.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150715 (experimental) [trunk revision 225804] (GCC)
$
$ gcc-trunk -O1 small.c; ./a.out
$ gcc-5.1 -Os small.c; ./a.out
$
$ gcc-trunk -Os small.c
$ ./a.out
Floating point exception (core dumped)
$
-
short a, b;
int
main ()
{
for (; a != 1; a += 3)
{
int c = 0;
for (; c 2; c++)
if (a)
{
char d = a;
b = d ? 1 / d : 0;
}
else
break;
}
return 0;
}
[Bug c++/66892] New: Fix of core language defect 355 has status c++11 but is not implemented yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66892 Bug ID: 66892 Summary: Fix of core language defect 355 has status c++11 but is not implemented yet Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: anders.granlund.0 at gmail dot com Target Milestone: --- The following core language defect has status c++11 but is not implemented yet: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#355 Without implementing this fix gcc doesn't fully support c++11 syntax.
[Bug middle-end/66891] New: ICE in expand_call, at calls.c:3407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66891 Bug ID: 66891 Summary: ICE in expand_call, at calls.c:3407 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: alasdairsinc at gmail dot com Target Milestone: --- Created attachment 35992 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35992action=edit -save-temps for affected file from wine I got the following ICE when compiling Wine with the latest trunk rev 225852. -O0 compiles without error, O1 and O2 both give and ICE. [ams@hal comctl32]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ams/src/gcc/install/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c,c++ --prefix=/home/ams/src/gcc/install Thread model: posix gcc version 6.0.0 20150715 (experimental) (GCC) [ams@hal comctl32]$ gcc -m32 -oblah -g -O2 propsheet.i -c ../../../wine-git/dlls/comctl32/propsheet.c: In function ‘PROPSHEET_DoCommand’: ../../../wine-git/dlls/comctl32/propsheet.c:3126:10: internal compiler error: in expand_call, at calls.c:3407 if (PROPSHEET_Apply(hwnd, wID == IDOK ? 1: 0) == FALSE) ^ 0x6e191f expand_call(tree_node*, rtx_def*, int) ../../gcc/gcc/calls.c:3406 0x7ebe04 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10362 0x7f9432 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*) ../../gcc/gcc/expr.c:5398 0x7fba55 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/gcc/expr.c:5170 0x6ef386 expand_call_stmt ../../gcc/gcc/cfgexpand.c:2350 0x6ef386 expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3239 0x6ef386 expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3400 0x6f11fc expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5412 0x6f7b86 execute ../../gcc/gcc/cfgexpand.c:6023 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.
[Bug c++/66893] New: disallowed initialization of reference with user-defined conversion function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66893
Bug ID: 66893
Summary: disallowed initialization of reference with
user-defined conversion function
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider the following:
struct B {};
struct S { explicit operator B(); };
int main() {
B const t(S{});
}
According to [over.match.ref]:
Those non-explicit conversion
functions that are not hidden within S and yield type “lvalue reference to cv2
T2” (when initializing an lvalue reference or an rvalue reference to function)
or “cv2 T2” or “rvalue reference to cv2 T2” (when initializing an rvalue
reference or an lvalue reference to function), where “cv1 T” is
reference-compatible (8.5.3) with “cv2 T2”, are candidate functions.
In this case, B const (cv1 T) is reference-compatible with B (cv2 T2), so the
operator should be a candidate function. However, gcc rejects it:
main.cpp: In function 'int main()':
main.cpp:5:19: error: invalid initialization of reference of type 'const B'
from expression of type 'S'
B const t(S{});
^
[Bug c++/66842] libatomic uses multiple locks for locked atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842
Bin Fan bin.x.fan at oracle dot com changed:
What|Removed |Added
Component|c |c++
--- Comment #4 from Bin Fan bin.x.fan at oracle dot com ---
Since I don't see any response from C so far, I change the example to C++ code,
and change the category to c++. Could C++ folks take a look?
-bash-4.2$ cat c++11_locked_atomics.cpp
#include atomic
using namespace std;
#ifndef SIZE
#define SIZE 1024
#endif
typedef struct {
char a[SIZE];
} lock_obj_t;
extern C {
extern void display_nlocks ();
}
int main()
{
lock_obj_t v2 = {0};
atomiclock_obj_t v1 = ATOMIC_VAR_INIT(v2);
v2 = atomic_load (v1);
display_nlocks ();
return 0;
}
gcc -shared -ldl -fPIC libmythread.c -o libmythread.so -g
g++ -std=c++11 -latomic c++11_locked_atomics.cpp -DSIZE=2048 -g -L./
-Wl,-rpath=./ -lmythread
+ LD_PRELOAD=./libmythread.so
+ a.out
pthread_mutex_lock is called 32 times
The g++ version is still 4.9.2.
[Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #16 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jul 15 07:39:30 2015 New Revision: 225807 URL: https://gcc.gnu.org/viewcvs?rev=225807root=gccview=rev Log: PR rtl-optimization/58066 * calls.c (expand_call): Precompute register parameters before stack alignment is performed. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c
[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86_64 Component|rtl-optimization|target --- Comment #17 from Uroš Bizjak ubizjak at gmail dot com --- Back to target component.
[Bug target/65956] [5/6 Regression] Another ARM overaligned arg passing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed for 5.2 ?
[Bug rtl-optimization/66838] Calling multiple SYSV AMD64 ABI functions from MS x64 ABI one results in clobbered parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66838 --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- Fixed for mainline, needs backport to gcc-5 branch.
[Bug middle-end/66872] fold a ((1 b) - 1) to a ~(-1 b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66872 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- This ought to be easy to do in match.pd, but I'm not sure if this transformation is beneficial for other architectures as well (it doesn't seem to reduce the number of operations).
[Bug middle-end/66876] New: vrp: changing unsigned to signed comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66876
Bug ID: 66876
Summary: vrp: changing unsigned to signed comparison
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: konstantin.vladimirov at gmail dot com
Target Milestone: ---
Minimized test case (note explicit unsigned long cast):
---
#include stdlib.h
int a = 0xecfb39f5;
unsigned short *d = (unsigned short *) a;
int
main (void)
{
if ((unsigned long) (65536 * d[1] + d[0]) (1UL 28))
{
abort ();
}
return 0;
}
---
Compiler version:
---
$ ~/x86-toolchain-5.1/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/tilir/x86-toolchain-5.1/bin/gcc
COLLECT_LTO_WRAPPER=/home/tilir/x86-toolchain-5.1/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1-src/gcc_5_1_0_release/configure
--enable-languages=c,c++ --prefix=/home/tilir/x86-toolchain-5.1/
Thread model: posix
gcc version 5.1.0 (GCC)
---
$ ~/x86-toolchain-5.1/bin/gcc -O2 test.c
$ ./a.out
Aborted
but
$ ~/x86-toolchain-5.1/bin/gcc -O2 test.c -fno-tree-vrp
$ ./a.out
Everything is ok.
Before VRP:
_9 = (unsigned int) _8;
if (_9 = 268435455)
goto bb 3;
else
goto bb 4;
On VRP stage:
_8 : -- single use.
_9 = (unsigned int) _8;
_9 : -- single use.
if (_9 = 268435455)
After VRP:
if (_8 = 268435455)
goto bb 3;
else
goto bb 4;
By C11 standard, the rank of unsigned long is equal to rank of long and higher,
then rank of int, so integer promotions here should make unsigned long from
both sides.
[Bug libgcc/66854] libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 --- Comment #4 from Sebastian Huber sebastian.hu...@embedded-brains.de --- (In reply to Michael Meissner from comment #3) Created attachment 35978 [details] Proposed patch to fix the problem I believe this patch fixes the problem. I was able to build libgcc with this patch installed. I could not complete a full RTEMS build (I suspect I am missing some parts of the software). Thanks for the quick fix. With your patch I can build without errors. To build the powerpc-rtems target you need a link to the latest Newlib in your GCC directory, e.g. newlib - ../newlib-git/newlib. I used the following configure options: ../gcc-git/configure --prefix=/opt/rtems-4.11 --target=powerpc-rtems4.11 --verbose --with-gnu-as --with-gnu-ld --with-newlib --disable-libstdcxx-pch --disable-nls --disable-lto --disable-plugin --without-included-gettext --enable-version-specific-runtime-libs --enable-threads --enable-newlib-io-c99-formats --enable-libgomp --enable-languages=c,c++
[Bug target/66866] [miscompile] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|uros at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Richard Biener from comment #5) Safe fix: No, no... pextr to a temporary should be used here. I plan to introduce pextr handling to insvmode pattern. Then, ix86_expand_pinsr will call ix86_expand_pextr for non-lowpart src subregs (and in a similar way, new ix86_expand_pextr will call ix86_expand_pinsr for non-lowpart dst subregs).
[Bug testsuite/66734] Many MPX tests are skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66734 --- Comment #2 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Wed Jul 15 09:56:00 2015 New Revision: 225815 URL: https://gcc.gnu.org/viewcvs?rev=225815root=gccview=rev Log: PR testsuite/66734 * gcc.dg/lto/lto.exp: Initialize MPX. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/lto/lto.exp
[Bug middle-end/66876] vrp: changing unsigned to signed comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66876 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- Compile with -fsanitize=undefined and you'll get runtime error: signed integer overflow: 60667 * 65536 cannot be represented in type 'int' The 65536 * d[1] sub-expression is evaluated as int*int-int, so it overflows and then all bets are off. Append a U to the 64K literal.
[Bug testsuite/66734] Many MPX tests are skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66734 Ilya Enkovich ienkovich at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Fixed
[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530 Bug 65530 depends on bug 66734, which changed state. Bug 66734 Summary: Many MPX tests are skipped https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66734 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873 vries at gcc dot gnu.org changed: What|Removed |Added Attachment #35983|0 |1 is obsolete|| --- Comment #7 from vries at gcc dot gnu.org --- Created attachment 35986 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35986action=edit Updated tentative patch I found that always doing graphite before parloops resulted in failures to parallelize reduction testcases. I've split things up now: - first we do parloopsred, a parloops variant in which we only handle reductions - then we do graphite - then we do the normal parloops This seems to combine the best of graphite and parloops. The only gotcha is that I had to disable pass_iv_canon when tree_parallelize_loops 1. It seems to interfere with graphite. I did not observe any failures to parallelize due to not running pass_iv_canon.
[Bug middle-end/66876] vrp: changing unsigned to signed comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66876 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, this looks invalid.
[Bug tree-optimization/66875] entire for loop got eliminated at cddce2 tree-opt stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66875
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
I'm just guessing that
for(i = 1; i = (188 + 1); i++) {
if (prot_short_str[i]) {
is accessing prot_short_str out of bounds.
[Bug tree-optimization/66875] entire for loop got eliminated at cddce2 tree-opt stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66875 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-07-15 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Yes, please try -fsanitize=undefined. This looks like an invalid.
[Bug tree-optimization/66875] New: entire for loop got eliminated at cddce2 tree-opt stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66875 Bug ID: 66875 Summary: entire for loop got eliminated at cddce2 tree-opt stage Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: patricksung at gmail dot com Target Milestone: --- Created attachment 35985 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35985action=edit Intermediate of the C source Hi the attached code in the parse_peppi_protocol() (which got inline into parse()) with the for loop (and nearby code) from line 10821 to line 10995 got eliminated. We found out this problem starting with GCC version 4.9.2 and subsequently also tested with GCC 4.9.3 and 5.1 also having this problem. One of the following two ways will work around this problem, 1) -fno-aggressive-loop-optimizations (obvious?) 2) change the for loop code from for (...; i++) to for (...; --i), i.e. the loop search backwards. We also found that the code elimination was happening at the cddce2 stage of the tree optimization. Here is the command line used with the -v output (with compiler warnings removed that I believe is irrelevant to this problem to make the output a little bit cleaner here) x86_64-peplink-linux-gnu-gcc -D_LARGEFILE_SOURCE=1 -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DXTABLES_LIBDIR=\/usr/lib/xtables\ -DXTABLES_INTERNAL -I../include -I.. -I../include -I/home/psung/tmp/fw.63.ndpi-test/staging/usr/include -I/home/psung/tmp/fw.63.ndpi-test/staging/usr/include -Wp,-MMD,./.libxt_peppi.oo.d,-MT,libxt_peppi.oo -Wall -Waggregate-return -Wmissing-declarations-Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -pipe -D_INIT=libxt_peppi_init -DPIC -fPIC -Wextra -g -O3 -o libxt_peppi.oo -c libxt_peppi.c -dp -save-temps -fdump-tree-cddce2-details-stats -fno-strict-aliasing -fwrapv -v x86_64-peplink-linux-gnu-gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. COLLECT_GCC=x86_64-peplink-linux-gnu-gcc Target: x86_64-peplink-linux-gnu Configured with: /home/psung/toolchains-2015/x64-4.9.3/.build/src/gcc-4.9.3/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=x86_64-peplink-linux-gnu --prefix=/home/psung/x-tools-2015/x86_64-peplink-linux-gnu --with-sysroot=/home/psung/x-tools-2015/x86_64-peplink-linux-gnu/x86_64-peplink-linux-gnu/sysroot --enable-languages=c,c++,go --with-pkgversion='crosstool-NG crosstool-ng-1.21.0-50-g488f7a8' --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --with-gmp=/home/psung/toolchains-2015/x64-4.9.3/.build/x86_64-peplink-linux-gnu/buildtools --with-mpfr=/home/psung/toolchains-2015/x64-4.9.3/.build/x86_64-peplink-linux-gnu/buildtools --with-mpc=/home/psung/toolchains-2015/x64-4.9.3/.build/x86_64-peplink-linux-gnu/buildtools --with-ppl=no --with-isl=no --with-cloog=no --with-libelf=/home/psung/toolchains-2015/x64-4.9.3/.build/x86_64-peplink-linux-gnu/buildtools --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --enable-gold --disable-nls --disable-multilib --with-local-prefix=/home/psung/x-tools-2015/x86_64-peplink-linux-gnu/x86_64-peplink-linux-gnu/sysroot --enable-long-long Thread model: posix gcc version 4.9.3 (crosstool-NG crosstool-ng-1.21.0-50-g488f7a8) COLLECT_GCC_OPTIONS='-D' '_LARGEFILE_SOURCE=1' '-D' '_LARGE_FILES' '-D' '_FILE_OFFSET_BITS=64' '-D' '_REENTRANT' '-D' 'XTABLES_LIBDIR=/usr/lib/xtables' '-D' 'XTABLES_INTERNAL' '-I' '../include' '-I' '..' '-I' '../include' '-I' '/home/psung/tmp/fw.63.ndpi-test/staging/usr/include' '-I' '/home/psung/tmp/fw.63.ndpi-test/staging/usr/include' '-Wall' '-Waggregate-return' '-Wmissing-declarations' '-Wmissing-prototypes' '-Wredundant-decls' '-Wshadow' '-Wstrict-prototypes' '-Winline' '-pipe' '-D' '_INIT=libxt_peppi_init' '-D' 'PIC' '-fPIC' '-Wextra' '-g' '-O3' '-o' 'libxt_peppi.oo' '-c' '-dp' '-save-temps' '-fdump-tree-cddce2-details-stats' '-fno-strict-aliasing' '-fwrapv' '-v' '-mtune=generic' '-march=x86-64' /home/psung/x-tools-2015/x86_64-peplink-linux-gnu/libexec/gcc/x86_64-peplink-linux-gnu/4.9.3/cc1 -E -quiet -v -I ../include -I .. -I ../include -I /home/psung/tmp/fw.63.ndpi-test/staging/usr/include -I /home/psung/tmp/fw.63.ndpi-test/staging/usr/include -D _LARGEFILE_SOURCE=1 -D _LARGE_FILES -D _FILE_OFFSET_BITS=64 -D _REENTRANT -D XTABLES_LIBDIR=/usr/lib/xtables -D XTABLES_INTERNAL -D _INIT=libxt_peppi_init -D PIC -MMD ./.libxt_peppi.oo.d -MT libxt_peppi.oo libxt_peppi.c -mtune=generic -march=x86-64 -Wall -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -Wextra -fPIC -fdump-tree-cddce2-details-stats -fno-strict-aliasing -fwrapv
[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3 or -miamcu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626 --- Comment #21 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to H.J. Lu from comment #20) Testcase in comment #1 still fails with r225789. Please note comment #3, where I recalled the testcase from Comment #2: A better testcase: Nope. This one works OK. The testcase from Comment #1 fails. Sorry for the confusion...
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #2 from nsz at gcc dot gnu.org --- Author: nsz Date: Wed Jul 15 09:03:15 2015 New Revision: 225810 URL: https://gcc.gnu.org/viewcvs?rev=225810root=gccview=rev Log: Add missing PR target/66731 to gcc/testsuite/Changelog Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/66869] [6 regression] -Wunused-function no longer warns for static declarations without definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66869 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||aldyh at gcc dot gnu.org Target Milestone|--- |6.0
[Bug c++/61936] template template friends fail to compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61936 hr.jonas.hansen at gmail dot com changed: What|Removed |Added CC||hr.jonas.hansen at gmail dot com --- Comment #3 from hr.jonas.hansen at gmail dot com --- The the errors remain under gcc 5.1.0.
[Bug target/66866] [miscompile] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #6) (In reply to Richard Biener from comment #5) Safe fix: No, no... pextr to a temporary should be used here. I plan to introduce pextr handling to insvmode pattern. Then, ... extzvmode pattern.
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to kugan from comment #12) Thanks. I can now reproduce it. However, If I just use the changes to gcc/postreload.c (changes for bug 66838), I can get the trunk to work. I can confrim this with [trunk revision 225805], please see insn @9c, it reloads %rsi. 0010 RtlConvertSidToUnicodeString: 10: 55 push %rbp 11: 57 push %rdi 12: 31 c0 xor%eax,%eax 14: 56 push %rsi 15: 53 push %rbx 16: 48 89 d3mov%rdx,%rbx 19: 48 8d 35 00 00 00 00lea0(%rip),%rsi# 20 RtlConvertSidToUnicodeString+0x10 1c: R_X86_64_PC32 .rodata+0xfffc 20: 48 81 ec 08 02 00 00sub$0x208,%rsp 27: 0f 29 b4 24 60 01 00movaps %xmm6,0x160(%rsp) 2e: 00 2f: 48 89 e7mov%rsp,%rdi 32: 48 89 e5mov%rsp,%rbp 35: 0f 29 bc 24 70 01 00movaps %xmm7,0x170(%rsp) 3c: 00 3d: 44 0f 29 84 24 80 01movaps %xmm8,0x180(%rsp) 44: 00 00 46: 44 0f 29 8c 24 90 01movaps %xmm9,0x190(%rsp) 4d: 00 00 4f: 44 0f 29 94 24 a0 01movaps %xmm10,0x1a0(%rsp) 56: 00 00 58: 44 0f 29 9c 24 b0 01movaps %xmm11,0x1b0(%rsp) 5f: 00 00 61: 44 0f 29 a4 24 c0 01movaps %xmm12,0x1c0(%rsp) 68: 00 00 6a: 44 0f 29 ac 24 d0 01movaps %xmm13,0x1d0(%rsp) 71: 00 00 73: 44 0f 29 b4 24 e0 01movaps %xmm14,0x1e0(%rsp) 7a: 00 00 7c: 44 0f 29 bc 24 f0 01movaps %xmm15,0x1f0(%rsp) 83: 00 00 85: 0f b6 12movzbl (%rdx),%edx 88: e8 00 00 00 00 callq 8d RtlConvertSidToUnicodeString+0x7d 89: R_X86_64_PLT32 sprintfW+0xfffc 8d: 0f b6 53 03 movzbl 0x3(%rbx),%edx 91: 0f b6 4b 04 movzbl 0x4(%rbx),%ecx 95: 48 98 cltq 97: 48 8d 7c 45 00 lea0x0(%rbp,%rax,2),%rdi 9c: 48 8d 35 00 00 00 00lea0(%rip),%rsi# a3 RtlConvertSidToUnicodeString+0x93 9f: R_X86_64_PC32 .rodata+0xfffc a3: 31 c0 xor%eax,%eax a5: c1 e2 08shl$0x8,%edx a8: 09 ca or %ecx,%edx aa: 0f b6 4b 05 movzbl 0x5(%rbx),%ecx ae: c1 e2 10shl$0x10,%edx b1: c1 e1 08shl$0x8,%ecx b4: 0f b7 c9movzwl %cx,%ecx b7: 09 ca or %ecx,%edx b9: e8 00 00 00 00 callq be RtlConvertSidToUnicodeString+0xae ba: R_X86_64_PLT32 sprintfW+0xfffc be: 0f 28 b4 24 60 01 00movaps 0x160(%rsp),%xmm6 c5: 00 c6: 0f 28 bc 24 70 01 00movaps 0x170(%rsp),%xmm7 cd: 00 ce: 44 0f 28 84 24 80 01movaps 0x180(%rsp),%xmm8 d5: 00 00 d7: 44 0f 28 8c 24 90 01movaps 0x190(%rsp),%xmm9 de: 00 00 e0: 44 0f 28 94 24 a0 01movaps 0x1a0(%rsp),%xmm10 e7: 00 00 e9: 44 0f 28 9c 24 b0 01movaps 0x1b0(%rsp),%xmm11 f0: 00 00 f2: 44 0f 28 a4 24 c0 01movaps 0x1c0(%rsp),%xmm12 f9: 00 00 fb: 44 0f 28 ac 24 d0 01movaps 0x1d0(%rsp),%xmm13 102: 00 00 104: 44 0f 28 b4 24 e0 01movaps 0x1e0(%rsp),%xmm14 10b: 00 00 10d: 44 0f 28 bc 24 f0 01movaps 0x1f0(%rsp),%xmm15 114: 00 00 116: 48 81 c4 08 02 00 00add$0x208,%rsp 11d: 5b pop%rbx 11e: 5e pop%rsi 11f: 5f pop%rdi 120: 5d pop%rbp 121: c3 retq
[Bug middle-end/66872] fold a ((1 b) - 1) to a ~(-1 b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66872 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-15 Ever confirmed|0 |1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- I think we can assume (on gimple) that andn is available and thus canonicalize to andn form when possible. The transform at least makes one binary operation an unary operation.
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Janne Blomqvist jb at gcc dot gnu.org --- Fixed on gcc-5 branch as well, release manager approval at https://gcc.gnu.org/ml/gcc/2015-07/msg00184.html . Closing as fixed, thanks Rainer for reporting the issue and testing!
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 --- Comment #8 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Wed Jul 15 07:00:23 2015 New Revision: 225805 URL: https://gcc.gnu.org/viewcvs?rev=225805root=gccview=rev Log: PR 66861 Fix null pointer crash on mingw. 2015-07-15 Janne Blomqvist j...@gcc.gnu.org PR libfortran/66861 * io/unix.c (compare_file_filename): Verify that u-filename is non-NULL before strcmp. (find_file0): Likewise. Modified: branches/gcc-5-branch/libgfortran/ChangeLog branches/gcc-5-branch/libgfortran/io/unix.c
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #12 from kugan at gcc dot gnu.org --- (In reply to austinenglish from comment #5) (In reply to kugan from comment #4) Ok, I downloaded wine-1.7.47.tar.bz2 and built it with trunk gcc. What do I have to do to reproduce this please? Sorry, forgot to specify it only happens with wine64. In any case, to reproduce: tar xjvf wine-1.7.47.tar.bz2 cd wine ./configure --enable-win64 --disable-tests make -j4 ./wine wineboot Expected behavior: wineboot runs to completion, exits 0 Actual behavior: wine segfaults as I pointed out previously, if you don't apply the patch for bug 66838, you will likely see that wine crashes instead of exiting 0 (but you will only see that with the cprop.c changes reverted) Hope that helps, please let me know if anything is unclear. Thanks. I can now reproduce it. However, If I just use the changes to gcc/postreload.c (changes for bug 66838), I can get the trunk to work.
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873
--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to kargl from comment #5)
Does the loop ordering matter? Fortran is a column major language,
so your nested loops are backwards. One would normally write.
do jj = 0, n - 1
do ii = 0, n - 1
x(ii, jj) = ii + jj + 3
end do
end do
where the first loop index varies most rapidly.
Thanks for letting me know. I'm obviously not fluent in Fortran.
Interchanging ii and jj in the array access of the example, and again disabling
pass_iv_canon, gives:
...
(Data Dep:
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 500}_3, +, 1}_4
#)
#(Data Ref:
# bb: 4
# stmt: x[_12] = _14;
# ref: x[_12];
# base_object: x;
# Access function 0: {{0, +, 500}_3, +, 1}_4
#)
access_fn_A: {{0, +, 500}_3, +, 1}_4
access_fn_B: {{0, +, 500}_3, +, 1}_4
(subscript
iterations_that_access_an_element_twice_in_A: [0]
last_conflict: scev_not_known
iterations_that_access_an_element_twice_in_B: [0]
last_conflict: scev_not_known
(Subscript distance: 0 ))
inner loop index: 0
loop nest: (3 4 )
distance_vector: 0 0
distance_vector: 1 -500
direction_vector: ==
direction_vector: +-
)
FAILED: data dependencies exist across iterations
...
Again, using -floops-parallelize-all allows the outer loop to be paralelized.
[Bug middle-end/66872] fold a ((1 b) - 1) to a ~(-1 b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66872 --- Comment #2 from Paolo Bonzini bonzini at gnu dot org --- left shift of negative value is undefined behavior in C It's not in any of GCC's intermediate representations, though.
[Bug rtl-optimization/66838] Calling multiple SYSV AMD64 ABI functions from MS x64 ABI one results in clobbered parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66838 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jul 15 07:28:33 2015 New Revision: 225806 URL: https://gcc.gnu.org/viewcvs?rev=225806root=gccview=rev Log: PR rtl-optimization/66838 * postreload.c (reload_cse_move2add): Also process CALL_INSN_FUNCTION_USAGE when resetting information of call-clobbered registers. testsuite/ChangeLog: PR rtl-optimization/66838 * gcc.target/i386/pr66838.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr66838.c Modified: trunk/gcc/ChangeLog trunk/gcc/postreload.c trunk/gcc/testsuite/ChangeLog
[Bug libgcc/66854] libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org --- Comment #6 from Michael Meissner meissner at gcc dot gnu.org --- Fixed in subversion id 225843.
[Bug target/66885] New: trunk/gcc/config/mcore/mcore.c:1656: poor code order ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66885 Bug ID: 66885 Summary: trunk/gcc/config/mcore/mcore.c:1656: poor code order ? Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- [trunk/gcc/config/mcore/mcore.c:1656]: (style) Expression is always false because 'else if' condition matches previous condition at line 1654. Source code is if (bytes 1) max = 4*4; else if (bytes 3) max = 8*4; else max = 16*4; Suggest check 3 *before 1.
[Bug boehm-gc/66886] New: trunk/boehm-gc/darwin_stop_world.c: 2 * redundant code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66886
Bug ID: 66886
Summary: trunk/boehm-gc/darwin_stop_world.c: 2 * redundant code
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boehm-gc
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
1.
[trunk/boehm-gc/darwin_stop_world.c:335]: (style) Redundant condition:
GC_use_mach_handler_thread. 'A (!A || B)' is equivalent to 'A || B'
(!GC_use_mach_handler_thread
|| (GC_use_mach_handler_thread
GC_mach_handler_thread != thread))) {
2.
[trunk/boehm-gc/darwin_stop_world.c:474]: (style) Redundant condition:
GC_use_mach_handler_thread. 'A (!A || B)' is equivalent to 'A || B'
(!GC_use_mach_handler_thread ||
(GC_use_mach_handler_thread GC_mach_handler_thread != thread))) {
[Bug boehm-gc/66884] New: trunk/boehm-gc/cord/cordbscs.c:455: bad if ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66884 Bug ID: 66884 Summary: trunk/boehm-gc/cord/cordbscs.c:455: bad if ? Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: boehm-gc Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- [trunk/boehm-gc/cord/cordbscs.c:455]: (style) Checking if unsigned variable 'i' is less than zero. # ifndef __STDC__ if (i 0) ABORT(CORD_substr: second arg. negative); /* Possible only if both client and C implementation are buggy. */ /* But empirically this happens frequently. */ # endif but CORD CORD_substr(CORD x, size_t i, size_t n) Suggest code removal. It seems to be dead, and I don't think anyone still uses KR (ie pre ANSI) compilers anymore.
[Bug libgcc/66854] libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 --- Comment #5 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Wed Jul 15 17:15:37 2015 New Revision: 225843 URL: https://gcc.gnu.org/viewcvs?rev=225843root=gccview=rev Log: 2015-07-14 Michael Meissner meiss...@linux.vnet.ibm.com PR target/66854 * config/rs6000/rs6000.c (rs6000_pass_by_reference): Move test for null before IEEE 128-bit floating point support patch. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug tree-optimization/66875] entire for loop got eliminated at cddce2 tree-opt stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66875 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- You can try -Warray-bounds, but it has its own quirks... If you compile with -fsanitize=undefined you should get a run-time error when doing an out-of-bounds access. Closing.
[Bug middle-end/66877] New: [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect vect_recog_over_widening_pattern: detected 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66877 Bug ID: 66877 Summary: [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect vect_recog_over_widening_pattern: detected 2 Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: rguenther at suse dot de Target Milestone: --- Target: arm-none-eabi After https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00743.html I see this test fail on arm targets. Changing the scan-tree-dump-times to scan for only one occurrence makes the test pass
[Bug libgomp/65742] [5 Regression] Several libgomp.oacc-* failures after r221922.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|jules at gcc dot gnu.org |tschwinge at gcc dot gnu.org --- Comment #10 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Now also fixed on gcc-5-branch.
[Bug tree-optimization/66875] entire for loop got eliminated at cddce2 tree-opt stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66875 --- Comment #3 from Patrick S. patricksung at gmail dot com --- argh... my mistake to not check the termination condition is actually matching the size of the prot_short_str[] array. fixing that by properly calculating the array size would fix the compilation now. Thanks! But one more thing. Since the compiler can see the static size of the array, wouldn't it be possible to have a warning for possible access of array size out of bound?
[Bug preprocessor/66871] .incbin in .S files does not appear in automatically generated dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66871 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to David Woodhouse from comment #2) It would still be extremely useful for it to emit dependencies on those files which are actually included (after preprocessing). Otherwise we end up screwing around with preprocessing it and then looking for '.incbin' and generating the full set of dependencies manually. Which is horrid. How about you file a bug to the assembler (binutils) asking to produce a .d file with .incbin files? Or just post process the .s files and add it to the .d file.
[Bug middle-end/66877] [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect vect_recog_over_widening_pattern: detected 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66877 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-15 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look.
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249 --- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #19) Just for my understanding ... at which time does the modified expand pattern kick in? Before RA, during RA or after RA? It's a bit confusing, because operands[0] is already a hard-reg and operands[1] is supposed to be a pseudo ...
[Bug libgomp/65099] nvptx offloading: hard-coded 64-bit assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65099 --- Comment #2 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Author: tschwinge Date: Wed Jul 15 11:55:13 2015 New Revision: 225824 URL: https://gcc.gnu.org/viewcvs?rev=225824root=gccview=rev Log: [PR libgomp/65099] nvptx offloading: only 64-bit configurations are currently supported Backport trunk r225560: PR libgomp/65099 gcc/ * config/nvptx/mkoffload.c (main): Create an offload image only in 64-bit configurations. libgomp/ * plugin/plugin-nvptx.c (nvptx_get_num_devices): Return 0 if not in a 64-bit configuration. * testsuite/libgomp.oacc-c++/c++.exp: Don't attempt nvidia offloading testing if no such device is available. * testsuite/libgomp.oacc-c/c.exp: Likewise. * testsuite/libgomp.oacc-fortran/fortran.exp: Likewise. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/nvptx/mkoffload.c branches/gcc-5-branch/libgomp/ChangeLog branches/gcc-5-branch/libgomp/plugin/plugin-nvptx.c branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-c++/c++.exp branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-c/c.exp branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp
[Bug middle-end/66332] goacc/acc_on_device-2.c scan-rtl-dump-times expand testsuite failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66332 --- Comment #4 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Author: tschwinge Date: Wed Jul 15 11:55:00 2015 New Revision: 225822 URL: https://gcc.gnu.org/viewcvs?rev=225822root=gccview=rev Log: [PR libgomp/65742, PR middle-end/66332] OpenACC acc_on_device fixes Backport trunk r223801: PR libgomp/65742 gcc/ * builtins.c (expand_builtin_acc_on_device): Don't use open-coded sequence for !ACCEL_COMPILER. libgomp/ * oacc-init.c (plugin/plugin-host.h): Include. (acc_on_device): Check whether we're in an offloaded region for host_nonshm plugin. Don't use __builtin_acc_on_device. * plugin/plugin-host.c (GOMP_OFFLOAD_openacc_parallel): Set nonshm_exec flag in thread-local data. (GOMP_OFFLOAD_openacc_create_thread_data): Allocate thread-local data for host_nonshm plugin. (GOMP_OFFLOAD_openacc_destroy_thread_data): Free thread-local data for host_nonshm plugin. * plugin/plugin-host.h: New. Mark parameters with ATTRIBUTE_UNUSED Backport trunk r223805: * builtins.c (expand_builtin_acc_on_device): Mark parameters with ATTRIBUTE_UNUSED. [PR libgomp/65742, PR middle-end/66332] XFAIL acc_on_device compile-time evaluation The OpenACC 2.0a specification mandates differently, but we currently do get a library call in the host code. Backport trunk r224028: PR libgomp/65742 PR middle-end/66332 gcc/testsuite/ * c-c++-common/goacc/acc_on_device-2.c: XFAIL for C, too. Added: branches/gcc-5-branch/libgomp/plugin/plugin-host.h Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/builtins.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c branches/gcc-5-branch/libgomp/ChangeLog branches/gcc-5-branch/libgomp/oacc-init.c branches/gcc-5-branch/libgomp/plugin/plugin-host.c
[Bug libgomp/65742] [5 Regression] Several libgomp.oacc-* failures after r221922.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742 --- Comment #9 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Author: tschwinge Date: Wed Jul 15 11:55:00 2015 New Revision: 225822 URL: https://gcc.gnu.org/viewcvs?rev=225822root=gccview=rev Log: [PR libgomp/65742, PR middle-end/66332] OpenACC acc_on_device fixes Backport trunk r223801: PR libgomp/65742 gcc/ * builtins.c (expand_builtin_acc_on_device): Don't use open-coded sequence for !ACCEL_COMPILER. libgomp/ * oacc-init.c (plugin/plugin-host.h): Include. (acc_on_device): Check whether we're in an offloaded region for host_nonshm plugin. Don't use __builtin_acc_on_device. * plugin/plugin-host.c (GOMP_OFFLOAD_openacc_parallel): Set nonshm_exec flag in thread-local data. (GOMP_OFFLOAD_openacc_create_thread_data): Allocate thread-local data for host_nonshm plugin. (GOMP_OFFLOAD_openacc_destroy_thread_data): Free thread-local data for host_nonshm plugin. * plugin/plugin-host.h: New. Mark parameters with ATTRIBUTE_UNUSED Backport trunk r223805: * builtins.c (expand_builtin_acc_on_device): Mark parameters with ATTRIBUTE_UNUSED. [PR libgomp/65742, PR middle-end/66332] XFAIL acc_on_device compile-time evaluation The OpenACC 2.0a specification mandates differently, but we currently do get a library call in the host code. Backport trunk r224028: PR libgomp/65742 PR middle-end/66332 gcc/testsuite/ * c-c++-common/goacc/acc_on_device-2.c: XFAIL for C, too. Added: branches/gcc-5-branch/libgomp/plugin/plugin-host.h Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/builtins.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c branches/gcc-5-branch/libgomp/ChangeLog branches/gcc-5-branch/libgomp/oacc-init.c branches/gcc-5-branch/libgomp/plugin/plugin-host.c
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249 --- Comment #21 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #20) Just for my understanding ... at which time does the modified expand pattern kick in? Before RA, during RA or after RA? It's a bit confusing, because operands[0] is already a hard-reg and operands[1] is supposed to be a pseudo ... Before RA, during expand phase. It's generated by function.c: expand_function_end with emit_move_insn (crtl-return_rtx, DECL_RTL (DECL_RESULT (current_function_decl)) essentially. In this case, crtl-return_rtx is (reg/i:DI 0 r0).
[Bug tree-optimization/66846] parloops does not always mark loops for fixup if needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66846 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #2 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01328.html
[Bug rtl-optimization/66890] function splitting only works with profile feedback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66890 --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org --- The problem seems to be that bb-reorder.c:find_rarely_executed_basic_blocks_and_crossing_edges returns no edges without profile feedback, which prevents generation of a section split note.
[Bug target/66882] New: [4.9 Regression] ICE (Segmentation fault) on powerpc64-linux-gnu building libjava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66882 Bug ID: 66882 Summary: [4.9 Regression] ICE (Segmentation fault) on powerpc64-linux-gnu building libjava Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- r225765 for powerpc64-linux-gnu on the 4.9 branch fails to build in libjava, while r225135 succeeded. both powerpc-linux-gnu (no libjava biarch) and powerpc64le-linux-gnu succeed to build. /«PKGBUILDDIR»/src/libjava/classpath/javax/swing/plaf/basic/BasicRadioButtonUI.java:132:0: internal compiler error: Segmentation fault AbstractButton b = (AbstractButton) c; ^ 0x105130eb crash_signal ../../src/gcc/toplev.c:337 0x105d5c1c get_use_from_ptr ../../src/gcc/tree-ssa-operands.h:112 0x105d5c1c op_iter_next_tree ../../src/gcc/ssa-iterators.h:544 0x105d5c1c likely_value ../../src/gcc/tree-ssa-ccp.c:639 0x105d5c1c evaluate_stmt ../../src/gcc/tree-ssa-ccp.c:1596 0x105d8057 visit_assignment ../../src/gcc/tree-ssa-ccp.c:2158 0x10657833 simulate_stmt ../../src/gcc/tree-ssa-propagate.c:329 0x10657f2f simulate_block ../../src/gcc/tree-ssa-propagate.c:452 0x10657f2f ssa_propagate(ssa_prop_result (*)(gimple_statement_base*, edge_def**, tree_node**), ssa_prop_result (*)(gimple_statement_base*)) ../../src/gcc/tree-ssa-propagate.c:869 0x105d2733 do_ssa_ccp ../../src/gcc/tree-ssa-ccp.c:2282 0x105d2733 execute ../../src/gcc/tree-ssa-ccp.c:2325 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions. Makefile:10645: recipe for target 'javax/swing/plaf/basic.lo' failed make[5]: *** [javax/swing/plaf/basic.lo] Error 1 gcc configured with -v --with-pkgversion='Debian 4.9.3-2' --with-bugurl='file:///usr/share/doc/gcc-4.9/README.Bugs' --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libsanitizer --disable-libquadmath --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-4.9-ppc64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-ppc64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-ppc64 --with-arch-directory=ppc64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-secureplt --disable-softfloat --enable-targets=powerpc64-linux,powerpc-linux --enable-multiarch --with-long-double-128 --enable-multilib --enable-checking=release --build=powerpc64-linux-gnu --host=powerpc64-linux-gnu --target=powerpc64-linux-gnu
[Bug rtl-optimization/50677] volatile forces load into register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- Can we make init_recog_no_volatile processor a target hook so that it can be disabled for x86?
[Bug libgcc/66883] New: config/epiphany/udivsi3-float.c:52: bad if test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66883 Bug ID: 66883 Summary: config/epiphany/udivsi3-float.c:52: bad if test ? Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- trunk/libgcc/config/epiphany/udivsi3-float.c:52]: (style) Checking if unsigned variable 'a' is less than zero. if (a 0) u0.i = (a 8) - 0x0080 + 0x3f80 + (31 23); but unsigned int __udivsi3 (unsigned int a, unsigned int b)
[Bug other/66887] New: trunk/libmpx/mpxrt/mpxrt.c:158: possible performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66887 Bug ID: 66887 Summary: trunk/libmpx/mpxrt/mpxrt.c:158: possible performance problem Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- [trunk/libmpx/mpxrt/mpxrt.c:159]: (performance) Buffer 'buffer' is being written before its old content has been used. Source code is memset (buffer, 0, sizeof (buffer)); memcpy (buffer, (uint8_t *)uctxt-uc_mcontext.fpregs + XSAVE_OFFSET_IN_FPMEM, sizeof (struct xsave_struct)); Maybe something like memcpy (buffer, (uint8_t *)uctxt-uc_mcontext.fpregs + XSAVE_OFFSET_IN_FPMEM, sizeof (struct xsave_struct)); memset (buffer[sizeof (struct xsave_struct))], 0, sizeof (buffer) - sizeof (struct xsave_struct)) );
[Bug target/66885] trunk/gcc/config/mcore/mcore.c:1656: poor code order ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66885 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- The second condition is *not* always false.
[Bug target/66885] trunk/gcc/config/mcore/mcore.c:1656: poor code order ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66885
--- Comment #2 from David Binderman dcb314 at hotmail dot com ---
(In reply to Andreas Schwab from comment #1)
The second condition is *not* always false.
After some further thought, agreed.
Would this be more clearly coded as
switch (bytes % 4)
{
case 1:
case 3:
max = 16;
break;
case 2:
max = 32;
break;
case 0:
max = 64;
break;
}
or maybe even faster, some table lookup.
[Bug tree-optimization/66873] fortran variant of outer-1.c not parallelized by autopar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66873 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #8 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01332.html
[Bug c++/66888] New: Compiler accepting ill-formed program trying to define a struct via using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66888 Bug ID: 66888 Summary: Compiler accepting ill-formed program trying to define a struct via using-declaration Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: anders.granlund.0 at gmail dot com Target Milestone: --- Created attachment 35990 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35990action=edit prog.cc used in the command line The attached program is ill-formed according to the c++ standard. This by the following clauses in the c++ standard: * [class]p11 ( http://eel.is/c++draft/class#11 ): Note especially the sentence i.e., not merely inherited or introduced by a using-declaration * [dcl.meaning]p1 ( http://eel.is/c++draft/dcl.meaning#1 ): Not especially the sentence the member shall not merely have been introduced by a using-declaration in the scope of the class or namespace nominated by the nested-name-specifier of the declarator-id. When compiling with the following command line no error message is given: gcc prog.cc The expected behaviour is to get an error message since the program is ill-formed. Output from gcc -v is: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --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-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-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 --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 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
[Bug c++/66889] Accepting ill-formed program trying to define a struct via using-directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66889 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Related to PR66879 (maybe a dup)
[Bug c++/66888] Compiler accepting ill-formed program trying to define a struct via using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66888 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Related to PR66879 (maybe a dup)
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249 --- Comment #23 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Thu Jul 16 00:48:33 2015 New Revision: 225856 URL: https://gcc.gnu.org/viewcvs?rev=225856root=gccview=rev Log: PR target/65249 * config/sh/sh.md (movdi): Split simple reg move to two movsi when the destination is R0 so as to lower R0-register pressure. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug c++/66889] New: Accepting ill-formed program trying to define a struct via using-directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66889 Bug ID: 66889 Summary: Accepting ill-formed program trying to define a struct via using-directive Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: anders.granlund.0 at gmail dot com Target Milestone: --- Created attachment 35991 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35991action=edit prog.cc used in the command line Compile the attached program with the following command line: gcc prog.cc No error output is given. The expected behaviour is to get an error. This because the program is ill-formed according to the clause [class]p11 of the c++ standard: http://eel.is/c++draft/class#11 Output for gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --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-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-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 --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 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3 or -miamcu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626 --- Comment #22 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to H.J. Lu from comment #20) Testcase in comment #1 still fails with r225789. Sorry, I did not check the 1st test. I checked only the 2nd one which has a different reason for failure than the 1st one. I've been working on the 1st test fialure. The patch will be more complicated. I hope to fix it tomorrow.
[Bug target/66866] [miscompile] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866 --- Comment #8 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jul 15 22:20:17 2015 New Revision: 225852 URL: https://gcc.gnu.org/viewcvs?rev=225852root=gccview=rev Log: PR target/66866 * config/i386/i386-protos.h (ix86_expand_pextr): New prototype. * config/i386/i386.c (ix86_expand_pextr): New function. (ix86_expand_pinsr): Handle V1TI and TI modes. Call ix86_expand_pextr for non-lowpart subregs. * config/i386/i386.md (extzvmode): Expand with ix86_expand_pextr. (insvmode): Use SWI248 mode iterator. (insvmode_1): Ditto. testsuite/ChangeLog: PR target/66866 * g++.dg/pr66866.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr66866.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug target/66866] [4.9/5 Regression] incorrect load address on manual vector shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66866 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.9.4 Summary|[miscompile] incorrect load |[4.9/5 Regression] |address on manual vector|incorrect load address on |shuffle |manual vector shuffle --- Comment #9 from Uroš Bizjak ubizjak at gmail dot com --- Fixed in mainline. The reduced testcase now compiles to: _Z4shufDv2_x: .LFB0: .cfi_startproc vpextrw $4, %xmm0, %eax vpxor %xmm0, %xmm0, %xmm0 vpinsrw $5, %eax, %xmm0, %xmm0 ret Patch needs backports to release branches.
[Bug c++/66878] Segmentation fault when compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66878 --- Comment #3 from Anders Granlund anders.granlund.0 at gmail dot com --- The following bug that I also reported is related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66888
[Bug rtl-optimization/66890] New: function splitting only works with profile feedback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66890
Bug ID: 66890
Summary: function splitting only works with profile feedback
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
Consider this simple example:
volatile int count;
int main()
{
int i;
for (i = 0; i 10; i++) {
if (i == 999)
count *= 2;
count++;
}
}
The default EQ is unlikely heuristic in predict.* predicts that the if (i ==
999) is unlikely. So the tracer moves the count *= 2 basic block out of line to
preserve instruction cache.
gcc50 -O2 -S thotcold.c
movl$1, %edx
jmp .L2
.p2align 4,,10
.p2align 3
.L4:
addl$1, %edx
.L2:
cmpl$1000, %edx
movlcount(%rip), %eax
je .L6
addl$1, %eax
cmpl$10, %edx
movl%eax, count(%rip)
jne .L4
xorl%eax, %eax
ret
# out of line code
.L6:
addl%eax, %eax
movl%eax, count(%rip)
movlcount(%rip), %eax
addl$1, %eax
movl%eax, count(%rip)
jmp .L4
Now if we enable -freorder-blocks-and-partition I would expect it to be also
put into .text.unlikely to given even better cache layout. But that's what is
not happening. It generates the same code.
Only when I use actual profile feedback and -freorder-blocks-and-partition the
code actually ends up being in a separate section
(it also unrolled the loop, so the code looks a bit different)
gcc -O2 -fprofile-generate -freorder-blocks-and-partition thotcold.c
./a.out
gcc -O2 -fprofile-use -freorder-blocks-and-partition thotcold.c
...
.cfi_endproc
.section.text.unlikely
.cfi_startproc
.L55:
movlcount(%rip), %ecx
addl$1, %eax
addl$1, %ecx
cmpl$10, %eax
movl%ecx, count(%rip)
je .L6
cmpl$1, %edx
je .L5
cmpl$2, %edx
je .L28
cmpl$3, %edx
-freorder-blocks-and-partition should already use the extra section even
without profile feedback.
I tested some larger programs and without profile feedback the unlikely section
is always empty.
The heuristics in predict.* often work quite well and a lot of code would
benefit from moving cold code out of the way of the caches.
This would allow to use the option to improve frontend bound codes without
needing to do full profile feedback.
[Bug tree-optimization/66875] entire for loop got eliminated at cddce2 tree-opt stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66875 --- Comment #4 from Patrick S. patricksung at gmail dot com --- (In reply to Marek Polacek from comment #2) Yes, please try -fsanitize=undefined. This looks like an invalid. I am guessing this would allow the compiler to detect the loop is undefined and would generate warning? if in that case no new warning/error was generated.
[Bug c++/65091] decltype(~arg) fails for template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65091 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jul 15 14:13:22 2015 New Revision: 225831 URL: https://gcc.gnu.org/viewcvs?rev=225831root=gccview=rev Log: PR c++/65091 * parser.c (cp_parser_unqualified_id): Don't accept ~x in a template if there is no type x in scope. Added: trunk/gcc/testsuite/g++.dg/parse/dtor17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug sanitizer/66880] New: 'error: case label does not reduce to an integer constant' with -fsanitize=shift -std=gnu99.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66880
Bug ID: 66880
Summary: 'error: case label does not reduce to an integer
constant' with -fsanitize=shift -std=gnu99.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: chefmax at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
mpolacek at gcc dot gnu.org, ygribov at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
When compile this testcase with -fsanitize=shift -std=gnu99, such an error
happened:
$ cat test.c
int main (int argc, char **argv) {
switch (argc) {
case 0xEB 24: return 1;
case 1: return 2;
default: return 0;
}
}
$ ~/install/master/bin/gcc -fsanitize=undefined -std=gnu99 test.c
-static-libubsan
1.c: In function ‘main’:
1.c:3:5: error: case label does not reduce to an integer constant
case 0xEB 24: return 1;
^
max@max:/tmp$ ~/install/master/bin/gcc -fsanitize=shift -std=gnu99 1.c
-static-libubsan
1.c: In function ‘main’:
1.c:3:5: error: case label does not reduce to an integer constant
case 0xEB 24: return 1;
^
$ ~/install/master/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/max/install/master/bin/gcc
COLLECT_LTO_WRAPPER=/home/max/install/master/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/max/workspace/downloads/gcc/configure --enable-multilib
--enable-checking --target=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--prefix=/home/max/install/master --disable-bootstrap --enable-languages=c,c++
CFLAGS='-g -O0' CXXFLAGS='-g -O0'
Thread model: posix
gcc version 6.0.0 20150710 (experimental) (GCC)
This is caused by this:
Breakpoint 1, check_case_value (loc=7699, value=0x769712a8) at
/home/max/workspace/downloads/gcc/gcc/c-family/c-common.c:3620
3620 error_at (loc, case label does not reduce to an integer
constant);
(gdb) call debug_tree(value)
compound_expr 0x769712a8
type integer_type 0x7682e7e0 int public SI
size integer_cst 0x7682aee8 constant 32
unit size integer_cst 0x7682af00 constant 4
align 32 symtab 0 alias set -1 canonical type 0x7682e7e0 precision
32 min integer_cst 0x7682aea0 -2147483648 max integer_cst 0x7682aeb8
2147483647
pointer_to_this pointer_type 0x76848930
side-effects
arg 0 call_expr 0x76833a68
type void_type 0x76848150 void VOID
align 8 symtab 0 alias set -1 canonical type 0x76848150
pointer_to_this pointer_type 0x768482a0
side-effects
fn addr_expr 0x7696fd20 type pointer_type 0x76987a80
constant arg 0 function_decl 0x769202a0
__builtin___ubsan_handle_shift_out_of_bounds
arg 0 addr_expr 0x7696fd00 type pointer_type 0x769879d8
constant arg 0 var_decl 0x76836cf0 *.Lubsan_data0
1.c:3:15
arg 1 integer_cst 0x76970a80 constant 235
arg 2 integer_cst 0x76970a68 constant 24
arg 1 integer_cst 0x76970840 type integer_type 0x7682e7e0 int
constant -352321536
1.c:3:15
(gdb)
[Bug sanitizer/66880] 'error: case label does not reduce to an integer constant' with -fsanitize=shift -std=gnu99.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66880 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, the problem is that a case label value needs to be an integral constant expression. 0xEB 24 contains an overflow so we weren't able to fold it, thus we emit the __builtin___ubsan_handle_shift_out_of_bounds call -- and that is rejected by the C FE later on. I'm not sure how to make this better.
[Bug c++/66879] New: Error message when defining a member function inside a class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
Bug ID: 66879
Summary: Error message when defining a member function inside a
class definition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Created attachment 35988
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35988action=edit
prog.cc used in the command line
Compile the attached program with the following command line:
gcc prog.cc
The output is the following:
prog.cc:6:22: error: definition of ‘void A::f()’ is not in namespace enclosing
‘A’ [-fpermissive]
class A { void f() {} };
^
The expected behaviour is not to get this error message. The error message seem
to suggest that the compiler thinks that the program violates [class.mfct]/2
where one sentence says:
A member function definition that appears outside of the class definition
shall appear in a namespace scope enclosing the class definition.
Observe however that the member function definition in the given program is
made inside the class definition.
Note that if we remove the member function definition in the given program it
compiles without errors.
Output of gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--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-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-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 --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 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
[Bug sanitizer/66880] 'error: case label does not reduce to an integer constant' with -fsanitize=shift -std=gnu99.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66880 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- And why do you think it is wrong? 0xEB 24 is undefined behavior in C99 I think.
[Bug c++/66857] [5/6 Regression] Reference not bound to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66857 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Patrick Palka from comment #4) Reverting the change made to ocp_convert in r217814 fixes it: diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c index 13bc1f7..6d4bd9a 100644 --- a/gcc/cp/cvt.c +++ b/gcc/cp/cvt.c @@ -687,7 +687,8 @@ ocp_convert (tree type, tree expr, int convtype, int flags, } /* FIXME remove when moving to c_fully_fold model. */ - e = scalar_constant_value (e); + if (!CLASS_TYPE_P (type)) +e = scalar_constant_value (e); if (error_operand_p (e)) return error_mark_node; This fix is OK.
[Bug sanitizer/66880] 'error: case label does not reduce to an integer constant' with -fsanitize=shift -std=gnu99.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66880 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Yes; it's not UB only in C89. (My warning -Wshift-overflow would warn about this as well, but it's not in yet.)
[Bug sanitizer/66880] 'error: case label does not reduce to an integer constant' with -fsanitize=shift -std=gnu99.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66880 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- I think Max means that error message may sound a bit unexpected as it mentions nothing about UBSan.
[Bug rtl-optimization/66865] [6 Regression] wine64 segfaults from gcc in trunk (r225757) (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865 --- Comment #11 from marcus at jet dot franken.de --- Created attachment 35984 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35984action=edit 707.c delta reduced testcase. gcc -O2 -fPIC -c 707.c
[Bug c++/66879] Error message when defining a member function inside a class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879 --- Comment #3 from Anders Granlund anders.granlund.0 at gmail dot com --- Thanks for the comments! Now I remember the following bug report that I sent to clang: https://llvm.org/bugs/show_bug.cgi?id=24030 That bug has now been confirmed and fixed in clang, so yes this is the actual bug and it should be fixed in gcc also.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #8 from boger at us dot ibm.com --- Created attachment 35989 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35989action=edit Clean up checks for flag_split_stack and attribute no_split_stack Made the change related to Alan's comment for my patch to rs6000.c.
[Bug middle-end/66881] New: Possibly inefficient std::atomicint codegen on x86 for simple arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881
Bug ID: 66881
Summary: Possibly inefficient std::atomicint codegen on x86
for simple arithmetic
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoeppe at google dot com
Target Milestone: ---
Consider these two simple versions of addition:
#include atomic
std::atomicint x;
int y;
void f(int a) {
x.store(x.load(std::memory_order_relaxed) + a, std::memory_order_relaxed);
}
void g(int a) {
y += a;
}
GCC generates the following assembly:
f(int):
mov eax, DWORD PTR x[rip]
add edi, eax
mov DWORD PTR x[rip], edi
ret
g(int):
add DWORD PTR y[rip], edi
ret
Now, it is clear to me that the correct atomic codegen for store() and load()
is mov, as it appears here, but why aren't the two consecutive operations not
folded into a single add? Aren't the semantics and the memory ordering the
same? x86 says that (most) reads and writes are strongly ordered; doesn't
that apply to the read and write produced by add, too?
(My original motivation came from a variant of this with floats, where the
non-atomic code executed noticeably faster, even though I would have expected
the two to produce the same machine code.)
[Bug c++/66879] Error message when defining a member function inside a class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-07-15
Version|unknown |6.0
Ever confirmed|0 |1
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
So confirming as accepts-invalid with this testcase:
class A;
namespace Y {
using ::A;
class A { };
}
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #9 from boger at us dot ibm.com --- (In reply to Andreas Schwab from comment #6) (past a few statements) Huh? @@ -158,10 +158,6 @@ go_langhook_init_options_struct (struct gcc_options *opts) @@ -295,6 +291,11 @@ go_langhook_post_options (const char **pfilename Sorry about that. Would you submit your change?
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249 --- Comment #22 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #21) Before RA, during expand phase. It's generated by function.c: expand_function_end with emit_move_insn (crtl-return_rtx, DECL_RTL (DECL_RESULT (current_function_decl)) essentially. In this case, crtl-return_rtx is (reg/i:DI 0 r0). Ah, I see. Thanks.
[Bug c++/66878] Segmentation fault when compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66878 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- This is infinite recursion in push_inner_scope_r - stack overflow.
[Bug c++/66878] New: Segmentation fault when compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66878 Bug ID: 66878 Summary: Segmentation fault when compiling Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: anders.granlund.0 at gmail dot com Target Milestone: --- Created attachment 35987 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35987action=edit prog.cc used in the command line With the attached file the following command results in an internal compiler error: gcc prog.cc The output is: gcc: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions. Output for gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --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-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-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 --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 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
[Bug c++/66878] Segmentation fault when compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66878 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-15 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed even with 4.9/5/trunk.
[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #18 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jul 15 13:42:07 2015 New Revision: 225829 URL: https://gcc.gnu.org/viewcvs?rev=225829root=gccview=rev Log: PR target/58066 * config/i386/i386.md (*tls_global_dynamic_64_mode): Depend on SP_REG. (*tls_local_dynamic_base_64_mode): Ditto. (*tls_local_dynamic_base_64_largepic): Ditto. (tls_global_dynamic_64_mode): Update expander pattern. (tls_local_dynamic_base_64_mode): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug c++/66879] Error message when defining a member function inside a class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Anders Granlund from comment #0)
Note that if we remove the member function definition in the given program
it compiles without errors.
I think that's the real bug. G++ should not accept this program:
class A;
namespace Y {
using ::A;
class A { };
}
int main()
{
Y::A a;
::A* p = a;
}
Clang rejects it because Y::A in main() is ambiguous, but EDG rejects it with
the same error as for the original testcase:
a.cc, line 5: error: class A cannot be defined in the current scope
class A { };
^
I believe EDG is right to reject that class-specifier because the class name A
has already been introduced into that scope, and it cannot be a definition of
::A because it doesn't use a nested-name-specifier and it isn't in the
namespace (or an enclosing namespace) of ::A.
[Bug c++/66879] Error message when defining a member function inside a class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Clang compiles it OK, but EDG says:
a.cc, line 5: error: class A cannot be defined in the current scope
class A { void f() {} };
This seems similar to the G++ error, which is due to the name A referring to
::A, which should be defined in the global scope.
I'm not sure whether the definition of Y::A should be an error, or (as Clang
thinks) should declare a new type, which cannot be referred to due to the
ambiguity caused by the using-declaration.
[Bug rtl-optimization/66556] Wrong code-generation for armv7-a big-endian at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66556 --- Comment #4 from renlin at gcc dot gnu.org --- Author: renlin Date: Wed Jul 15 15:13:36 2015 New Revision: 225835 URL: https://gcc.gnu.org/viewcvs?rev=225835root=gccview=rev Log: [PATCH]Fix PR66556. Don't drop side-effect in simplify_const_relational_operation function. gcc/ Backport from mainline. 2015-07-13 Renlin Li renlin...@arm.com PR rtl/66556 * simplify-rtx.c (simplify_const_relational_operation): Add side_effects_p checks. gcc/testsuite/ Backport from mainline. 2015-07-13 Renlin Li renlin...@arm.com PR rtl/66556 * gcc.c-torture/execute/pr66556.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr66556.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/simplify-rtx.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530 Bug 65530 depends on bug 66734, which changed state. Bug 66734 Summary: Many MPX tests are skipped https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66734 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug testsuite/66734] Many MPX tests are skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66734 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2015-07-15 Depends on||66737 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- MPX tests are still skipped on Linux/ia32 due to PR 66737: spawn -ignore SIGHUP /export/gnu/import/git/gcc-test-ia32corei7/bld/gcc/xgcc -B/export/gnu/import/git/gcc-test-ia32corei7/bld/gcc/ mpx30359.c -B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/ -B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/mpxrt -L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/mpxrt/.libs -B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/ -B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/mpxwrap -L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -fcheck-pointer-bounds -mmpx -o mpx30359.exe^M /usr/local32/bin/ld: warning: -z bndplt ignored.^M output is: /usr/local32/bin/ld: warning: -z bndplt ignored.^M UNSUPPORTED: gcc.dg/lto/pr66221_0.c Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66737 [Bug 66737] ld: warning: -z bndplt ignored
[Bug middle-end/66881] Possibly inefficient std::atomicint codegen on x86 for simple arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Dup of PR 50677?
[Bug middle-end/66881] Possibly inefficient std::atomicint codegen on x86 for simple arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881 --- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com --- (In reply to H.J. Lu from comment #1) Dup of PR 50677? Well, this report has no volatiles in it, so perhaps not?
[Bug middle-end/66881] Possibly inefficient std::atomicint codegen on x86 for simple arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Ville Voutilainen from comment #2) (In reply to H.J. Lu from comment #1) Dup of PR 50677? Well, this report has no volatiles in it, so perhaps not? Can you change init_recog_no_volatile to try it out?
[Bug rtl-optimization/50677] volatile forces load into register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||tkoeppe at google dot com --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- *** Bug 66881 has been marked as a duplicate of this bug. ***
[Bug middle-end/66881] Possibly inefficient std::atomicint codegen on x86 for simple arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- Dup.
