[Bug target/86681] ICE in extract_insn, at recog.c:2304 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86681 --- Comment #1 from Martin Liška --- May I please ping that?
[Bug target/87196] New: ICE in vectorizable_load, at tree-vect-stmts.c:8043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87196 Bug ID: 87196 Summary: ICE in vectorizable_load, at tree-vect-stmts.c:8043 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rdsandiford at googlemail dot com Target Milestone: --- Following causes an ICE: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.target/aarch64/sve/catch_2.C -mstrict-align -Ofast --param vect-epilogues-nomask=1 during GIMPLE pass: vect In file included from /home/marxin/Programming/gcc/gcc/testsuite/g++.target/aarch64/sve/catch_2.C:4: /home/marxin/Programming/gcc/gcc/testsuite/g++.target/aarch64/sve/catch_1.C: In function ‘void f2(int (*)[100], int*)’: /home/marxin/Programming/gcc/gcc/testsuite/g++.target/aarch64/sve/catch_1.C:26:1: internal compiler error: in vectorizable_load, at tree-vect-stmts.c:8043 26 | f2 (int x[40][100], int *y) | ^~ 0x166907d vectorizable_load /home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:8043 0x166ecc4 vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*, _slp_tree*, _slp_instance*) /home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:9720 0x1693065 vect_transform_loop_stmt /home/marxin/Programming/gcc/gcc/tree-vect-loop.c:8267 0x1693db9 vect_transform_loop(_loop_vec_info*) /home/marxin/Programming/gcc/gcc/tree-vect-loop.c:8489 0x16ba5fb try_vectorize_loop_1 /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:943 0x16ba7d9 try_vectorize_loop_1 /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:976 0x16ba895 try_vectorize_loop /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:993 0x16baa71 vectorize_loops() /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1075 0x1546e4d execute /home/marxin/Programming/gcc/gcc/tree-ssa-loop.c:414
[Bug target/87196] ICE in vectorizable_load, at tree-vect-stmts.c:8043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87196 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-9-3 CC||ktkachov at gcc dot gnu.org, ||ramana at gcc dot gnu.org Target Milestone|--- |9.0
[Bug tree-optimization/87197] New: [9 Regression] ICE in is_gimple_reg_type at gimple-expr.h:75 since r264021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87197
Bug ID: 87197
Summary: [9 Regression] ICE in is_gimple_reg_type at
gimple-expr.h:75 since r264021
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Following isolated snippet from perlbench cases an ICE:
$ cat pp_pack.i
int a, c, e, f, g;
void
h (int i)
{
a = i;
}
void
j (char *i, long k)
{
while (k--)
c = *i++;
}
void
l (unsigned char *i, long k)
{
unsigned char *b = i + k;
while (i < b)
{
h (*i);
i++;
}
}
void
m ()
{
while (e)
{
float d = g;
l ((char *) &d, sizeof (g));
if (f)
j ((char *) &d, sizeof (g));
}
}
$ gcc pp_pack.i -c -O3
during GIMPLE pass: cunrolli
pp_pack.i: In function ‘m’:
pp_pack.i:24:1: internal compiler error: Segmentation fault
24 | m ()
| ^
0xd34cc6 crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:325
0x76bc310f ???
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xa87ce5 is_gimple_reg_type
/home/marxin/Programming/gcc/gcc/gimple-expr.h:75
0xa87ce5 is_gimple_val(tree_node*)
/home/marxin/Programming/gcc/gcc/gimple-expr.c:789
0xd6be39 verify_gimple_assign_unary
/home/marxin/Programming/gcc/gcc/tree-cfg.c:3576
0xd7dc61 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5360
0xc5072e execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1943
0xc5104a execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:1997
[Bug tree-optimization/87197] [9 Regression] ICE in is_gimple_reg_type at gimple-expr.h:75 since r264021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87197 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-03 Known to work||8.2.0 Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0
[Bug middle-end/59521] __builtin_expect not effective in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Martin Liška --- Done.
[Bug middle-end/59521] __builtin_expect not effective in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521 --- Comment #20 from Martin Liška --- Author: marxin Date: Mon Sep 3 07:51:56 2018 New Revision: 264050 URL: https://gcc.gnu.org/viewcvs?rev=264050&root=gcc&view=rev Log: Make __builtin_expect effective in switch statements (PR middle-end/PR59521). 2018-09-03 Martin Liska PR middle-end/59521 * predict.c (set_even_probabilities): Add likely_edges argument and handle cases where we have precisely one likely edge. (combine_predictions_for_bb): Catch also likely_edges. (tree_predict_by_opcode): Handle gswitch statements. * tree-cfg.h (find_case_label_for_value): New declaration. (find_taken_edge_switch_expr): Likewise. * tree-switch-conversion.c (switch_decision_tree::balance_case_nodes): Find pivot in decision tree based on probabily, not by number of nodes. 2018-09-03 Martin Liska PR middle-end/59521 * c-c++-common/pr59521-1.c: New test. * c-c++-common/pr59521-2.c: New test. * gcc.dg/tree-prof/pr59521-3.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr59521-1.c trunk/gcc/testsuite/c-c++-common/pr59521-2.c trunk/gcc/testsuite/gcc.dg/tree-prof/pr59521-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-cfg.h trunk/gcc/tree-switch-conversion.c
[Bug c++/84980] [concepts] ICE with missing typename in concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84980 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 3 07:57:33 2018 New Revision: 264051 URL: https://gcc.gnu.org/viewcvs?rev=264051&root=gcc&view=rev Log: /cp 2018-09-03 Paolo Carlini PR c++/84980 * constraint.cc (finish_shorthand_constraint): Early return if the constraint is erroneous. /testsuite 2018-09-03 Paolo Carlini PR c++/84980 * g++.dg/concepts/pr84980.C: New. Added: trunk/gcc/testsuite/g++.dg/concepts/pr84980.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constraint.cc trunk/gcc/testsuite/ChangeLog
[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193 --- Comment #17 from Martin Liška --- Author: marxin Date: Mon Sep 3 08:16:27 2018 New Revision: 264052 URL: https://gcc.gnu.org/viewcvs?rev=264052&root=gcc&view=rev Log: Come up with TARGET_GET_VALID_OPTION_VALUES option hook (PR driver/83193). 2018-09-03 Martin Liska PR driver/83193 * common/common-target.def: Add TARGET_GET_VALID_OPTION_VALUES. * common/common-targhooks.c (default_get_valid_option_values): New function. * common/common-targhooks.h (default_get_valid_option_values): Likewise. * common/config/i386/i386-common.c: Move processor_target_table from i386.c. (ix86_get_valid_option_values): New function. (TARGET_GET_VALID_OPTION_VALUES): New macro. * config/i386/i386.c (struct ptt): Move to i386-common.c. (PTA_*): Move all defined masks into i386-common.c. (ix86_function_specific_restore): Use new processor_cost_table. * config/i386/i386.h (struct ptt): Moved from i386.c. (struct pta): Likewise. * doc/tm.texi: Document new TARGET_GET_VALID_OPTION_VALUES. * doc/tm.texi.in: Likewise. * opt-suggestions.c (option_proposer::suggest_option): Pass prefix to build_option_suggestions. (option_proposer::get_completions): Likewise. (option_proposer::build_option_suggestions): Use the new target hook. * opts.c (struct option_help_tuple): New struct. (print_filtered_help): Use the new target hook. 2018-09-03 Martin Liska PR driver/83193 * gcc.dg/completion-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/completion-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/common/common-target.def trunk/gcc/common/common-targhooks.c trunk/gcc/common/common-targhooks.h trunk/gcc/common/config/i386/i386-common.c trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/opt-suggestions.c trunk/gcc/opt-suggestions.h trunk/gcc/opts.c trunk/gcc/testsuite/ChangeLog
[Bug target/87198] New: ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87198 Bug ID: 87198 Summary: ICE in extract_insn, at recog.c:2304 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hjl at gcc dot gnu.org, jakub at gcc dot gnu.org, uros at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Following causes ICE: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/xsavec-1.c -mxsavec -mno-sse2 /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/xsavec-1.c: In function ‘test_xsavec’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/xsavec-1.c:11:1: error: unrecognizable insn: } ^ (insn 14 13 17 2 (set (mem:BLK (reg:DI 89) [0 A8]) (unspec_volatile:BLK [ (subreg:SI (reg:DI 90) 0) (subreg:SI (reg:DI 91) 0) ] UNSPECV_XSAVEC)) "/usr/lib64/gcc/x86_64-suse-linux/8/include/xsavecintrin.h":41 -1 (nil)) during RTL pass: vregs /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/xsavec-1.c:11:1: internal compiler error: in extract_insn, at recog.c:2304 0x76996fea __libc_start_main ../csu/libc-start.c:308
[Bug tree-optimization/85859] [6/7/8/9 Regression] wrong code with -fno-isolate-erroneous-paths-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85859 --- Comment #7 from Tom de Vries --- (In reply to Jakub Jelinek from comment #6) > So fixed on the trunk? Any plans to backport? Will do, thanks for the ping.
[Bug tree-optimization/87186] Does not inline constant to simplify bitwise expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186 --- Comment #6 from Marc Glisse --- In some sense, the bug is that .original is optimized at all, ideally it would be the "original" unoptimized code. It is convenient to start optimizing single expressions early, so we do it, but that's it.
[Bug tree-optimization/87169] [9 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87169 --- Comment #3 from Richard Biener --- There's two issues I think though fixing the first makes us no longer run into the second. The first is that I again forgot to mark a destination block executable after marking an edge so ... (doh). The second one is that when marking loop headers as not need iterating we can face the situation (as with the CFG in this testcase) that a backedge into its header is _not_ a latch of it but part of an outer irreducible region which we may end up iterating and thus we need to continue iterating the loop we try to mark not needing that. Even though I lack a testcase for the latter issue I'll fix that as well. (fixing only that results in endless iteration - sth you'd expect)
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 --- Comment #4 from Jonathan Wakely --- Ah yes, good point. So it's user error, but we could try to give a better diagnostic.
[Bug tree-optimization/87176] [9 Regression] wrong code at -Os and above on x86-64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87176 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 --- Comment #5 from Jakub Jelinek --- Generally certainly can't, one can define the inline variable in one TU and the non-inline for the same section in a different TU. If both are in the same TU, we could, but we don't have any mapping between the user defined sections and decls that are put into those.
[Bug tree-optimization/87177] [9 Regression] wrong code at -O2 and -O3 on x86-64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87177 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug libstdc++/87193] symbols in have inconsistent types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87193 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-03 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Yes, this was noted at https://gcc.gnu.org/ml/libstdc++/2018-07/msg00128.html
[Bug libfortran/87182] libbacktrace does not use GCC own zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182 Richard Biener changed: What|Removed |Added Keywords||build CC||ian at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Really a libbacktrace issue but we don't have a proper component for that.
[Bug libstdc++/87193] symbols in have inconsistent types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87193 --- Comment #2 from Jonathan Wakely --- I'm not in a rush to fix this, because sane code should only be using those values in preprocessor conditions. They have type long only because the standard doesn't guarantee that type int can represent 6 decimal digits, not because anybody should care about the type.
[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182 Richard Biener changed: What|Removed |Added Component|libfortran |libbacktrace --- Comment #2 from Richard Biener --- Now we do.
[Bug tree-optimization/87184] generic-match.c:55076:1: ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87184 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-03 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- (In reply to John David Anglin from comment #1) > Created attachment 44645 [details] > Preprocessed source > > We might be running out of memory. Can you check that somehow? r263931 added some more patterns so generic-match.c grow.
[Bug tree-optimization/87186] Does not inline constant to simplify bitwise expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Richard Biener --- Yes. And I doubt we'll add 'const' expression initializer "inlining" for early folding in the FEs.
[Bug lto/87187] FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87187 Richard Biener changed: What|Removed |Added Blocks||86549 --- Comment #2 from Richard Biener --- Probably reproduces on x86_64-linux when you compile with -g0 and link with -g (didn't check). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86549 [Bug 86549] [8/9 Regression] -flto -g0 vs. -g issues
[Bug libstdc++/87194] Associative container cannot be inserted from move iterators that refer to elements implicitly convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87194 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-03 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I think this is the same problem as PR 78595
[Bug other/87199] New: Thread local storage dynamic initialization behaviour differs Linux vs macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87199
Bug ID: 87199
Summary: Thread local storage dynamic initialization behaviour
differs Linux vs macOS
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: me at nvartolomei dot com
Target Milestone: ---
Hello,
Here is a test program that behaves different on Linux vs macOS.
main.c:
```
#include "lib.h"
int main() {
getProfileEvents();
}
```
lib.cpp
```
#include "lib.h"
thread_local ThreadStatus thread_local_var = ThreadStatus();
ThreadStatus::ThreadStatus() {
std::cout << "cons";
doX();
}
```
lib.h
```
#pragma once
#include
#include
class ThreadStatus {
public:
int x = 0;
ThreadStatus();
static void doX() { std::cout << "test"; }
};
extern thread_local ThreadStatus thread_local_var;
static int getProfileEvents() {
return thread_local_var.x;
}
```
Compiling it using the following command:
`g++-8 -g -std=c++17 -c -I . main.cpp && g++-8 -g -std=c++17 -c -I . lib.cpp
&& g++-8 -o main main.o lib.o && ./main`
On a Linux machine the output is: "constest" (g++-8 (Ubuntu
8-20180414-1ubuntu2) 8.0.1 20180414 (experimental) [trunk revision 259383])
On a macOS machine the output is empty. (Homebrew GCC 8.2.0, also HEAD)
I found curious that moving doX definition from .h file to .cpp will make this
work correctly.
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Hmm, "interesting" case. Not sure what to do about these...
[Bug c/87192] -Warray-bounds (even =2) does not work on struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-03 Blocks||56456 Ever confirmed|0 |1 --- Comment #8 from Richard Biener --- The issue is the array isn't visible in the IL anymore but we have bar (&MEM[(void *)&s + 48B]); The first CCP pass already propagates the constant pointer from _1 = &s.a + 48; bar (_1); to the above. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 --- Comment #6 from Jonathan Wakely --- OK. FWIW Clang seems to create two different sections called foo, one COMDAT and one not.
[Bug tree-optimization/87197] [9 Regression] ICE in is_gimple_reg_type at gimple-expr.h:75 since r264021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87197 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Mine.
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #3 from Jakub Jelinek --- This is a glibc bug, coming up with a set of weakref checks for gthr.h that would satisfy static linking of glibc and all possible combinations of included vs. non-included objects is impossible. E.g. Fedora/RHEL ld -r libpthread.a objects into a single exactly because of this. The other alternative is to add (for libpthread.a) dependencies in betweeh the *.o objects so that a reasonable set is always linked together, or just link with --whole-archive -lpthread --no-whole-archive. There are many dups of this both on the gcc side and glibc side.
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 --- Comment #7 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #6) > OK. > > FWIW Clang seems to create two different sections called foo, one COMDAT and > one not. Does it? That is I think impossible unless bypassing assembler. If I try godbolt and look at clang++ trunk generated assembly, it doesn't honor the user sections at all, whether using inline vars or not.
[Bug tree-optimization/85859] [6/7/8 Regression] wrong code with -fno-isolate-erroneous-paths-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85859 --- Comment #8 from Tom de Vries --- Author: vries Date: Mon Sep 3 09:43:46 2018 New Revision: 264053 URL: https://gcc.gnu.org/viewcvs?rev=264053&root=gcc&view=rev Log: backport "[tail-merge] Fix side-effect test in stmt_local_def" 2018-09-03 Tom de Vries backport from trunk: 2018-06-21 Tom de Vries PR tree-optimization/85859 * tree-ssa-tail-merge.c (stmt_local_def): Copy gimple_is_call test with comment from bb_no_side_effects_p. * gcc.dg/pr85859.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr85859.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-tail-merge.c
[Bug tree-optimization/87200] New: [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87200
Bug ID: 87200
Summary: [9 Regression] ICE in set_ssa_val_to, at
tree-ssa-sccvn.c:3629
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20180902 snapshot (r264045) ICEs when compiling the following
snippet w/ any optimization level:
unsigned long long int ry;
int
gl (void)
{
long long int my = 0;
unsigned long long int *oi = (unsigned long long int *) &my;
int s9;
s9 = !!gl () ? ry : 0;
if (s9 != 0)
oi = &ry;
else
{
my = ry;
*oi += my;
}
return *oi;
}
% gcc-9.0.0-alpha20180902 -O1 -c piukefl9.c
during GIMPLE pass: fre
piukefl9.c: In function 'gl':
piukefl9.c:20:1: internal compiler error: in set_ssa_val_to, at
tree-ssa-sccvn.c:3629
20 | }
| ^
0x69bc1b set_ssa_val_to
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:3629
0xe61819 visit_reference_op_load
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:3985
0xe61819 visit_stmt
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:4359
0xe630ac process_bb
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:5980
0xe64468 do_rpo_vn
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:6406
0xe651cc execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:6598
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 --- Comment #8 from Jonathan Wakely --- Ah I misread it then.
[Bug middle-end/87201] New: [9 Regression] Segfault in GIMPLE pass: switchlower_O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87201
Bug ID: 87201
Summary: [9 Regression] Segfault in GIMPLE pass: switchlower_O0
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Created attachment 44650
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44650&action=edit
Test case, compiled with "g++ test.ii"
That's with GCC 9. I did this morning a bootstrip (incremental build) with
r264051 - and installed it. A "git pull" then made r264052 available. Using the
previous build as system compiler failed with:
../../gcc/genoutput.c:276:1: internal compiler error: Segmentation fault
(Attached is a more simplified test case, which crashes my r264051.
TODO: bisect; [me: use clean GCC bootstrap not incremental build].)
g++ -w input21.ii
during GIMPLE pass: switchlower_O0
input21.ii: In function ‘long unsigned int ParseBinary(const char*,
XPParser**)’:
input21.ii:7:26: internal compiler error: Segmentation fault
7 | static long unsigned int ParseBinary (const char *str, XPParser ** p) {
| ^~~
0xed326f crash_signal
../../gcc/toplev.c:325
0xfb4198
tree_switch_conversion::switch_decision_tree::balance_case_nodes(tree_switch_conversion::case_tree_node**,
tree_switch_conversion::case_tree_node*)
../../gcc/tree-switch-conversion.c:1944
0xfb4fca tree_switch_conversion::switch_decision_tree::emit(basic_block_def*,
tree_node*, profile_probability, tree_node*)
../../gcc/tree-switch-conversion.c:1869
0xfb634e
tree_switch_conversion::switch_decision_tree::try_switch_expansion(vec&)
../../gcc/tree-switch-conversion.c:1783
0xfb6c2f
tree_switch_conversion::switch_decision_tree::analyze_switch_statement()
../../gcc/tree-switch-conversion.c:1709
0xfb72c2 execute
../../gcc/tree-switch-conversion.c:2444
[Bug tree-optimization/87202] New: [9 Regression] ICE in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87202
Bug ID: 87202
Summary: [9 Regression] ICE in vn_reference_insert_pieces, at
tree-ssa-sccvn.c:2752
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20180902 snapshot (r264045) ICEs when compiling the following
snippet w/ -O1 (-Og):
int dk;
void
lv (void)
{
int nm;
dk = 1;
while (dk != 0)
{
}
if (1 / 0)
{
dk = 0;
while (dk != 0)
{
}
}
for (;;)
nm = !!dk;
(void) nm;
}
% gcc-9.0.0-alpha20180902 -O1 -w -c znz65qpd.c
during GIMPLE pass: fre
znz65qpd.c: In function 'lv':
znz65qpd.c:25:1: internal compiler error: in vn_reference_insert_pieces, at
tree-ssa-sccvn.c:2752
25 | }
| ^
0x69c31f vn_reference_insert_pieces(tree_node*, int, tree_node*,
vec, tree_node*, unsigned int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:2752
0xe5e153 vn_reference_lookup_or_insert_for_pieces
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:1728
0xe5ee1c vn_reference_lookup_3
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:2182
0xdaa643 walk_non_aliased_vuses(ao_ref*, tree_node*, void* (*)(ao_ref*,
tree_node*, unsigned int, void*), void* (*)(ao_ref*, tree_node*, void*, bool*),
tree_node* (*)(tree_node*), void*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-alias.c:2833
0xe5b796 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:2630
0xe61748 visit_reference_op_load
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:3961
0xe61748 visit_stmt
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:4359
0xe630ac process_bb
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:5980
0xe64468 do_rpo_vn
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:6406
0xe651cc execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/tree-ssa-sccvn.c:6598
[Bug tree-optimization/85859] [6/7 Regression] wrong code with -fno-isolate-erroneous-paths-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85859 --- Comment #9 from Tom de Vries --- Author: vries Date: Mon Sep 3 10:04:08 2018 New Revision: 264054 URL: https://gcc.gnu.org/viewcvs?rev=264054&root=gcc&view=rev Log: backport "[tail-merge] Fix side-effect test in stmt_local_def" 2018-09-03 Tom de Vries backport from trunk: 2018-06-21 Tom de Vries PR tree-optimization/85859 * tree-ssa-tail-merge.c (stmt_local_def): Copy gimple_is_call test with comment from bb_no_side_effects_p. * gcc.dg/pr85859.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr85859.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-ssa-tail-merge.c
[Bug middle-end/87201] [9 Regression] Segfault in GIMPLE pass: switchlower_O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87201 Tobias Burnus changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- [Now did clean bootstrap; result below is the same for the Stage1 compiler (compiled by GCC 8) as for the incremental build of GCC 9.] Culprit is probably r264050: Make __builtin_expect effective in switch statements (PR middle-end/PR59521). Running cc1plus in the debugger shows that the crash is for: tree_switch_conversion::switch_decision_tree::balance_case_nodes at ../../gcc/tree-switch-conversion.c:1944 1944 prob -= (*npp)->m_c->m_prob; where (gdb) p npp $1 = (tree_switch_conversion::case_tree_node **) 0x2934f28 (gdb) p *npp $2 = (tree_switch_conversion::case_tree_node *) 0x0 (gdb) p *npp
[Bug web/87050] Bump wwwdocs to html5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87050 --- Comment #11 from Janne Blomqvist --- (In reply to Gerald Pfeifer from comment #10) > (In reply to Janne Blomqvist from comment #0) > > So apart from the headers, little work ought to be needed for the > > conversion itself. > > Well, no. :-} https://gcc.gnu.org/ml/gcc-patches/2018-09/ speaks a > different language, and that's just part of it, after all I did the > last year(s) already. Indeed, it seems I grossly underestimated the amount of work required. Thanks for doing it!
[Bug tree-optimization/85859] [6 Regression] wrong code with -fno-isolate-erroneous-paths-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85859 --- Comment #10 from Tom de Vries --- Author: vries Date: Mon Sep 3 10:14:52 2018 New Revision: 264055 URL: https://gcc.gnu.org/viewcvs?rev=264055&root=gcc&view=rev Log: backport "[tail-merge] Fix side-effect test in stmt_local_def" 2018-09-03 Tom de Vries backport from trunk: 2018-06-21 Tom de Vries PR tree-optimization/85859 * tree-ssa-tail-merge.c (stmt_local_def): Copy gimple_is_call test with comment from bb_no_side_effects_p. * gcc.dg/pr85859.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr85859.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-tail-merge.c
[Bug tree-optimization/85859] wrong code with -fno-isolate-erroneous-paths-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85859 Tom de Vries changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Summary|[6 Regression] wrong code |wrong code with |with|-fno-isolate-erroneous-path |-fno-isolate-erroneous-path |s-dereference |s-dereference | --- Comment #11 from Tom de Vries --- Patch with test-case committed to trunk and backported. Marking resolved-fixed.
[Bug target/87198] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87198
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-09-03
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Created attachment 44651
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44651&action=edit
gcc9-pr87198.patch
Bug in the option handling, -mxsavec turned on -mxsave and relied on that, but
-mno-xsave didn't turn off -mxsave{opt,c,s}.
[Bug target/87198] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87198 --- Comment #2 from Uroš Bizjak --- I think you also need: diff --git a/gcc/common/config/i386/i386-common.c b/gcc/common/config/i386/i386-common.c index 70b3c3f2fc31..edb55e542451 100644 --- a/gcc/common/config/i386/i386-common.c +++ b/gcc/common/config/i386/i386-common.c @@ -181,7 +181,7 @@ along with GCC; see the file COPYING3. If not see #define OPTION_MASK_ISA_AVX_UNSET \ (OPTION_MASK_ISA_AVX | OPTION_MASK_ISA_FMA_UNSET \ | OPTION_MASK_ISA_FMA4_UNSET | OPTION_MASK_ISA_F16C_UNSET \ - | OPTION_MASK_ISA_AVX2_UNSET | OPTION_MASK_ISA_XSAVE_UNSET) + | OPTION_MASK_ISA_AVX2_UNSET) #define OPTION_MASK_ISA_FMA_UNSET OPTION_MASK_ISA_FMA #define OPTION_MASK_ISA_FXSR_UNSET OPTION_MASK_ISA_FXSR #define OPTION_MASK_ISA_XSAVE_UNSET \ so -mno-avx won't turn off -mxsave.
[Bug target/87198] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87198 --- Comment #3 from Jakub Jelinek --- (In reply to Uroš Bizjak from comment #2) > I think you also need: > > diff --git a/gcc/common/config/i386/i386-common.c > b/gcc/common/config/i386/i386-common.c > index 70b3c3f2fc31..edb55e542451 100644 > --- a/gcc/common/config/i386/i386-common.c > +++ b/gcc/common/config/i386/i386-common.c > @@ -181,7 +181,7 @@ along with GCC; see the file COPYING3. If not see > #define OPTION_MASK_ISA_AVX_UNSET \ >(OPTION_MASK_ISA_AVX | OPTION_MASK_ISA_FMA_UNSET \ > | OPTION_MASK_ISA_FMA4_UNSET | OPTION_MASK_ISA_F16C_UNSET \ > - | OPTION_MASK_ISA_AVX2_UNSET | OPTION_MASK_ISA_XSAVE_UNSET) > + | OPTION_MASK_ISA_AVX2_UNSET) > #define OPTION_MASK_ISA_FMA_UNSET OPTION_MASK_ISA_FMA > #define OPTION_MASK_ISA_FXSR_UNSET OPTION_MASK_ISA_FXSR > #define OPTION_MASK_ISA_XSAVE_UNSET \ > > so -mno-avx won't turn off -mxsave. Why shouldn't it turn off -mxsave? -mavx sets -mxsave too. I mean, otherwise if one does say on -m32 do -mavx -mno-avx, then won't that turn on -mxsave and not turn it off again? Or with target pragmas. I believe we generally want consistency, if option ABC turns automatically option DEF, then turning off option DEF explicitly disables option ABC.
[Bug tree-optimization/87176] [9 Regression] wrong code at -Os and above on x86-64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87176 --- Comment #3 from Richard Biener --- The issue here is similar to that of PR87132 - this time we get at memory state from the previous iteration by means of a virtual PHI that was value-numbered to its backedge value.
[Bug tree-optimization/87202] [9 Regression] ICE in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87202 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-03 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug middle-end/87201] [9 Regression] Segfault in GIMPLE pass: switchlower_O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87201 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug tree-optimization/87200] [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87200 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-03 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug middle-end/87201] [9 Regression] Segfault in GIMPLE pass: switchlower_O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87201 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-03 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- It ICEs all over the testsuite in the same way ... Confirmed (but bootstrap worked OK for me).
[Bug libstdc++/78595] Unnecessary copies in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78595 Jonathan Wakely changed: What|Removed |Added Assignee|ville.voutilainen at gmail dot com |redi at gcc dot gnu.org Target Milestone|8.3 |9.0
[Bug middle-end/87203] New: Optimize x % constant ==/!= 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87203 Bug ID: 87203 Summary: Optimize x % constant ==/!= 0 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- As mentioned in http://duriansoftware.com/joe/Optimizing-is-multiple-checks-with-modular-arithmetic.html , we could optimize unsigned x % const == 0 or x % const != 0 into a single (non-highpart) multiplication plus comparison (at least for odd const, for even const we can rotate before comparison if target has cheap rotates, or could test low bits and compare). Obviously, for power of two const we already emit the best code.
[Bug middle-end/87201] [9 Regression] Segfault in GIMPLE pass: switchlower_O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87201 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Mine.
[Bug target/87198] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87198 --- Comment #4 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #3) > (In reply to Uroš Bizjak from comment #2) > > I think you also need: > > > > diff --git a/gcc/common/config/i386/i386-common.c > > b/gcc/common/config/i386/i386-common.c > > index 70b3c3f2fc31..edb55e542451 100644 > > --- a/gcc/common/config/i386/i386-common.c > > +++ b/gcc/common/config/i386/i386-common.c > > @@ -181,7 +181,7 @@ along with GCC; see the file COPYING3. If not see > > #define OPTION_MASK_ISA_AVX_UNSET \ > >(OPTION_MASK_ISA_AVX | OPTION_MASK_ISA_FMA_UNSET \ > > | OPTION_MASK_ISA_FMA4_UNSET | OPTION_MASK_ISA_F16C_UNSET \ > > - | OPTION_MASK_ISA_AVX2_UNSET | OPTION_MASK_ISA_XSAVE_UNSET) > > + | OPTION_MASK_ISA_AVX2_UNSET) > > #define OPTION_MASK_ISA_FMA_UNSET OPTION_MASK_ISA_FMA > > #define OPTION_MASK_ISA_FXSR_UNSET OPTION_MASK_ISA_FXSR > > #define OPTION_MASK_ISA_XSAVE_UNSET \ > > > > so -mno-avx won't turn off -mxsave. > > Why shouldn't it turn off -mxsave? -mavx sets -mxsave too. > I mean, otherwise if one does say on -m32 do -mavx -mno-avx, then won't that > turn on -mxsave and not turn it off again? Or with target pragmas. > I believe we generally want consistency, if option ABC turns automatically > option DEF, then turning off option DEF explicitly disables option ABC. Please see recent discussion in PR87171#c4.
[Bug sanitizer/87191] UBSan doesn't catch invalid pointer arithmetic outside known object bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87191
--- Comment #3 from Martin Liška ---
I believe it's nice example where ASAN can help:
$ cat pr87191.c
void bar(void *ptr)
{
__builtin_putchar (*(char *)ptr);
}
int main()
{
char a[10];
bar(&a+2);
}
$ =
==17684==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffdb84 at pc 0x00401192 bp 0x7fffdb20 sp 0x7fffdb18
READ of size 1 at 0x7fffdb84 thread T0
#0 0x401191 in bar (/home/marxin/Programming/testcases/a.out+0x401191)
#1 0x40122a in main (/home/marxin/Programming/testcases/a.out+0x40122a)
#2 0x76c71fea in __libc_start_main ../csu/libc-start.c:308
#3 0x4010a9 in _start (/home/marxin/Programming/testcases/a.out+0x4010a9)
Address 0x7fffdb84 is located in stack of thread T0 at offset 52 in frame
#0 0x4011b5 in main (/home/marxin/Programming/testcases/a.out+0x4011b5)
This frame has 1 object(s):
[32, 42) 'a' <== Memory access at offset 52 overflows this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
[Bug other/87199] Thread local storage dynamic initialization behaviour differs Linux vs macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87199 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- My first guess would be that the difference is Linux has native TLS, whereas macOS only has emutls, which would be bug 52268. I'll wait for someone else to confirm, though.
[Bug middle-end/87203] Optimize x % constant ==/!= 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87203 --- Comment #1 from Marc Glisse --- Dup of PR 82853 ?
[Bug middle-end/87203] Optimize x % constant ==/!= 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87203 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Dup indeed. *** This bug has been marked as a duplicate of bug 82853 ***
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- *** Bug 87203 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87200] [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87200 --- Comment #2 from Richard Biener --- The underlying issue is that match-and-simplify invoked via vn_nary_build_or_lookup_1 valuezies captures according to availability. But in the end we'd like to have a value-number back.
[Bug tree-optimization/87184] generic-match.c:55076:1: ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87184 --- Comment #3 from dave.anglin at bell dot net --- On 2018-09-03 5:20 AM, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87184 > > Richard Biener changed: > > What|Removed |Added > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2018-09-03 > Ever confirmed|0 |1 > > --- Comment #2 from Richard Biener --- > (In reply to John David Anglin from comment #1) >> Created attachment 44645 [details] >> Preprocessed source >> >> We might be running out of memory. > Can you check that somehow? r263931 added some more patterns so > generic-match.c grow. I'm not sure. When I compiled generic-match.c manually, it completed successfully. I restarted the build and the compile failed again at stage3. At stage2, the compile now takes on the order of half an hour... I had started a regression search. I'll check if r263931 introduced the problem.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #14 from Jakub Jelinek --- http://duriansoftware.com/joe/Optimizing-is-multiple-checks-with-modular-arithmetic.html Do we want to do this at GIMPLE time ignoring costs, or during expansion time? Doing it later has the benefit that we can compare costs and could avoid breaking say divmod recognition, or finding out multiple uses of the modulo, etc. Doing it earlier has the benefit for vectorization I guess, otherwise we need a pattern recognizer that will work like the expansion.
[Bug libstdc++/87194] Associative container cannot be inserted from move iterators that refer to elements implicitly convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87194 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #15 from ktkachov at gcc dot gnu.org --- I tried to do something similar at https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02005.html and the feedback was that we should do this at expand time
[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737 John David Anglin changed: What|Removed |Added Last reconfirmed|2016-01-29 00:00:00 |2018-08-16 0:00 --- Comment #2 from John David Anglin --- Still present in gcc 9.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #16 from Jakub Jelinek --- For unsigned x % y == z if y is odd constant we can handle it for any constant z, by computing m = mul_inv (y, 2^prec) and d = (2^prec / y) and using x * m - (z * m) < d . For even y, not sure if it can work for anything but z == 0; for z == 0 we can do s = ctz (y); y_ = y >> s; m = mul_inv (y_, 2^prec); d = (2^prec / y_); and use ((x * m) r>> s) < d .
[Bug libquadmath/87204] New: strtoflt128 produces different results for subnormals with -m32 and -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204
Bug ID: 87204
Summary: strtoflt128 produces different results for subnormals
with -m32 and -m64
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: barannikov88 at gmail dot com
Target Milestone: ---
The testcase:
#include
#include
#include
int main ()
{
union {
__float128 f;
uint64_t i64[2];
} u = { .f = strtoflt128("1e-4941", NULL) };
printf("%016" PRIx64 " %016" PRIx64 "\n", u.i64[1], u.i64[0]);
}
$ gcc-7.3.0 t.c -lquadmath -lm -m32 && a.out
00014707 e947d757fbf6f700
$ gcc-7.3.0 t.c -lquadmath -lm -m64 && a.out
00014707 e946d257f2f674b9
The output is for x86-64, haven't tested for other platforms.
[Bug tree-optimization/87169] [9 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87169 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/87197] [9 Regression] ICE in is_gimple_reg_type at gimple-expr.h:75 since r264021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87197 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug tree-optimization/87169] [9 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87169 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Sep 3 13:28:25 2018 New Revision: 264057 URL: https://gcc.gnu.org/viewcvs?rev=264057&root=gcc&view=rev Log: 2018-09-03 Richard Biener PR tree-optimization/87197 * tree-ssa-sccvn.c (vn_nary_build_or_lookup_1): Mark the new def visited. CSE the VN_INFO hashtable lookup. * gcc.dg/torture/pr87197.c: New testcase. PR tree-optimization/87169 * tree-ssa-sccvn.c (do_rpo_vn): When marking loops for not iterating make sure there's no extra backedges from irreducible regions feeding the header. Mark the destination block executable. * gcc.dg/torture/pr87169.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87169.c trunk/gcc/testsuite/gcc.dg/torture/pr87197.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/87197] [9 Regression] ICE in is_gimple_reg_type at gimple-expr.h:75 since r264021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87197 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Sep 3 13:28:25 2018 New Revision: 264057 URL: https://gcc.gnu.org/viewcvs?rev=264057&root=gcc&view=rev Log: 2018-09-03 Richard Biener PR tree-optimization/87197 * tree-ssa-sccvn.c (vn_nary_build_or_lookup_1): Mark the new def visited. CSE the VN_INFO hashtable lookup. * gcc.dg/torture/pr87197.c: New testcase. PR tree-optimization/87169 * tree-ssa-sccvn.c (do_rpo_vn): When marking loops for not iterating make sure there's no extra backedges from irreducible regions feeding the header. Mark the destination block executable. * gcc.dg/torture/pr87169.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87169.c trunk/gcc/testsuite/gcc.dg/torture/pr87197.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #17 from Alexander Monakov --- (In reply to Jakub Jelinek from comment #16) > For unsigned x % y == z if y is odd constant we can handle it for any > constant z, by computing m = mul_inv (y, 2^prec) and d = (2^prec / y) and > using x * m - (z * m) < d . Is that preferable to testing (x - z) % y == 0? Why?
[Bug middle-end/87201] [9 Regression] Segfault in GIMPLE pass: switchlower_O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87201 --- Comment #4 from Martin Liška --- Author: marxin Date: Mon Sep 3 13:35:35 2018 New Revision: 264058 URL: https://gcc.gnu.org/viewcvs?rev=264058&root=gcc&view=rev Log: Fix thinko (PR tree-optimization/87201). 2018-09-03 Martin Liska PR tree-optimization/87201 * tree-switch-conversion.c (switch_decision_tree::balance_case_nodes): Fix parenthesis in an expression. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-switch-conversion.c
[Bug middle-end/87201] [9 Regression] Segfault in GIMPLE pass: switchlower_O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87201 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed now.
[Bug tree-optimization/87177] [9 Regression] wrong code at -O2 and -O3 on x86-64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87177 Richard Biener changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #3 from Richard Biener --- *** Bug 87202 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87202] [9 Regression] ICE in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87202 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener --- Fixed by same reversal as PR87177. *** This bug has been marked as a duplicate of bug 87177 ***
[Bug c++/87205] New: Inefficient code generation for switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87205
Bug ID: 87205
Summary: Inefficient code generation for switch
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
For the following code:
```
void f( int x );
void h( unsigned ix )
{
switch( ix )
{
case 0: f(42); break;
case 1: f(42); break;
case 2: f(42); break;
case 3: f(42); break;
case 4: f(42); break;
case 5: f(42); break;
default: __builtin_unreachable();
}
}
```
g++ 9.0 -O2, -O3 generates:
```
h(unsigned int):
cmp edi, 5
jbe .L5
.L5:
mov edi, 42
jmp f(int)
```
https://godbolt.org/z/4I_Chu
The initial part that compares edi to 5 is redundant.
At -O1 the result is a jump table that doesn't check edi, as expected:
```
h(unsigned int):
sub rsp, 8
mov edi, edi
jmp [QWORD PTR .L4[0+rdi*8]]
```
This is a simplified example; I've stripped the metaprogramming that produces
it. :-)
For comparison, g++ 8.2 produces
```
h(unsigned int):
cmp edi, 5
ja .L2
mov edi, 42
jmp f(int)
h(unsigned int) [clone .cold.0]:
.L2:
```
[Bug libstdc++/87194] Associative container cannot be inserted from move iterators that refer to elements implicitly convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87194 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Mon Sep 3 14:25:25 2018 New Revision: 264060 URL: https://gcc.gnu.org/viewcvs?rev=264060&root=gcc&view=rev Log: PR libstdc++/87194 fix range insertion into maps and sets Since C++11 range insertion and construction of maps and sets from a pair of iterators only requires that the iterator's value_type is convertible to the container's value_type (previously it had to be the same). This fixes the implementation to meet that relaxed requirement, by defining a pair of overloads that either insert or emplace, depending on the iterator's value_type. Instead of adding yet another overload of _M_insert_unique and _M_insert_equal, the overloads taking iterators are renamed to _M_insert_range_unique and _M_insert_range_equal. PR libstdc++/87194 * include/bits/stl_map.h (map::map(initializer_list, const Compare&, const Alloc&)) (map::map(initializer_list, const Alloc&)) (map::map(InputIterator, InputIterator, const Alloc&)) (map::map(InputIterator, InputIterator)) (map::map(InputIterator, InputIterator, const Compare&, const Alloc&)) (map::insert(InputIterator, InputIterator)): Call _M_insert_range_unique instead of _M_insert_unique. * include/bits/stl_multimap.h (multimap::multimap(initializer_list, const C&, const A&)) (multimap::multimap(initializer_list, const A&)) (multimap::multimap(InputIterator, InputIterator, const A&)) (multimap::multimap(InputIterator, InputIterator)) (multimap::multimap(InputIterator, InputIterator, const C&, const A&)) (multimap::insert(InputIterator, InputIterator)): Call _M_insert_range_equal instead of _M_insert_equal. * include/bits/stl_multiset.h (multiset::multiset(InputIterator, InputIterator)) (multiset::multiset(InputIterator, InputIterator, const C&, const A&)) (multiset::multiset(initializer_list, const C&, const A&)) (multiset::multiset(initializer_list, const A&)) (multiset::multiset(InputIterator, InputIterator, const A&)) (multiset::insert(InputIterator, InputIterator)): Call _M_insert_range_equal instead of _M_insert_equal. * include/bits/stl_set.h (set::set(InputIterator, InputIterator)) (set::set(InputIterator, InputIterator, const Compare&, const Alloc&)) (set::set(initializer_list, const Compare&, const Alloc&)) (set::set(initializer_list, const Alloc&)) (set::set(InputIterator, InputIterator, const Alloc&)) (set::insert(InputIterator, InputIterator)): Call _M_insert_range_unique instead of _M_insert_unique. * include/bits/stl_tree.h [__cplusplus >= 201103L] (_Rb_tree::__same_value_type): New alias template for SFINAE constraints. [__cplusplus >= 201103L] (_Rb_tree::_M_insert_range_unique): Pair of constrained overloads that either insert or emplace, depending on iterator's value_type. [__cplusplus >= 201103L] (_Rb_tree::_M_insert_range_equal): Likewise. [__cplusplus < 201103L] (_Rb_tree::_M_insert_range_unique) (_Rb_tree::_M_insert_range_equal): New functions replacing range versions of _M_insert_unique and _M_insert_equal. (_Rb_tree::_M_insert_unique(_InputIterator, _InputIterator)) (_Rb_tree::_M_insert_equal(_InputIterator, _InputIterator)): Remove. * testsuite/23_containers/map/modifiers/insert/87194.cc: New test. * testsuite/23_containers/multimap/modifiers/insert/87194.cc: New test. * testsuite/23_containers/multiset/modifiers/insert/87194.cc: New test. * testsuite/23_containers/set/modifiers/insert/87194.cc: New test. Added: trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/insert/87194.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/modifiers/insert/87194.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/modifiers/insert/87194.cc trunk/libstdc++-v3/testsuite/23_containers/set/modifiers/insert/87194.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_map.h trunk/libstdc++-v3/include/bits/stl_multimap.h trunk/libstdc++-v3/include/bits/stl_multiset.h trunk/libstdc++-v3/include/bits/stl_set.h trunk/libstdc++-v3/include/bits/stl_tree.h
[Bug libstdc++/78595] Unnecessary copies in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78595 --- Comment #13 from Jonathan Wakely --- Author: redi Date: Mon Sep 3 14:25:12 2018 New Revision: 264059 URL: https://gcc.gnu.org/viewcvs?rev=264059&root=gcc&view=rev Log: PR libstdc++/78595 implement insertion into maps in terms of emplace C++14 simplified the specification of the generic insert function templates to be equivalent to calling emplace (or emplace_hint). Defining them in terms of emplace takes care of the problems described in PR 78595, ensuring a single conversion to value_type is done at the right time. PR libstdc++/78595 * include/bits/stl_map.h (map::insert(_Pair&&)) (map::insert(const_iterator, _Pair&&)): Do emplace instead of insert. * include/bits/stl_multimap.h (multimap::insert(_Pair&&)) (multimap::insert(const_iterator, _Pair&&)): Likewise. * include/bits/unordered_map.h (unordered_map::insert(_Pair&&)) (unordered_map::insert(const_iterator, _Pair&&)) (unordered_multimap::insert(_Pair&&)) (unordered_multimap::insert(const_iterator, _Pair&&)): Likewise. * testsuite/23_containers/map/modifiers/insert/78595.cc: New test. * testsuite/23_containers/multimap/modifiers/insert/78595.cc: New test. * testsuite/23_containers/unordered_map/modifiers/78595.cc: New test. * testsuite/23_containers/unordered_multimap/modifiers/78595.cc: New test. Added: trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/insert/78595.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/modifiers/insert/78595.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_map/modifiers/78595.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/modifiers/78595.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_map.h trunk/libstdc++-v3/include/bits/stl_multimap.h trunk/libstdc++-v3/include/bits/unordered_map.h
[Bug libstdc++/78595] Unnecessary copies in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78595 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jonathan Wakely --- Fixed on trunk. This is probably safe to backport, but I'll wait a while.
[Bug tree-optimization/87200] [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87200 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/87200] [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87200 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Sep 3 14:29:00 2018 New Revision: 264062 URL: https://gcc.gnu.org/viewcvs?rev=264062&root=gcc&view=rev Log: 2018-09-03 Richard Biener PR tree-optimization/87200 * tree-ssa-sccvn.c (vn_nary_build_or_lookup_1): Valueize a simplify result. * gcc.dg/torture/pr87200.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87200.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug libstdc++/78179] FAIL: 26_numerics/headers/cmath/hypot.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78179 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #5 from Jonathan Wakely --- This should be fixed at r264063, please reopen if not (or if you want it backported).
[Bug libstdc++/78179] FAIL: 26_numerics/headers/cmath/hypot.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78179 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Mon Sep 3 14:54:28 2018 New Revision: 264063 URL: https://gcc.gnu.org/viewcvs?rev=264063&root=gcc&view=rev Log: PR libstdc++/78179 run long double tests separately Split the long double testing into a separate file, so that we can XFAIL targets where the long double precision doesn't meet the expected tolerances. The float and double tests are still expefted to PASS for all targets. PR libstdc++/78179 * testsuite/26_numerics/headers/cmath/hypot-long-double.cc: New test that runs the long double part of hypot.cc. * testsuite/26_numerics/headers/cmath/hypot.cc: Disable long double tests unless TEST_HYPOT_LONG_DOUBLE is defined. Added: trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot.cc
[Bug libstdc++/87194] Associative container cannot be inserted from move iterators that refer to elements implicitly convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87194 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #3 from Jonathan Wakely --- Fixed for GCC 9.
[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2018-08-16 00:00:00 |2018-09-03 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Could this be due to using alloca? The tests should not require a huge stack, so either alloca isn't usable or maybe there's a bug causing an infinite recursion.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #18 from Wilco --- (In reply to Alexander Monakov from comment #17) > (In reply to Jakub Jelinek from comment #16) > > For unsigned x % y == z if y is odd constant we can handle it for any > > constant z, by computing m = mul_inv (y, 2^prec) and d = (2^prec / y) and > > using x * m - (z * m) < d . > > Is that preferable to testing (x - z) % y == 0? Why? That would require checking that it when x - z underflows if returns the correct answer (or adding a && x >= z).
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #4 from Paul Pluzhnikov --- (In reply to Jakub Jelinek from comment #3) > This is a glibc bug I (obviously) disagree. , coming up with a set of weakref checks for gthr.h that > would satisfy static linking of glibc and all possible combinations of > included vs. non-included objects is impossible. If you call pthread_mutex_lock (or any other function) via weakref, then you should ensure that the function is actually available. AFAICT, libgcc only calls a few pthread_* functions. Why is it hard to check that *all* of them are present? > E.g. Fedora/RHEL ld -r libpthread.a objects into a single exactly because of > this. That is a workaround, not a fix. And it has significant negative effects in the resulting program code size. > There are many dups of this both on the gcc side and glibc side. Well, I think GCC and GLIBC developers need to sit down and decide whose bug it is, and fix it once and for all :-)
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #5 from Jakub Jelinek --- (In reply to Paul Pluzhnikov from comment #4) > (In reply to Jakub Jelinek from comment #3) > > This is a glibc bug > > I (obviously) disagree. > > , coming up with a set of weakref checks for gthr.h that > > would satisfy static linking of glibc and all possible combinations of > > included vs. non-included objects is impossible. > > If you call pthread_mutex_lock (or any other function) via weakref, then you > should ensure that the function is actually available. > > AFAICT, libgcc only calls a few pthread_* functions. Why is it hard to check > that *all* of them are present? Because it is very expensive. Each of those tests requires a dynamic relocation, GOT read every time it is checked, bloats the code size, etc.
[Bug libstdc++/87193] symbols in have inconsistent types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87193 --- Comment #3 from W E Brown --- Sorry; hadn't seen or recalled the note cited by comment 1. Agreed with comment 2 that this need not be a priority. My (admittedly hostile) experimental code caught it, so I thought to note it for the record. Thanks for confirming.
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #6 from Paul Pluzhnikov --- (In reply to Jakub Jelinek from comment #5) > Because it is very expensive. One impractical solution is to require '-pthread' on the compile and link line, and link a libgcc_mt that has non-weak references to pthread_* functions. This will force end users to finally build their programs with correct command line :-)
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #7 from Jakub Jelinek --- gthr.h is used heavily e.g. in libstdc++, so your solution doesn't really work at all.
[Bug libstdc++/77691] [7/8/9 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #24 from Jonathan Wakely ---
I think this would make the tests pass, so you could remove the xfail
directives:
--- a/libstdc++-v3/include/experimental/memory_resource
+++ b/libstdc++-v3/include/experimental/memory_resource
@@ -421,7 +421,11 @@ namespace pmr {
do_allocate(size_t __bytes, size_t __alignment) override
{
if (__alignment <= __guaranteed_alignment<_Alloc>::value)
- return _M_alloc.allocate(__bytes);
+ {
+ if (__bytes < __alignment)
+ __bytes = __alignment;
+ return _M_alloc.allocate(__bytes);
+ }
const _AlignMgr __mgr(__bytes, __alignment);
// Assume _M_alloc returns 1-byte aligned memory, so allocate enough
@@ -437,6 +441,8 @@ namespace pmr {
auto __ptr = static_cast(__p);
if (__alignment <= __guaranteed_alignment<_Alloc>::value)
{
+ if (__bytes < __alignment)
+ __bytes = __alignment;
_M_alloc.deallocate(__ptr, __bytes);
return;
}
[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182 --- Comment #3 from joseph at codesourcery dot com --- Host libbacktrace would need to use GCC's host zlib and target libbacktrace would need to use GCC's target zlib for the same target multilib (which would require appropriate dependencies to be added to cause a target zlib to be built; I think it used to be built for GCJ, but I don't see any current dependencies that would result in it being built).
[Bug sanitizer/87191] UBSan doesn't catch invalid pointer arithmetic outside known object bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87191 --- Comment #4 from Rich Felker --- Regarding ASan, absolutely, but this is a case that can be caught without heavy memory tracking machinery, and that seems to be documented as being caught by -fsanitize=object-size but isn't. In my particular case, the bug I hoped it would have caught but didn't was in musl libc, and I don't even have San runtime libraries that are musl compatible, much less the framework to run ASan *under* libc, which is very complex to get right.
[Bug libquadmath/87204] strtoflt128 produces different results for subnormals with -m32 and -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204 --- Comment #1 from joseph at codesourcery dot com --- There are lots of glibc strtod fixes that postdate the last merges of strtod code to libquadmath. I don't know if any of them are relevant to this issue, but merging in those fixes would seem a good idea before investigating this issue further.
[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737 --- Comment #4 from dave.anglin at bell dot net --- On 2018-09-03 10:57 AM, redi at gcc dot gnu.org wrote: > Could this be due to using alloca? The tests should not require a huge stack, > so either alloca isn't usable or maybe there's a bug causing an infinite > recursion. (gdb) r Starting program: /mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/libstdc++-v3/testsuite/14220.exe warning: Private mapping of shared library text was not specified by the executable; setting a breakpoint in a shared library which is not privately mapped will not work. See the HP-UX 11i v3 chatr manpage for methods to privately map shared library text. Pid 2143 received a SIGSEGV for stack growth failure. Possible causes: insufficient memory or swap space, or stack size exceeded maxssiz. Program received signal SIGSEGV, Segmentation fault. 0xc0270de8 in memmove () from /lib/pa20_64/libc.2 (gdb) bt #0 0xc0270de8 in memmove () from /lib/pa20_64/libc.2 #1 0xc05bba38 in std::ctype::do_widen ( __to=0x83fffdff0dd0 "1.", '0' , __hi=0x83fffdff0d9f "", __lo=0x83fffdff0da0 "1.", '0' , this=) at /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/locale_facets.h:1107 #2 std::ctype::widen ( __to=0x83fffdff0dd0 "1.", '0' , __hi=0x83fffdff0d9f "", __lo=0x83fffdff0da0 "1.", '0' , this=) at /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/locale_facets.h:908 #3 std::num_put > >::_M_insert_float (this=0x83fffdfe57a0, __s=..., __io=..., __fill=43 '+', __mod=, __v=1) at /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/locale_facets.tcc:1048 #4 0xc05bbe68 in std::num_put > >::do_put (this=, __s=, ---Type to continue, or q to quit--- __io=..., __fill=, __v=) at /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/locale_facets.tcc:1157 #5 0x40003794 in std::num_put > >::put (__v=1, __fill=43 '+', __io=..., __s=..., this=0x83fffdfe57a0) at /mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/22_locale/num_put/put/char/14220.cc:38 #6 test01 () at /mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/22_locale/num_put/put/char/14220.cc:38 #7 0x40003a74 in main () at /mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/22_locale/num_put/put/char/14220.cc:45 On the failing call to memmove, we have the following arguments: (gdb) p/x $r26 $1 = 0x83fffdff0dd0 (gdb) p/x $r25 $2 = 0x83fffdff0da0 (gdb) p/x $r24 $3 = 0x (gdb) frame 1 #1 0x83fffdfa0a38 in std::ctype::do_widen ( __to=0x83fffdff0dd0 "\200", __hi=0x83fffdff0d9f "", __lo=0x83fffdff0da0 "1.", '0' , this=) at /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/locale_facets.h:1107 1107 __builtin_memcpy(__to, __lo, __hi - __lo); (gdb) p __hi $4 = 0x83fffdff0d9f "" (gdb) p __lo $5 = 0x83fffdff0da0 "1.", '0' (gdb) p/x __hi - __lo $6 = 0x
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #8 from H.J. Lu --- Here is a very old proposal: https://groups.google.com/forum/#!msg/generic-abi/K1lUiNsmM6c/Pl9-7ngPVXIJ I am not sure if it will completely fix: https://sourceware.org/bugzilla/show_bug.cgi?id=5784
[Bug tree-optimization/87206] New: Suboptimal code generation for __atomic_compare_exchange_n followed by a comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87206
Bug ID: 87206
Summary: Suboptimal code generation for
__atomic_compare_exchange_n followed by a comparison
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
I tried to build the example #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080 on x86_64 and observed a
similar issue:
$ cat 1.c
extern void bar (int *);
void foo5(int *mem)
{
int oldval = 0;
__atomic_compare_exchange_n (mem, (void *) &oldval, 1,
1, __ATOMIC_ACQUIRE, __ATOMIC_RELAXED);
if (oldval != 0)
bar (mem);
}
$ gcc-8 -c 1.c -O3 -g
$ objdump -d 1.o
# skip
<_foo5>:
0: 31 c0 xor%eax,%eax
2: ba 01 00 00 00 mov$0x1,%edx
7: f0 0f b1 17 lock cmpxchg %edx,(%rdi)
b: 85 c0 test %eax,%eax
d: 75 01 jne10 <_foo5+0x10>
f: c3 retq
10: e9 00 00 00 00 jmpq 15 <_foo5+0x15>
We don't have to do "test %eax,%eax", because this information is already
available through ZF, which is set by CMPXCHG.
I wonder if it would be possible to come up with a common solution for all
architectures, including x86_64 and s390?
[Bug other/77609] __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 --- Comment #7 from Gabriel Rauter --- (In reply to Gabriel Rauter from comment #6) > This change breaks the .noinit section on avr which now gets set to PROGBTIS > because the section type is omitted. It should be NOBITS. .noinit regression fixed in binutils https://sourceware.org/bugzilla/show_bug.cgi?id=23570
