[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- Relocation problems with ifunc resolvers come about due to the fact that ifunc resolvers run at the same time other relocations are being processed. So.. 1) If the resolver runs before its code/data has been relocated, the resolver won't run correctly. 2) If the object requires text relocations then the text segment will be set read/write, but this makes it non-exec so any attempt to run an ifunc resolver will result in a segfault. (1) is fixed for leaf function resolvers called from within the same object (shared lib or executable), as the linker sorts ifunc relocs last. You will need to know the order in which an executable and its shared libraries are relocated by ld.so if you want to call a non-local resolver, or when the resolver itself makes non-local calls to functions that need their code/data relocating. Generally, don't do that. By inspection, getauxval loads values from the TOC/GOT, so it does need relocating, but if ld.so always relocates libc.so first then you might be OK calling getauxval.. I don't know enough about ld.so to answer that detail. And, oh yeah, provided the user doesn't override libc.so getauxval with their own version. (2) will give you an error/warning at link time.
[Bug driver/70936] [6/7/8 Regression] Hard-coded C++ header paths and relocation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 Cory Cohen changed: What|Removed |Added CC||cfcohen at verizon dot net --- Comment #15 from Cory Cohen --- In my case, the bug was caused by yaml-cpp-config.cmake setting the include directory to: /usr/lib/x86_64-linux-gnu/cmake/yaml-cpp/../../../../include aka /usr/include And then my Makefile specifying -isystem for that path. It looks like there might be a lack of path normalization... My GCC: gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406 from Kubuntu 17.04 I hope that helps.
[Bug libfortran/81195] SPEC CPU2017 621.wrf_s failure with 40+ openmp threads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81195 --- Comment #1 from Jim Wilson --- Created attachment 41623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41623&action=edit patch to make wrf_s work
[Bug libfortran/81195] New: SPEC CPU2017 621.wrf_s failure with 40+ openmp threads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81195 Bug ID: 81195 Summary: SPEC CPU2017 621.wrf_s failure with 40+ openmp threads Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: wilson at gcc dot gnu.org Target Milestone: --- I'm seeing many different kinds of failures when running a wrf_s binary compiled with gcc mainline. Double free aborts. Segfaults. Fortran runtime error: End of file. Etc. This uses openmp, and I'm running on an aarch64 machine with over 40 processors, using over 40 threads. Debugging, I tracked it down to a problem in libgfortran/io/unit.c There is a stack, newunit_stack, used to hold malloc structures not currently in use, apparently to avoid lots of malloc/free calls. The code locks this stack when pushing. However, it does not lock the stack when popping. If multiple threads try to pop at the same time, they can end up using the same structure, and then bad things happen. I have confirmed this behavior in gdb. The more threads you have, the more likely you run into the problem. wrf_s works if I add code to lock newunit_stack when popping. We also need to lock around uses of newunit_tos. I'm not sure if my patch is the best solution though. I haven't used Fortran in 30+ years, so I don't know how to write a testcase. GCC 7 appears to have the same code, so may have the same problem. I haven't tried to reproduce with gcc 7.
[Bug c++/79056] [7/8 Regression] [C++17] ICE with broken deduction guide / broken template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79056 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Jun 23 23:30:01 2017 New Revision: 249615 URL: https://gcc.gnu.org/viewcvs?rev=249615&root=gcc&view=rev Log: PR c++/79056 - C++17 ICE with invalid template syntax. * parser.c (cp_parser_simple_type_specifier): Don't assume that type is a TYPE_DECL. (cp_parser_check_for_invalid_template_id): Handle TYPE_DECL. * pt.c (template_placeholder_p): New. * cp-tree.h: Declare it. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/parse/template28.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/cp-tree.h branches/gcc-7-branch/gcc/cp/parser.c branches/gcc-7-branch/gcc/cp/pt.c
[Bug c++/79056] [7/8 Regression] [C++17] ICE with broken deduction guide / broken template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79056 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Jun 23 23:30:01 2017 New Revision: 249615 URL: https://gcc.gnu.org/viewcvs?rev=249615&root=gcc&view=rev Log: PR c++/79056 - C++17 ICE with invalid template syntax. * parser.c (cp_parser_simple_type_specifier): Don't assume that type is a TYPE_DECL. (cp_parser_check_for_invalid_template_id): Handle TYPE_DECL. * pt.c (template_placeholder_p): New. * cp-tree.h: Declare it. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/parse/template28.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/cp-tree.h branches/gcc-7-branch/gcc/cp/parser.c branches/gcc-7-branch/gcc/cp/pt.c
[Bug c++/79056] [7/8 Regression] [C++17] ICE with broken deduction guide / broken template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79056 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Jun 23 23:29:51 2017 New Revision: 249614 URL: https://gcc.gnu.org/viewcvs?rev=249614&root=gcc&view=rev Log: PR c++/79056 - C++17 ICE with invalid template syntax. * parser.c (cp_parser_simple_type_specifier): Don't assume that type is a TYPE_DECL. (cp_parser_check_for_invalid_template_id): Handle TYPE_DECL. * pt.c (template_placeholder_p): New. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/parse/template28.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c
[Bug c++/79056] [7/8 Regression] [C++17] ICE with broken deduction guide / broken template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79056 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Jun 23 23:29:51 2017 New Revision: 249614 URL: https://gcc.gnu.org/viewcvs?rev=249614&root=gcc&view=rev Log: PR c++/79056 - C++17 ICE with invalid template syntax. * parser.c (cp_parser_simple_type_specifier): Don't assume that type is a TYPE_DECL. (cp_parser_check_for_invalid_template_id): Handle TYPE_DECL. * pt.c (template_placeholder_p): New. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/parse/template28.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Jun 23 23:30:01 2017 New Revision: 249615 URL: https://gcc.gnu.org/viewcvs?rev=249615&root=gcc&view=rev Log: PR c++/79056 - C++17 ICE with invalid template syntax. * parser.c (cp_parser_simple_type_specifier): Don't assume that type is a TYPE_DECL. (cp_parser_check_for_invalid_template_id): Handle TYPE_DECL. * pt.c (template_placeholder_p): New. * cp-tree.h: Declare it. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/parse/template28.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/cp-tree.h branches/gcc-7-branch/gcc/cp/parser.c branches/gcc-7-branch/gcc/cp/pt.c
[Bug c++/81182] result of ‘operator->()’ yields non-pointer result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81182 --- Comment #2 from bartek 'basz' szurgot --- looks like the problem is gone in GCC-7.1.
[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193 --- Comment #2 from Michael Meissner --- One other possibility is to just remove the code that checks TARGET_LIBC_PROVIDES_HWCAP_IN_TCB, given that when we use it there is a reference to __parse_hwcap_and_convert_at_platform in the code. That won't be satisified unless you have a new enough glibc. Though it may be friendlier to warn the user if GCC wasn't configured to use the newer glibc.
[Bug middle-end/79794] unnecessary copy from target to target results in poor code for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79794 --- Comment #4 from Jim Wilson --- Author: wilson Date: Fri Jun 23 21:01:32 2017 New Revision: 249612 URL: https://gcc.gnu.org/viewcvs?rev=249612&root=gcc&view=rev Log: Testcase for FSF GCC bug 79794. gcc/testsuite/ PR middle-end/79794 * gcc.target/aarch64/pr79794.c: New. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr79794.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193 Peter Bergner changed: What|Removed |Added CC||amodra at gcc dot gnu.org --- Comment #1 from Peter Bergner --- I think 1) is doable, but I think there might be a problem with 2). I seem to recall Alan mentioning that we have to be careful generating relocations in ifunc resolver functions and calling getauxval() would definitely generate one. Alan, can you comment on what the issue is and whether it would be safe to call getauxval() in an ifunc resolver?
[Bug rtl-optimization/81194] ICE during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194 --- Comment #1 from Marc Mutz --- $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/d/gcc/trunk --enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++ : (reconfigured) ../gcc/configure --prefix=/d/gcc/trunk --enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++ --enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion Thread model: posix gcc version 8.0.0 20170623 (experimental) (GCC)
[Bug rtl-optimization/81194] New: ICE during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81194
Bug ID: 81194
Summary: ICE during RTL pass: expand
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marc.mutz at kdab dot com
Target Milestone: ---
Created attachment 41622
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41622&action=edit
compressed preprocessed source
during RTL pass: expand
In file included from
/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0/QtQml/private/qv4isel_util_p.h:1:0,
from
/home/marc/Qt/qt5/qtdeclarative/src/qml/jit/qv4isel_masm_p.h:56,
from
/home/marc/Qt/qt5/qtdeclarative/src/qml/jit/qv4isel_masm.cpp:40:
/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0/QtQml/private/../../../../../../../qt5/qtdeclarative/src/qml/compiler/qv4isel_util_p.h:
In member function ‘void QV4::JIT::InstructionSelection::run(int)
[with JITAssembler =
QV4::JIT::Assembler >]’:
/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0/QtQml/private/../../../../../../../qt5/qtdeclarative/src/qml/compiler/qv4isel_util_p.h:215:9:
internal compiler error: Segmentation fault
switch (s->stmtKind) {
^~
0xb21a6f crash_signal
../../gcc/gcc/toplev.c:338
0xb1391c expand_case(gswitch*)
../../gcc/gcc/stmt.c:1157
0x7bab17 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3569
0x7bab17 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3741
0x7bc2bf expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5745
0x7c171e execute
../../gcc/gcc/cfgexpand.c:6354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
[Bug target/81193] New: PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193 Bug ID: 81193 Summary: PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- If GCC is configured with a new glibc, it supports the __builtin_cpu_is and __builtin_cpu_supports built-in functions. However, if GCC is configured with an old glibc, the various __builtin_cpu* functions just return 0. GCC should do either: 1) Warn that __builtin_cpu_is/__builtin_cpu_supports is not supported; (or) 2) It should call getauxval and check the HWCAP/HWCAP2 bits directly. Perhaps there should be a helper function in libgcc that stands the built-in calls and the code generated for the built-in functions.
[Bug go/81183] -gdwarf-5: fatal error: unrecognized DWARF version in .debug_info at 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81183 --- Comment #1 from Ian Lance Taylor --- libbacktrace needs DWARF 5 support.
[Bug tree-optimization/81192] New: gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81192
Bug ID: 81192
Summary: gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk at
-Os on x86_64-linux-gnu in both 32- and 64-bit modes.
$ gcc-trunk --version
gcc-trunk (GCC) 8.0.0 20170623 (experimental) [trunk revision 249588]
$ gcc-trunk -Os abc.c
during GIMPLE pass: pre
abc.c: In function ‘fn2’:
abc.c:4:6: internal compiler error: Segmentation fault
void fn2() {
^~~
0xc8a4cf crash_signal
../../gcc/gcc/toplev.c:338
0xe56285 same_succ_flush_bb
../../gcc/gcc/tree-ssa-tail-merge.c:813
0xe580cb same_succ_flush_bbs
../../gcc/gcc/tree-ssa-tail-merge.c:828
0xe580cb update_worklist
../../gcc/gcc/tree-ssa-tail-merge.c:875
0xe580cb tail_merge_optimize(unsigned int)
../../gcc/gcc/tree-ssa-tail-merge.c:1792
0xe06bf0 execute
../../gcc/gcc/tree-ssa-pre.c:5162
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ cat abc.c
unsigned a;
int b, c;
int(fn1)(int p1, int p2) { return p1 > 2147483647 - p2 ? p1 : p1 + p2; }
void fn2() {
int j;
a = 30;
for (; a;)
for (; c; b = fn1(j, 1))
;
}
[Bug target/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #17 from Dominik Schmidt --- I'm having issues to build our whole stack with gcc-6-branch. Working on it.
[Bug target/80510] Optimize Power7/power8 Altivec load/stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80510 --- Comment #8 from Michael Meissner --- Author: meissner Date: Fri Jun 23 18:25:10 2017 New Revision: 249607 URL: https://gcc.gnu.org/viewcvs?rev=249607&root=gcc&view=rev Log: [gcc] 2017-06-23 Michael Meissner PR target/80510 * config/rs6000/rs6000.md (ALTIVEC_DFORM): Do not allow DImode in 32-bit, since indexed is not valid for DImode. (mov_hardfloat32): Reorder ISA 2.07 load/stores before ISA 3.0 d-form load/stores to be the same as mov_hardfloat64. (define_peephole2 for Altivec d-form load): Add 32-bit support. (define_peephole2 for Altivec d-form store): Likewise. [gcc/testsuite] 2017-06-23 Michael Meissner PR target/80510 * gcc.target/powerpc/pr80510-1.c: Allow test to run on 32-bit. * gcc.target/powerpc/pr80510-2.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr80510-1.c trunk/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
[Bug ipa/81185] Target clones support generates awkward names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81185 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Michael Meissner --- Fixed in subversion id 249605.
[Bug ipa/81185] Target clones support generates awkward names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81185 --- Comment #4 from Michael Meissner --- Author: meissner Date: Fri Jun 23 18:08:31 2017 New Revision: 249605 URL: https://gcc.gnu.org/viewcvs?rev=249605&root=gcc&view=rev Log: 2017-06-23 Michael Meissner PR ipa/81185 * multiple_target.c (create_dispatcher_calls): Only create the dispatcher call if the function is the default clone of a versioned function. Modified: trunk/gcc/ChangeLog trunk/gcc/multiple_target.c
[Bug middle-end/80902] A problem in expand_builtin_atomic_fetch_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80902 --- Comment #1 from Segher Boessenkool --- Author: segher Date: Fri Jun 23 17:37:27 2017 New Revision: 249603 URL: https://gcc.gnu.org/viewcvs?rev=249603&root=gcc&view=rev Log: Fix expand_builtin_atomic_fetch_op for pre-op (PR80902) __atomic_add_fetch adds a value to some memory, and returns the result. If there is no direct support for this, expand_builtin_atomic_fetch_op is asked to implement this as __atomic_fetch_add (which returns the original value of the mem), followed by the addition. Now, the __atomic_add_fetch could have been a tail call, but we shouldn't perform the __atomic_fetch_add as a tail call: following code would not be executed, and in fact thrown away because there is a barrier after tail calls. This fixes it. PR middle-end/80902 * builtins.c (expand_builtin_atomic_fetch_op): If emitting code after a call, force the call to not be a tail call. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c
[Bug tree-optimization/81163] error: ‘snprintf’ output may be truncated before the last format character [-werror=format-truncation=] note: ‘snprintf’ output between 2 and 266 bytes into a destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81163 Martin Sebor changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #10 from Martin Sebor --- We don't need any more information to resolve the report (besides, what you attached appears incomplete or truncated and cannot be used to reproduce the warning anyway). As I explained in comment #2 the warning for the code is deliberate and the bug report is invalid. Please quit reopening it.
[Bug web/81191] New: `-fsplit-paths` is listed as `-O2`instead of `-O3` flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81191 Bug ID: 81191 Summary: `-fsplit-paths` is listed as `-O2`instead of `-O3` flag Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: glen56 at Rcpt dot at Target Milestone: --- https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html `-fsplit-paths` flag is listed as a `-O3`-flag side-effect. However, going at the actual decleration of `-fsplit-paths`, it says that it `is enabled by default at -O2 and above`. Searching the webpage, it is only listed twice (once in `-O3` and once in it's explaination). Please disambiguate this reference
[Bug libstdc++/81190] std::optional doesn't compile with containers that have noncopyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81190 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |RESOLVED Known to work||8.0 Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- This is a dup of PR 80654 which was fixed on trunk by r248153. *** This bug has been marked as a duplicate of bug 80654 ***
[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654 Jonathan Wakely changed: What|Removed |Added CC||lyberta at lyberta dot net --- Comment #4 from Jonathan Wakely --- *** Bug 81190 has been marked as a duplicate of this bug. ***
[Bug libstdc++/81190] New: std::optional doesn't compile with containers that have noncopyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81190
Bug ID: 81190
Summary: std::optional doesn't compile with containers that
have noncopyable types
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lyberta at lyberta dot net
Target Milestone: ---
The following code will compile perfectly with std::experimental::optional but
will produce compiler errors with std::optional:
#include
#include
#include
#include
class Foo
{
public:
Foo(std::unique_ptr a)
{
m1.emplace(42, std::move(a));
}
private:
std::map> m1;
};
int main()
{
std::optional opt;
opt.emplace(std::make_unique(42));
opt = std::nullopt;
}
[Bug c++/81182] result of ‘operator->()’ yields non-pointer result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81182
--- Comment #1 from Jonathan Wakely ---
Reduced:
struct S
{
int i;
};
template
struct T
{
auto operator->() { return &s; }
S s;
};
template
void problem(T& t)
{
t->i;
}
[Bug testsuite/81179] [8 regression] gcc.dg/vect/pr65947-9.c and gcc.dg/vect/pr65947-14.c fail starting with r249553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81179 --- Comment #3 from Richard Biener --- Created attachment 41621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41621&action=edit patch Patch that should fix the execute fail, but it's a quiet big hammer.
[Bug testsuite/81179] [8 regression] gcc.dg/vect/pr65947-9.c and gcc.dg/vect/pr65947-14.c fail starting with r249553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81179 Renlin Li changed: What|Removed |Added CC||renlin at gcc dot gnu.org --- Comment #2 from Renlin Li --- The same failures are observed on all arm and aarch64 targets. FAIL: gcc.dg/vect/pr65947-9.c -flto -ffat-lto-objects scan-tree-dump vect "loop size is greater than data size" FAIL: gcc.dg/vect/pr65947-9.c scan-tree-dump vect "loop size is greater than data size" FAIL: gcc.dg/vect/pr65947-14.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/pr65947-14.c execution test
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560 --- Comment #1 from Jonathan Wakely --- A related issue is that we decide on shared_ptr locking policy based on a dynamic property that can change between translation units according to -march: static const _Lock_policy __default_lock_policy = #ifdef __GTHREADS #if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \ && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4)) _S_atomic; #else _S_mutex; #endif #else _S_single; #endif This causes ABI changes when inconsistent -march values are used, e.g. when mixing i386 and i686, or armv5 and armv7 (e.g. PR 42734 and PR 67843). It would be better to fix the lock policy at configure-time, so it is a constant for a given build of libstdc++. If, for example, the library is configured for armv7 then the atomic lock policy will be used, and if user code is compiled with -march=armv5 it will still use the same policy, and will use the __atomic_add and __exchange_and_add library functions from libstdc++.so If the library is configured for armv5 it will use the mutex policy, and if user code is compiled with -march=armv7 it will still use the same policy. We might also want to add an option to override the default, so that the targets can opt to use the atomics, which will call the __atomic_add and __exchange_and_add functions in libstdc++.so which will use either functions in libatomic or the kernel helper routines in libgcc.
[Bug rtl-optimization/81174] bswap not recognized in |= statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81174
--- Comment #3 from Thomas Preud'homme ---
(In reply to Jakub Jelinek from comment #2)
> Simplified testcase:
> static inline unsigned
> bar (unsigned x)
> {
> return ((x & 0x00ff) << 24) | ((x & 0xff00) << 8)
>| ((x & 0x00ff) >> 8) | ((x & 0xff00) >> 24);
> }
>
> unsigned
> foo (unsigned p, unsigned q)
> {
> p &= ~0x180U;
> p |= bar ((q << 7) & 0x180U);
> return p;
> }
>
> The problem is that with |= instead of += the reassoc pass is invoked first
> and reassociates the many | operands and then the bswap pass can't recognize
> the pattern.
> So, either we should consider moving the bswap pass 6 passes earlier (i.e.
> before reassoc1), or if we want to catch that we'd need to be able to
> recognize | operands unrelated to the bswap pattern mixed with | operands
> related to that, and replace just the ones related to the bswap and leave
> the others in.
Two things need to happen for bswap to catch the byteswap in this testcase:
1) do some reassociation to keep expression involving a single source
2) look for byteswap by stopping at all level of the recursion.
Let me illustrate with the testcase reduced by Jakub. Here's the gimple I get
with this testcase before bswap:
foo (unsigned int p, unsigned int q)
{
unsigned int _1;
unsigned int _2;
unsigned int _7;
unsigned int _9;
unsigned int _10;
unsigned int _12;
unsigned int _13;
unsigned int _15;
unsigned int _17;
unsigned int _18;
unsigned int _19;
[100.00%]:
p_4 = p_3(D) & 0xFE7F;
_1 = q_5(D) << 7;
_2 = _1 & 0x0180;
_7 = _2 << 24;
_9 = _2 << 8;
_10 = _9 & 0x00FF;
_12 = _2 >> 8;
_13 = _12 & 0xFF00;
_15 = _2 >> 24;
_17 = _7 | _15;
_18 = p_4 | _17;
_19 = _10 | _18;
p_8 = _13 | _19;
return p_8;
}
1) is needed to ignore expressions based on p when looking at the statement
defining p_8. Currently because p_8 ORs _13 (based on q) and _19 (based on p
and q) the match would fail. Similarly for _19 and _18. Then when looking at
_17 some statements would be missing to get a byteswap. So it would be
necessary to start at p_8 but realize that | is associative and thus
reassociate by only following expressions based on q. bswap need to be extended
so that the analysis for one statement could return several results (here one
for the expression based on p and one for the expression based on q) as well as
the operation that links these results (OR).
2) is needed to stop once statement defining _2 is reached. Currently bswap
would continue to recurse through _1 but due to the bitwise AND the pattern
would not be a byteswap of q and the match would fail. Some form of memoization
would be needed to not make this expensive.
[Bug c++/65775] Late-specified return type bypasses return type checks (qualified, function, array)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65775 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |8.0 --- Comment #2 from Paolo Carlini --- Mine.
[Bug tree-optimization/81175] [7/8 Regression] EXC_BAD_ACCESS in ::slpeel_duplicate_current_defs_from_edges(edge, edge, edge, edge) at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81175 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* --- Comment #3 from Richard Biener --- #5 0x012c72c0 in slpeel_duplicate_current_defs_from_edges ( from= 75)>, to= 67)>) at /space/rguenther/src/svn/gcc-7-branch/gcc/tree-vect-loop-manip.c:353 353 get_current_def (PHI_ARG_DEF_FROM_EDGE (from_phi, from))); (gdb) l 348 349 gphi *from_phi = get_virtual_phi (from->dest); 350 gphi *to_phi = get_virtual_phi (to->dest); 351 if (from_phi) 352 set_current_def (PHI_ARG_DEF_FROM_EDGE (to_phi, to), 353 get_current_def (PHI_ARG_DEF_FROM_EDGE (from_phi, from))); 354 } 355 356 357 /* Given LOOP this function generates a new copy of it and puts it (gdb) p from_phi $1 = (gphi *) 0x766d3b00 (gdb) p to_phi $2 = (gphi *) 0x0 ok, so that's unexpected... As we do the peeling from the non-ifconverted copy we have a virtual loop-closed PHI for the scalar loop but not for the to be vectorized loop. For some reason. Looks like update_ssa done by vect_loop_versioning produces that. Ah, and that is because we vectorize gathers with a x86_64 builtin that has a VDEF ... (ISTR a bug about that).
[Bug target/81170] powerpc*-linux --enable-default-pie chooses incorrect startup files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81170 Alan Modra changed: What|Removed |Added Keywords||patch Priority|P3 |P2 URL||https://gcc.gnu.org/ml/gcc- ||patches/2017-06/msg01678.ht ||ml
[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928 Richard Biener changed: What|Removed |Added Attachment #41612|0 |1 is obsolete|| --- Comment #24 from Richard Biener --- Created attachment 41620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41620&action=edit patch that seems to work Patch in testing/posted.
[Bug c++/81182] result of ‘operator->()’ yields non-pointer result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81182 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-23 Ever confirmed|0 |1
[Bug c++/81187] Doc entry for -Wnoexcept-type misspelled, -Wc++1z-compat missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81187 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.2 --- Comment #4 from Jonathan Wakely --- Fixed on trunk and gcc-7-branch.
[Bug c++/81187] Doc entry for -Wnoexcept-type misspelled, -Wc++1z-compat missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81187 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri Jun 23 10:56:04 2017 New Revision: 249586 URL: https://gcc.gnu.org/viewcvs?rev=249586&root=gcc&view=rev Log: PR c++/81187 fix -Wnoexcept-type entry in manual PR c++/81187 * doc/invoke.texi (-Wnoexcept-type): Fix name of option, from -Wnoexcept. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/doc/invoke.texi
[Bug c++/81180] [7/8 Regression] ICE with class template deduction in nested template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81180 Jonathan Wakely changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #3 from Jonathan Wakely --- And it is valid code AFAICT.
[Bug c++/81180] [7/8 Regression] ICE with class template deduction in nested template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81180 --- Comment #2 from Jonathan Wakely --- I don't think this is a regression, because class template argument deduction wasn't supported before r240756 - it's a new C++17 feature.
[Bug c++/81188] [7/8 Regression] decltype(this->member()) raises invalid prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81188 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r236221.
[Bug c++/81188] [7/8 Regression] decltype(this->member()) raises invalid prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81188 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |7.2 Summary|decltype(this->member())|[7/8 Regression] |raises invalid prototype|decltype(this->member()) ||raises invalid prototype
[Bug tree-optimization/81189] Out of bounds memory access introduced by the vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81189 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #1 from Richard Biener --- You can use mmap/mprotect to setup a source area where it woudl trap. See gcc.dg/vect/pr49038.c for example. Note that the vectorizer happily uses alignment for its advantage thus it is valid to access beyond the last element of an object if alignment of that object ensures the access cannot cross a page boundary (where we assume that max. alignment < page size ...).
[Bug sanitizer/81148] UBSAN: two more false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81148 --- Comment #11 from Marek Polacek --- That causes miscompiled cc1plus. Richi, any ideas?
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759 --- Comment #52 from ro at CeBiTec dot Uni-Bielefeld.DE --- > The attached patch (on top of v6) *might* solve the problem on Darwin, but I > don't understand exactly how GOTPCREL works, other than it's using a global > offset table for linking. Hopefully, the linker can translate this directly > into a constant rip-rel offset. What I'm doing here is that instead of > feeding > addresses to the asm template, I'm giving in the offsets and schlepping > together an address operand from that, e.g.: > > lea %p0 + test_data@GOTPCREL(%%rip), %%rax > > Now if this fix *does* work, then I might need to investigate if this is a > performance problem for Darwin -- why use an extra instruction to copy the > address to a register before modifying it? If it doesn't work then it's > probably because it really *needs* two instructions. I'm curious what the > disassembly of the linked program looks like. Unfortunately, the patch doesn't work, apart from the +# define PCREL "@GETPCREL" -> @GOTPCREL typo ;-) At -O0 -g3, it SEGVs at Program received signal SIGSEGV, Segmentation fault. 0x in ?? () 1: x/i $pc => 0x0: (gdb) where #0 0x in ?? () #1 0x000100031c58 in do_test_body0 () at /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:178 Backtrace stopped: previous frame inner to this frame (corrupt stack?) where %rip is 0x0. This happens because most of the addresses are off by 0x680 bytes. Here's the disassembly: (gdb) x/12i 0x000100031c58-42 0x100031c2e : push %rbp 0x100031c2f : mov%rsp,%rbp 0x100031c32 : lea0x1b407(%rip),%rax# 0x10004d040 0x100031c39 : callq 0x10003247c 0x100031c3e : lea0x1b4db(%rip),%rax# 0x10004d120 0x100031c45 : callq 0x1000324ea 0x100031c4a : pop%rax 0x100031c4b : mov%rax,0x1b696(%rip)# 0x10004d2e8 0x100031c52 : callq *0x1b688(%rip)# 0x10004d2e0 0x100031c58 : mov0x1bd09(%rip),%rcx# 0x10004d968 Here are the addresses that are supposed to be used: %p0 (gdb) p/x &test_data.regdata[0] $11 = 0x10004d6c0 %p1 (gdb) p/x &test_data.regdata[1] $12 = 0x10004d7a0 %p4 (gdb) p/x &test_data.retaddr $13 = 0x10004d968 %p3 (gdb) p/x &test_data.fn $14 = 0x10004d960 Only the second use of %p4 is right. Rainer
[Bug tree-optimization/81189] New: Out of bounds memory access introduced by the vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81189
Bug ID: 81189
Summary: Out of bounds memory access introduced by the
vectoriser
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
The testcase gcc.dg/vect/O3-pr70130.c performs an out of bounds access when
vectorised on aarch64 (I didn't check other targets).
Compile with -O3.
The problematic function is Loop_err:
void
Loop_err (struct foo *img, const int s[16][2], int s0)
{
int i, j;
for (j = 0; j < 16; j++)
{
for (i=0; i < 16; i++)
{
img->a[0][j][i] = s[i][0];
img->a[1][j][i] = s[j][1];
img->a[2][j][i] = s0;
}
}
}
The part of the assembly code that performs the loads from s[j][1] is the
problematic one:
...
add x4, x1, 4 // Add a +4 offset to 's' to access s[j][1]
...
.L7:
ldr q0, [x4], 8 // < V4SI load from s[j][1] onwards
add x2, x2, 32
str q4, [x2, -32]
cmp x5, x2
dup v0.4s, v0.s[0]
str q3, [x2, -16]
str q1, [x2, 992]
xtn v2.4h, v0.4s
xtn2v2.8h, v0.4s
str q1, [x2, 1008]
str q2, [x2, 480]
str q2, [x2, 496]
bne .L7
The array passed as as 's' is defined as:
const int s[16][2] = { { 1, 16 }, { 2, 15 }, { 3, 14 }, { 4, 13 },
{ 5, 12 }, { 6, 11 }, { 7, 10 }, { 8, 9 },
{ 9, 8 }, { 10, 7 }, { 11, 6 }, { 12, 5 },
{ 13, 4 }, { 14, 3 }, { 15, 2 }, { 16, 1 } };
So the V4SI load marked above loads 4 ints at a time starting from the second
element in each entry of 's'.
If I step through the execution gdb in gdb I see the loop reaching iteration 15
at which it loads { s[14][1], s[15][0], s[15][1], s[16][0] } where s[16][0] is
out-of-bounds.
GDB shows the contents of Q0 after the load as (formatted for readability):
s = {0x00020001 0x0001 0x0010 0x0002}
As you can see the 4th element (0x00020001) is bogus (presumably from an
adjacent constant pool entry) but because the code after the load doesn't use
it (it only cares about element 0) it doesn't cause any problems in this
instance.
It is however an out-of-bounds access so we should fix it.
Sorry I can't come up with an aborting testcase, I guess since the OOB memory
access is only 4 bytes off in the constant pool the system doesn't trap it.
[Bug c++/81187] Doc entry for -Wnoexcept-type misspelled, -Wc++1z-compat missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81187 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Jun 23 08:16:05 2017 New Revision: 249584 URL: https://gcc.gnu.org/viewcvs?rev=249584&root=gcc&view=rev Log: PR c++/81187 fix -Wnoexcept-type entry in manual PR c++/81187 * doc/invoke.texi (-Wnoexcept-type): Fix name of option, from -Wnoexcept. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug c++/81187] Doc entry for -Wnoexcept-type misspelled, -Wc++1z-compat missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81187 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-06-23 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- -Wc++1z-compat is documented at https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wc_002b_002b1z-compat I'll fix the -Wnoexcept-type entry, thanks.
[Bug c++/81188] New: decltype(this->member()) raises invalid prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81188
Bug ID: 81188
Summary: decltype(this->member()) raises invalid prototype
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: serge.guel...@telecom-bretagne.eu
Target Milestone: ---
Compiling the following test case
```
template
struct C {
F fast(long i) const;
auto operator[](long i) const -> decltype(this->fast(i));
};
template
auto C::operator[](long i) const -> decltype(this->fast(i)) {
return fast(i);
}
```
with
```
g++ -std=c++11 -c a.cpp
```
raises the following unexpected error message
```
a.cpp:8:6: error: prototype for ‘decltype (((const C*)this)->C::fast(i))
C::operator[](long int) const’ does not match any in class ‘C’
auto C::operator[](long i) const -> decltype(this->fast(i)) {
^~~~
a.cpp:4:8: error: candidate is: decltype (((const C*)this)->C::fast(i))
C::operator[](long int) const
auto operator[](long i) const -> decltype(this->fast(i));
```
Removing the ``this->`` in the decltype fixes the issue, but this is a
regression compared to g++-6 and clang++.
[Bug testsuite/81179] [8 regression] gcc.dg/vect/pr65947-9.c and gcc.dg/vect/pr65947-14.c fail starting with r249553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81179 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-06-23 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- The execute FAIL is expected (latent bug). The FAIL in -9.c I don't understand (you'd have to look when this message triggers and what's different on ppc). Mine.
[Bug c++/81180] [7/8 Regression] ICE with class template deduction in nested template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81180 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.2
[Bug tree-optimization/81181] [7/8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81181 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.2 --- Comment #2 from Richard Biener --- This likely just triggered a latent issue. I'll have a looksee.
[Bug sanitizer/81186] SIGSEGV when using Address Sanitizer with nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81186 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-06-23 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine, w/ -fno-sanitize-address-use-after-scope works fine.
[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81184 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/81181] [7/8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81181 Martin Liška changed: What|Removed |Added CC||law at redhat dot com, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, started to trigger the assert: /* Theoretically possible, but *highly* unlikely. */ gcc_checking_assert (num_iterations < 500); by r246225.
[Bug c++/81180] [7 Regression ]ICE with class template deduction in nested template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81180 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-23 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|internal compiler error |[7 Regression ]ICE with |with class template |class template deduction in |deduction in nested |nested template class |template class | Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r240756.
[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81184
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-06-23
CC||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Liška ---
Confirmed, I'm adding Jakub as author of original test-case.
The affected function changed from:
Optimizing range tests c_2(D) -[0, 31] and -[32, 32]
into c_2(D) > 32
Removing basic block 3
;; basic block 3, loop depth 0
;; pred:
;; succ: 4
fix_loop_structure: fixing up loops for function
f6 (unsigned char c)
{
int _1;
_Bool _5;
[100.00%] [count: INV]:
if (c_2(D) == 34)
goto ; [18.79%] [count: INV]
else
goto ; [81.21%] [count: INV]
[65.95%] [count: INV]:
_5 = c_2(D) <= 32;
if (_5 != 0)
goto ; [31.00%] [count: INV]
else
goto ; [69.00%] [count: INV]
[45.51%] [count: INV]:
[100.00%] [count: INV]:
# _1 = PHI <2(2), 0(4), 2(3)>
return _1;
}
to:
Optimizing range tests c_2(D) -[32, 32] and -[34, 34]
into (c_2(D) & 253) != 32
Width = 1 was chosen for reassociation
Merging blocks 2 and 3
fix_loop_structure: fixing up loops for function
f6 (unsigned char c)
{
int _1;
_Bool _4;
unsigned char _5;
[100.00%] [count: INV]:
_5 = c_2(D) & 253;
_4 = _5 == 32;
if (_4 != 0)
goto ; [10.65%] [count: INV]
else
goto ; [89.35%] [count: INV]
[79.83%] [count: INV]:
if (c_2(D) <= 31)
goto ; [18.79%] [count: INV]
else
goto ; [81.21%] [count: INV]
[15.00%] [count: INV]:
[100.00%] [count: INV]:
# _1 = PHI <0(3), 2(2), 2(4)>
return _1;
}
On x86_64 it's different because the function looks as follows:
f6 (unsigned char c)
{
int _1;
_Bool _4;
_Bool _5;
_Bool _7;
_Bool _8;
_Bool _9;
[100.00%] [count: INV]:
_5 = c_2(D) == 32;
_4 = c_2(D) == 34;
_9 = c_2(D) <= 32;
_7 = c_2(D) <= 31;
_8 = _9 | _4;
if (_8 != 0)
goto ; [15.00%] [count: INV]
else
goto ; [85.00%] [count: INV]
[15.00%] [count: INV]:
[100.00%] [count: INV]:
# _1 = PHI <0(2), 2(3)>
return _1;
}
Note that the PR exposes problem where we are able to do predictions for
conditions, but
here we transform:
if (c_2(D) == 34)
goto ; [10.65%] [count: INV]
else
goto ; [89.35%] [count: INV]
into:
_4 = c_2(D) == 34;
and then we do
_8 = _9 | _4;
if (_8 != 0)
It's related to PR79489.
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #14 from Christophe Lyon --- (In reply to Ramana Radhakrishnan from comment #13) > (In reply to christophe.lyon from comment #12) > > Created attachment 32864 [details] > > ELF binary file #3 > > > > Compiled with -Os -g3 -pie -fpie -march=armv5t -mthumb > > Is this still an issue ? As of today, the test passes on trunk, using binutils-2.27. We can probably close this bug, but I've lost track when it was fixed.
