[Bug sanitizer/88400] address-sanitizer on the cpu with only one core, may deadlock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88400 --- Comment #4 from hhj --- (In reply to Andrew Pinski from comment #3) > Also this seems like it is an upstream issue too. This is how we handle it. When the parent's sched_priority isn't sam as the children's 1 If the parent's sched_priority is greater than the children's, raising the children's sched_priority. After register children, restore the children's sched_priority. 2 If children's sched_priority is greater than the parent's, raising the parent's sched_priority. After register children, restore the parent's sched_priority.
[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-07 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) > Well, the main issue is that the loop has two exits which is something the > vectorizer doesn't support (with a hard check). Jakub explains why that is > so. > > You could change the loop to sth like > > unsigned char *p = cur + pos; > int len = 0; > int diff_pos = __INT_MAX__; > while (++len != max) > if (p[len] != cur[len]) > diff_pos = len < diff_pos ? len : diff_pos; > return cur[diff_pos]; > > which then runs into a limitation recently reported (two dependent > reductions not recognized). Could GCC generate this version and select it at runtime if max is sufficiently large?
[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398 --- Comment #7 from Jakub Jelinek --- No, because that has different behavior. In particular, it reads all bytes from 0 to max - 1 from both arrays, rather than stopping at the first one. If both pointers are aligned the same modulo simd size, then it is in theory vectorizable just by loading both simd words, comparing all the individual bytes, if all of them compare equal, continue looping, otherwise e.g. in a scalar loop determine the exact one. Though, if they are different, it is harder, one simd word would need to be read in the previous iteration of the loop and not read in the current one until you prove that there isn't any difference. Essentially, you are looking for reimplementation of memcmp e.g. from glibc (like the C version in https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=string/memcmp.c;hb=HEAD ) just with the minor tweak that rather than returning the difference of the bytes you return the length of the common prefix of both strings and you don't have the guarantee memcmp has (that all bytes between 0 and max-1 are accessible). E.g. glibc x86_64 memcmp unrolled loop looks like: movdqu(%rdi,%rsi), %xmm0 pcmpeqb (%rdi), %xmm0 pmovmskb %xmm0, %edx subl $0x, %edx jnz L(neq) addq $16, %rdi repeated a couple of times, but that can be done this way only if both pointers % simd_size are the same (you can even use movdqa after scalar loop for alignment). If they aren't, you need to compare separately one set of bytes first and only if they are all equal you can read the next (aligned) word and in both cases you need to do the whole vector shifts. All in all, I'd say you want to have a function for this and implement it efficiently, rather than hoping the compiler will pattern match inefficient code and turn it into the smart thing for you, it is way too specialized thing.
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 --- Comment #5 from Jakub Jelinek --- Created attachment 45178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45178&action=edit gcc9-ia64-constexpr-virtual.patch Here is untested patch to fix all g++.dg/cpp2a/constexpr-virtual*.C failures, not sure if it is related or not. I don't have access to ia64 so can't really test this.
[Bug c++/88390] [9 regression] g++.dg/tree-prof/pr57451.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88390 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-07 Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- It's a missing cfi_window_save directive for the cold part of getData.
[Bug c++/88390] [9 regression] g++.dg/tree-prof/pr57451.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88390 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Investigating.
[Bug middle-end/88401] New: -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401
Bug ID: 88401
Summary: -Wshift-overflow only works for const variables
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Target Milestone: ---
Consider this program (1.cc):
#include
void foo ()
{
int32_t x = -32768;
x << 31;
const int32_t y = -32768;
y << 31;
}
GCC detects shift overflow on y, but not on x:
$ g++ -c 1.cc -Wshift-overflow=2 --std=c++11 -O3
1.cc: In function ‘void foo()’:
1.cc:9:5: warning: result of ‘(-32768 << 31)’ requires 47 bits to represent,
but ‘int’ only has 32 bits [-Wshift-overflow=]
y << 31;
~~^
It seems that very basic constant propagation would deduce x = -32768.
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 --- Comment #16 from Valeriy E. Ushakov --- (In reply to Eric Gallager from comment #15) > (In reply to Valeriy E. Ushakov from comment #11) > > Created attachment 44668 [details] > > Diff against gcc-6.4.0 > > > > This is essentially the same diff except gcc now provides its own > > HOST_WIDE_INT_C() macro, so the patch uses that instead of defining its own. > > can you please send it to the gcc-patches mailing list for review? This patch has been sitting in your bugtracker for 11 years. Anything I know about this bug is written in this bug report and swapped out of my active memory, so I cannot meaningfully answer any questions about that patch on gcc-patches@ other than by referring people to what's written here in this bug report. Why do I have to go through this strange ritual of taking this patch out of gcc's own bugtracker and sending it to gcc's own list for proposed patches? This is not some proposed change that I can meaningfully advocate (like a new feature or something). I.e. what that action is going to change from the standpoint of communication setup? As I see it, it can only make things worse b/c if I'm actually asked any questions I can't answer them, or someone replies to that patch only to the mailing list and I miss that reply (and it's not recorded here too). And then it will just look as my fault, not engaging in a proper discussion.
[Bug c++/87636] Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_demangle_type, d_bare_function_type, d_function_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87636 --- Comment #3 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886&root=gcc&view=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 --- Comment #5 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886&root=gcc&view=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 --- Comment #7 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886&root=gcc&view=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug demangler/87681] Recursive Stack Overflow within function d_name, d_encoding, and d_local_name in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87681 --- Comment #1 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886&root=gcc&view=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #12 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886&root=gcc&view=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #15 from Harald Anlauf --- (In reply to Jakub Jelinek from comment #14) > Author: jakub > Date: Thu Dec 6 10:28:31 2018 > New Revision: 266847 > > URL: https://gcc.gnu.org/viewcvs?rev=266847&root=gcc&view=rev This fixes the original testcase, but not the following variant, which crashes with a similar backtrace: MODULE mo_occ implicit none integer :: ncid contains function nf90_inquire_dimension(ncid, dimid, name, len) integer,intent( in) :: ncid, dimid character(*), optional, intent(out) :: name integer, optional, intent(out) :: len integer :: nf90_inquire_dimension end function nf90_inquire_dimension subroutine read_gpsro_netcdf () contains function dimlen (dim) integer ,intent(in) :: dim integer :: dimlen integer :: status integer :: dimids (10) status = nf90_Inquire_Dimension (ncid, dimids(dim), len=dimlen) end function dimlen end subroutine read_gpsro_netcdf end module mo_occ % gfc-trunk -c gfcbug152-v3.f90 gfcbug152-v3.f90:11:0: 11 | subroutine read_gpsro_netcdf () | internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'mem_ref' in use_pointer_in_frame, at tree-nested.c:267 0x5ed193 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../trunk/gcc/tree.c:9929 0xd44250 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../trunk/gcc/tree.h:3271 0xd44250 use_pointer_in_frame ../../trunk/gcc/tree-nested.c:267 0xd4a745 convert_local_reference_stmt ../../trunk/gcc/tree-nested.c:2327 0x9d8a56 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:568 0x9d8c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:51 0x9d8bb1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:631 0x9d8c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:51 0x9d8b11 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:595 0x9d8c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:51 0xd440c8 walk_body ../../trunk/gcc/tree-nested.c:703 0xd44118 walk_function ../../trunk/gcc/tree-nested.c:714 0xd44118 walk_all_functions ../../trunk/gcc/tree-nested.c:779 0xd4e094 lower_nested_functions(tree_node*) ../../trunk/gcc/tree-nested.c:3482 0x836330 cgraph_node::analyze() ../../trunk/gcc/cgraphunit.c:673 0x8397b9 analyze_functions ../../trunk/gcc/cgraphunit.c:1126 0x83a8a2 symbol_table::finalize_compilation_unit() ../../trunk/gcc/cgraphunit.c:2835
[Bug middle-end/63184] [7/8/9 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184 --- Comment #20 from Richard Biener --- Created attachment 45179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45179&action=edit patch This patch fixes the testcases but it comes at a cost without much visible benefit (trying 258098 expansions in a C,C++ bootstrap with just 4 hits, all in the same place).
[Bug middle-end/63184] [7/8/9 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184 --- Comment #21 from Richard Biener --- Created attachment 45180 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45180&action=edit reassoc patch The reassoc patch, not solving the issue in its own.
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
Jaydeep Chauhan changed:
What|Removed |Added
CC||jaydeepchauhan1494 at gmail
dot co
||m
--- Comment #10 from Jaydeep Chauhan ---
Hi,
For the below case fix is not working.
#include
struct param {
int a, b, c, d;
__m128i array[256];
};
struct param *p1;
void func(struct param *p, unsigned char *src, int *dst)
{
__m128i x = p1->array[*src];
*dst = _mm_cvtsi128_si32(x);
}
gcc generates for x86-64 with -O2:
func:
movzbl (%rsi), %eax
addq$1, %rax
salq$4, %rax
addqp1(%rip), %rax
movl(%rax), %eax
movl%eax, (%rdx)
ret
clang generates for x86_64 with -O2:
func:
movqp1(%rip), %rax
movzbl (%rsi), %ecx
shlq$4, %rcx
movl16(%rax,%rcx), %eax
movl%eax, (%rdx)
retq
[Bug target/86753] [9 Regression] gcc.target/aarch64/sve/vcond_[45].c fail after recent combine patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86753 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2018-12-07 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #5 from rsandifo at gcc dot gnu.org --- The PR is for tracking why the tests needed to be XFAILed. What the tests are looking for is still the preferred outcome, so I think we should keep the PR open until the XFAILs can be removed. The point of #c1 was that the combine patch that made the tests regress wasn't really at fault. We need more gimple stuff to do this properly.
[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #8 from Wilco ---
(In reply to Jiangning Liu from comment #0)
> For the small case below, GCC -O3 can't vectorize the small loop to do byte
> comparison in func2.
>
> void *malloc(long unsigned int);
> typedef struct {
> unsigned char *buffer;
> } data;
>
> static unsigned char *func1(data *d)
> {
> return d->buffer;
> }
>
> static int func2(int max, int pos, unsigned char *cur)
> {
> unsigned char *p = cur + pos;
> int len = 0;
> while (++len != max)
> if (p[len] != cur[len])
> break;
> return cur[len];
> }
>
> int main (int argc) {
> data d;
> d.buffer = malloc(2*argc);
> return func2(argc, argc, func1(&d));
> }
>
> At the moment, the following code is generated for this loop,
>
> 4004d4: 38616862ldrbw2, [x3,x1]
> 4004d8: 6b5fcmp w2, w0
> 4004dc: 54a1b.ne4004f0
> 4004e0: 38616880ldrbw0, [x4,x1]
> 4004e4: 6b01027fcmp w19, w1
> 4004e8: 91000421add x1, x1, #0x1
> 4004ec: 5441b.ne4004d4
>
> In fact, this loop can be vectorized by checking if the comparison size is
> aligned to SIMD register length. It may introduce run time overhead, but
> cost model could make decision on doing it or not.
The only optimization that can be done here is unrolling. For this kind of
string matching the number of bytes that match is will be small on average, so
even if vectorization was feasible, the startup overhead alone would kill
performance. With unrolling you can remove the comparison with max each
iteration and do 4 bytes per iteration like this:
loop4:
ldrbw2, [x3,4]!
ldrbw0, [x4,4]!
cmp w0, w2
bne exitloop1
ldrbw2, [x3,1]
ldrbw0, [x4,1]
cmp w0, w2
bne exitloop2
ldrbw2, [x3,2]
ldrbw0, [x4,2]
cmp w0, w2
bne exitloop3
ldrbw2, [x3,3]
ldrbw0, [x4,3]
cmp w0, w2
bne exitloop4
add x1, x1, 4
cmp x1, w19
blt loop4
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- Created attachment 45181 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45181&action=edit gcc9-pr88304.patch Untested fix for the #c15 bug (a different one from the originally reported).
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 Jakub Jelinek changed: What|Removed |Added Attachment #45178|0 |1 is obsolete|| --- Comment #6 from Jakub Jelinek --- Created attachment 45182 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45182&action=edit gcc9-pr87861.patch Updated patch, so that it doesn't fail to compile due to warning on non-ia64. Andreas, could you please bootstrap/regtest this?
[Bug demangler/85373] Ice in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85373 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Fixed with commit 266886.
[Bug demangler/85452] Stack-Overflow in nm-new / C++ name demangler (binuitils-2.30-15ubuntu1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85452 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed with commit 266886
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #11 from Jakub Jelinek ---
That is because e.g. on:
struct S { int a, b, c, d; };
struct T { struct S a; struct S b[256]; } *v;
int
foo (unsigned char *x)
{
return v->b[*x].a;
}
we have:
(insn 6 3 7 2 (set (reg/f:DI 88 [ v ])
(mem/f/c:DI (symbol_ref:DI ("v") [flags 0x2] ) [1 v+0 S8 A64])) "pr54589-3.c":7:18 66 {*movdi_internal}
(nil))
(insn 7 6 8 2 (set (reg:SI 89 [ *x_5(D) ])
(zero_extend:SI (mem:QI (reg/v/f:DI 86 [ x ]) [0 *x_5(D)+0 S1 A8])))
"pr54589-3.c":7:15 119 {*zero_extendqisi2}
(expr_list:REG_DEAD (reg/v/f:DI 86 [ x ])
(nil)))
(insn 8 7 9 2 (set (reg:DI 90 [ *x_5(D) ])
(sign_extend:DI (reg:SI 89 [ *x_5(D) ]))) "pr54589-3.c":7:18 128
{*extendsidi2_rex64}
(expr_list:REG_DEAD (reg:SI 89 [ *x_5(D) ])
(nil)))
(insn 9 8 10 2 (parallel [
(set (reg:DI 91)
(plus:DI (reg:DI 90 [ *x_5(D) ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "pr54589-3.c":7:18 191 {*adddi_1}
(expr_list:REG_DEAD (reg:DI 90 [ *x_5(D) ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 10 9 11 2 (parallel [
(set (reg:DI 92)
(ashift:DI (reg:DI 91)
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) "pr54589-3.c":7:18 518 {*ashldi3_1}
(expr_list:REG_DEAD (reg:DI 91)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 11 10 12 2 (parallel [
(set (reg/f:DI 93)
(plus:DI (reg/f:DI 88 [ v ])
(reg:DI 92)))
(clobber (reg:CC 17 flags))
]) "pr54589-3.c":7:18 191 {*adddi_1}
(expr_list:REG_DEAD (reg:DI 92)
(expr_list:REG_DEAD (reg/f:DI 88 [ v ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
(insn 12 11 17 2 (set (reg:SI 94 [ v.0_1->b[_3].a ])
(mem:SI (reg/f:DI 93) [2 v.0_1->b[_3].a+0 S4 A32])) "pr54589-3.c":7:18
67 {*movsi_internal}
(expr_list:REG_DEAD (reg/f:DI 93)
(nil)))
and combine would handle that fine if it tried to combine 9, 10, 11 -> 12
first, but unfortunately for this case it tries 6 -> 11 first and, if the
combination of everything doesn't simplify, we try to split it only into two
parts, which in this case isn't enough, we'd need to split those 4 instructions
into 3 (one to do the shift, one to do the v load and last to do the mem read
with the 16(reg1, reg2) addressing.
Unless the combiner grows the possibility to split into 3 functions, I'm afraid
this would need to be solved in machine reorg or something similar.
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589 --- Comment #12 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #11) > Unless the combiner grows the possibility to split into 3 functions, I'm I mean 3 instructions when trying to combine 4. > afraid this would need to be solved in machine reorg or something similar.
[Bug middle-end/88401] -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- It is a front-end warning, so there is no constant propagation possible. You can use -fsanitize=shift to detect this stuff at runtime.
[Bug demangler/85454] Multiple memory corruptions in objdump / C++ name demangler (binuitils-2.30-15ubuntu1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85454 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed with commit 266886.
[Bug other/86656] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 85454, which changed state. Bug 85454 Summary: Multiple memory corruptions in objdump / C++ name demangler (binuitils-2.30-15ubuntu1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85454 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug demangler/86664] Demangler segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86664 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/87620] NULL deref in iterate_demangle_function (117536819)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87620 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed by commit 266886.
[Bug c++/87636] Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_demangle_type, d_bare_function_type, d_function_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87636 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/87681] Recursive Stack Overflow within function d_name, d_encoding, and d_local_name in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87681 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Fixed by commit 266886.
[Bug target/88402] New: inefficient code generation for mask from CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
Bug ID: 88402
Summary: inefficient code generation for mask from CC
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For sth like
unsigned long foo (int a, int b)
{
return a < b ? -1ul : 0;
}
we produce at -O[23]
xorl%eax, %eax
cmpl%esi, %edi
setl%al
negq%rax
ret
(partial register stall?)
and at -O
cmpl%esi, %edi
setl%al
movzbl %al, %eax
negq%rax
while we could use sbbq %rax, %rax if the suggestion at
https://lwn.net/Articles/744257/ is correct.
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Nick Clifton --- Fixed by commit 266886
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 Nick Clifton changed: What|Removed |Added Status|WAITING |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #13 from Nick Clifton --- Fixed by commit 266886.
[Bug target/37637] Build fails with reserved constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37637 Matthias Klose changed: What|Removed |Added CC||doko at debian dot org --- Comment #2 from Matthias Klose --- Debian doesn't have any s390 hardware anymore. multilib builds on s390x-linux-gnu work, so maybe just close this issue.
[Bug other/86656] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 85122, which changed state. Bug 85122 Summary: Stack Overflow(Stack Exhaustion) in demangle related functions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/88403] New: [Mips,AArch64] The gcse prevents if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88403 Bug ID: 88403 Summary: [Mips,AArch64] The gcse prevents if-conversion Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dragan.mladjeno...@rt-rk.com Target Milestone: --- Created attachment 45183 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45183&action=edit mark.c If I compile the marck.c with aarch64-linux-gnu-gcc -O3 or mipsel-linux-gnu-gcc -mips32r6 -mbranch-cost=5 the inner if does not get transformed to use conditional moves. mips32r6 example: li $13,5000# 0x1388 $L4: ... subu$3,$2,$3 bgec$13,$3,$L3 addiu $2,$2,5000 sra $4,$2,31 <-- inserted by gcse $L3: muh $2,$2,$9 sra $2,$2,12 subu$2,$4,$2 ... The if-conversion fails because it refuses to speculate both instructions whose set regs are alive. If I use -fno-gcse or -ftree-loop-if-convert the problem disappears. Is there something that can be done here w/o resolving to ftree-loop-if-convert ? Tried: mipsel-linux-gnu-gcc --version mipsel-linux-gnu-gcc-7 (Debian 7.3.0-28) 7.3.0 xgcc --version xgcc (GCC) 9.0.0 20181203 (experimental)
[Bug demangler/85122] Stack Overflow(Stack Exhaustion) in demangle related functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/82890] Demangler segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82890 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed by commit 266886.
[Bug middle-end/88401] -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401 --- Comment #2 from Ulya --- (In reply to Jakub Jelinek from comment #1) > It is a front-end warning, so there is no constant propagation possible. > You can use -fsanitize=shift to detect this stuff at runtime. Ok, understood. Maybe someday it can be moved to middle-end.
[Bug middle-end/88401] -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401 Ulya changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Ulya --- The warning needs to be re-implemented in middle-end to be able to use constant propagation.
[Bug ipa/61159] __builtin_constant_p gives incorrect results with aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Martin Liška --- > Can the bug be marked as resolved? No, the Solaris/x86 problem persists.
[Bug middle-end/88401] -Wshift-overflow only works for const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401 --- Comment #4 from Jakub Jelinek --- That is not that easy, because what is considered invalid heavily depends on the FE (and standard version), e.g. the above is completely valid in C++20. Furthermore, warning too late in the middle-end could very well mean warning about stuff that is propagated into statements after jump threading etc. and that are dead and not something user actually wrote. As I said, if you want accurate diagnostics, use the runtime one.
[Bug bootstrap/87551] [9 regression] libgnat-9.so fails to link on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87551 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Jakub Jelinek --- > So fixed with r265025 ? That commit should have referenced this PR... Yes to both. I've now added the forgotten PR marker.
[Bug target/88402] inefficient code generation for mask from CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
I don't think you can use it in that case, you get it with:
unsigned long bar (unsigned int a, unsigned int b)
{
return a < b ? -1ul : 0;
}
which does something different:
cmpl%esi, %edi
sbbq%rax, %rax
ret
at -O2 as well as -O.
[Bug ipa/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #12 from Martin Jambor --- I have just posted the patch for review in: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00456.html With it the compile time of the testcase goes down from approximately 340 seconds to about 160 seconds (With -fno-ipa-cp -fno-inline the compile time is only 30 seconds, however) the relevant bits of-ftime-report -ftime-report-details are below: Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 1215 kB ( 0%) phase parsing : 1.07 ( 1%) 1.12 ( 38%) 2.20 ( 1%) 37151 kB ( 7%) phase opt and generate : 161.38 ( 99%) 1.85 ( 62%) 163.28 ( 99%) 469241 kB ( 92%) ... ipa function summary : 0.11 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 554 kB ( 0%) `- tree STMT verifier : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) `- loop init : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 11 kB ( 0%) `- tree SSA verifier : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 kB ( 0%) ... ipa cp : 0.12 ( 0%) 0.02 ( 1%) 0.10 ( 0%) 9656 kB ( 2%) `- tree STMT verifier : 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 kB ( 0%) `- alias stmt walking : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- tree SSA verifier : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 kB ( 0%) ... ipa icf: 2.98 ( 2%) 0.00 ( 0%) 2.99 ( 2%) 0 kB ( 0%) `- tree STMT verifier : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) `- tree SSA verifier : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- dominance computation : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) ... CFG verifier : 2.27 ( 1%) 0.00 ( 0%) 2.37 ( 1%) 0 kB ( 0%) ... df reaching defs : 1.59 ( 1%) 0.01 ( 0%) 1.59 ( 1%) 0 kB ( 0%) df live regs : 1.74 ( 1%) 0.00 ( 0%) 1.73 ( 1%) 0 kB ( 0%) df live&initialized regs : 5.32 ( 3%) 0.00 ( 0%) 5.37 ( 3%) 0 kB ( 0%) ... alias stmt walking : 3.19 ( 2%) 0.30 ( 10%) 3.35 ( 2%) 5 kB ( 0%) ... tree VRP : 36.88 ( 23%) 0.15 ( 5%) 37.00 ( 22%) 58212 kB ( 11%) `- tree SSA incremental: 0.10 ( 0%) 0.07 ( 2%) 0.19 ( 0%) 16219 kB ( 3%) `- CFG verifier: 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- repair loop structures : 0.01 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) `- tree operand scan : 0.09 ( 0%) 0.04 ( 1%) 0.14 ( 0%) 9616 kB ( 2%) `- tree SSA verifier : 0.10 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 0 kB ( 0%) `- loop init : 0.03 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 23 kB ( 0%) `- tree STMT verifier : 0.13 ( 0%) 0.00 ( 0%) 0.15 ( 0%) 0 kB ( 0%) tree Early VRP : 6.53 ( 4%) 0.00 ( 0%) 6.52 ( 4%) 1621 kB ( 0%) `- CFG verifier: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- repair loop structures : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- dominance computation : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- tree operand scan : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- tree SSA verifier : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) `- loop init : 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 39 kB ( 0%) `- tree STMT verifier : 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 kB ( 0%) tree FRE : 59.08 ( 36%) 0.69 ( 23%) 59.93 ( 36%) 1822 kB ( 0%) `- CFG verifier: 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 kB ( 0%) `- repair loop structures : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- dominance computation : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- tree SSA verifier : 0.08 ( 0%) 0.00 ( 0%) 0.08 ( 0%) 0 kB ( 0%) `- loop init : 0.06 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 kB ( 0%) `- alias stmt walkin
[Bug sanitizer/88404] New: [9 Regression] ICE (tree check) with -fsanitize=thread on Fortran2003 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88404 Bug ID: 88404 Summary: [9 Regression] ICE (tree check) with -fsanitize=thread on Fortran2003 code Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Simple test case (valid Fortran2003 code with unlimited polymorphism): program t type :: tString character(len=:), allocatable :: cs end type call test(getstr()) contains subroutine test(val) class(*), intent(in) :: val end subroutine function getstr() result(str) type(tString) :: str end function end gfortran versions 5 to 8 handle this well with -fsanitize=thread, but recent 9-trunk ICEs: during GIMPLE pass: tsan0 tsan_ice.f90:1:0: 1 | program t | internal compiler error: tree check: expected record_type or union_type or qual_union_type or array_type, have void_type in may_be_nonaddressable_p, at tree-ssa-loop-ivopts.c:2265 0x5c17c3 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /home/janus/github/gcc/trunk/gcc/tree.c:9757 0xdfc6d6 tree_check4(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code, tree_code) /home/janus/github/gcc/trunk/gcc/tree.h:3218 0xdfc6d6 may_be_nonaddressable_p(tree_node*) /home/janus/github/gcc/trunk/gcc/tree-ssa-loop-ivopts.c:2265 0xcb14ea instrument_expr /home/janus/github/gcc/trunk/gcc/tsan.c:190 0xcb23dd instrument_gimple /home/janus/github/gcc/trunk/gcc/tsan.c:729 0xcb23dd instrument_memory_accesses /home/janus/github/gcc/trunk/gcc/tsan.c:802 0xcb23dd tsan_pass /home/janus/github/gcc/trunk/gcc/tsan.c:854 0xcb23dd execute /home/janus/github/gcc/trunk/gcc/tsan.c:905
[Bug tree-optimization/88405] New: Missed DSE opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88405
Bug ID: 88405
Summary: Missed DSE opportunity
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
For the following code:
#define MATRIX_SIZE 512
static double a[MATRIX_SIZE][MATRIX_SIZE];
static double b[MATRIX_SIZE][MATRIX_SIZE];
static double c[MATRIX_SIZE][MATRIX_SIZE];
double
foo (void) {
double s;
int i, j, k;
/* Section A */
for (i = 0; i < MATRIX_SIZE; i++) {
for (j = 0; j < MATRIX_SIZE; j++) {
a[i][j] = (double)i * (double)j;
b[i][j] = (double)i / (double)(j+5);
}
}
/* Section B */
for (j = 0; j < MATRIX_SIZE; j++) {
for (i = 0; i < MATRIX_SIZE; i++) {
s = 0;
for (k = 0; k < MATRIX_SIZE; k++) {
s += a[i][k] * b[k][j];
}
c[i][j] = s;
}
}
s = 0.0; // (1)
#if 0
/* Section C */
for (i = 0; i < MATRIX_SIZE; i++) {
for (j = 0; j < MATRIX_SIZE; j++) {
s += c[i][j];
}
}
#endif
return s;
}
GCC does not manage to eliminate the code up to (1) and retains the expensive
Section A.
Clang manages to eliminate much more and produces:
foo:// @foo
// %bb.0: // %entry
orr w8, wzr, #0x200
.LBB0_1:// %vector.ph
// =>This Inner Loop Header: Depth=1
subsx8, x8, #1 // =1
b.ne.LBB0_1
// %bb.2: // %for.cond20.preheader.preheader
fmovd0, xzr
ret
on aarch64. This happens at -O3 as well as -O2 as well as other targets (occurs
also on x86)
[Bug go/88406] New: [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406 Bug ID: 88406 Summary: [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- Target: sparc*-sun-solaris2.10 Since the Go 1.11 merge, many (all?) 64-bit Solaris 10/SPARC execution tests FAIL with FAIL: cmd/go/internal/cache runtime: memory allocated by OS [18446744071360741376, 18446744071427850240) not in usable address space: base outside usable address space fatal error: memory reservation exceeds address space limit runtime stack: :0 :0 :0 :0 :0 :0 :0 :0 [...] :0 main /vol/gcc/src/hg/trunk/local/libgo/runtime/go-main.c:57 _start :0 Solaris 11/SPARC and Solaris/x86 are fine, though.
[Bug go/88406] [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214 --- Comment #7 from Martin Jambor --- I have posted the patch to the mailing list for review: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00460.html
[Bug libgomp/88407] [OpenACC] Correctly handle unseen async-arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88407 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-07 Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1
[Bug libgomp/88407] New: [OpenACC] Correctly handle unseen async-arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88407 Bug ID: 88407 Summary: [OpenACC] Correctly handle unseen async-arguments Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: openacc, patch Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: cltang at gcc dot gnu.org, jakub at gcc dot gnu.org Target Milestone: --- The current implementation of "acc_async_test" does not conform to the specification, and I've now generally asked the OpenACC technical committee about the intended behavior of 'OpenACC "wait" directive/clause/runtime API call with async-argument not used before'. This will need to be fixed on all release branches.
[Bug c++/86669] [7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Dec 7 15:20:04 2018 New Revision: 266893 URL: https://gcc.gnu.org/viewcvs?rev=266893&root=gcc&view=rev Log: PR c++/86669 * call.c (make_temporary_var_for_ref_to_temp): Call pushdecl even for automatic vars. * g++.dg/cpp0x/initlist105.C: New test. * g++.dg/cpp0x/initlist106.C: New test. * g++.dg/other/pr86669.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist105.C trunk/gcc/testsuite/g++.dg/cpp0x/initlist106.C trunk/gcc/testsuite/g++.dg/other/pr86669.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug target/86753] [9 Regression] gcc.target/aarch64/sve/vcond_[45].c fail after recent combine patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86753 --- Comment #6 from Jeffrey A. Law --- Sorry, my misunderstanding. I thought you had indicated the resulting code was better.
[Bug target/85593] [7/8 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 --- Comment #15 from Jakub Jelinek --- ARM maintainers - feel free to add some ARM test for naked vs. IPA-RA too.
[Bug fortran/88377] ICE in gfc_omp_clause_copy_ctor, at fortran/trans-openmp.c:614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88377 --- Comment #3 from Jakub Jelinek --- Fixed on GCC trunk so far.
[Bug tree-optimization/88367] [9 Regression] -fno-delete-null-pointer-checks doesn't work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88367 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Hopefully fixed now.
[Bug c++/87506] [7/8 Regression] ICE with inherited constexpr constructor with const argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87506 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] ICE with |[7/8 Regression] ICE with |inherited constexpr |inherited constexpr |constructor with const |constructor with const |argument|argument --- Comment #4 from Jakub Jelinek --- Fixed for GCC9+ so far.
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 --- Comment #7 from Jeffrey A. Law --- I've still got my ia64 beaker box from yesterday provisioned. I'll spin your patch.
[Bug c++/86669] [7/8 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 regression] Complete |[7/8 regression] Complete |object constructor clone|object constructor clone |omits length for a c++11|omits length for a c++11 |braced initialiser |braced initialiser --- Comment #8 from Jakub Jelinek --- Fixed for GCC9+ so far.
[Bug target/37637] Build fails with reserved constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37637 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Eric Gallager --- (In reply to Matthias Klose from comment #2) > Debian doesn't have any s390 hardware anymore. multilib builds on > s390x-linux-gnu work, so maybe just close this issue. OK.
[Bug target/88402] inefficient code generation for mask from CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- It's possible to change signed comparison to unsigned by rotating integer domain by half, i.e. foo(a, b) == bar(a^0x8000, b^0x8000) but this increases register pressure if a and b are not dead after the comparison.
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #19 from Eric Gallager --- (In reply to Andrew Pinski from comment #18) > > 1. build and install Glibc --prefix=/tmp/foo > > Since glibc is not able to build this way any more, I doubt this can be > supported. OK, I guess I will actually close it then after all.
[Bug target/88408] New: [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408
Bug ID: 88408
Summary: [9 regression] r266868 breaks
gcc.target/powerpc/undef-bool-2.c on powerpc64 LE
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/undef-bool-2.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -std=c11 -DNO_WARN_X86_INTRINSICS -mvsx -S -o
undef-bool-2.s
In file included from
/home/seurer/gcc/build/gcc-test2/gcc/include/xmmintrin.h:79,
from
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/undef-bool-2.c:10:
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h: In function
'_mm_packs_pu16':
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:19: error: 'vector'
undeclared (first use in this function); did you mean 'vec_or'?
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:19: note: each
undeclared identifier is reported only once for each function it appears in
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:25: error: expected
')' before 'unsigned'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:41: error: expected
')' before 'vm1'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:233:25: error: expected
')' before 'vector'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:233:3: error: can't
convert a vector of type '__vector signed short' {aka 'const __vector(8) short
int'} to type 'int' which has different size
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/undef-bool-2.c: At
top level:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/undef-bool-2.c:12:1:
error: unknown type name 'bool'
compiler exited with status 1
PASS: gcc.target/powerpc/undef-bool-2.c (test for errors, line 12)
FAIL: gcc.target/powerpc/undef-bool-2.c (test for excess errors)
Excess errors:
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:19: error: 'vector'
undeclared (first use in this function); did you mean 'vec_or'?
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:25: error: expected
')' before 'unsigned'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:231:41: error: expected
')' before 'vm1'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:233:25: error: expected
')' before 'vector'
/home/seurer/gcc/build/gcc-test2/gcc/include/mmintrin.h:233:3: error: can't
convert a vector of type '__vector signed short' {aka 'const __vector(8) short
int'} to type 'int' which has different size
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #21 from Wilco --- (In reply to Rainer Orth from comment #20) > The new testcase also FAILs on sparc-sun-solaris2.11 (both 32 and 64-bit): > > +FAIL: gcc.c-torture/execute/pr64242.c -O2 execution test > +FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto execution test > +FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto -flto-partition=none > execution test > +FAIL: gcc.c-torture/execute/pr64242.c -O3 -g execution test > +FAIL: gcc.c-torture/execute/pr64242.c -Os execution test > > Thread 2 received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1 (LWP 1)] > 0x0008 in ?? () > (gdb) where > #0 0x0008 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > Single-stepping, I find that this happens at the very end of main: > > 1: x/i $pc > => 0x10de4 : return %i7 + 8 > (gdb) > 0x00010de8 in main () > at > /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/pr64242.c:50 > 50return 0; > 1: x/i $pc > => 0x10de8 : nop > (gdb) > 0x0008 in ?? () > 1: x/i $pc > => 0x8: > > Obviously the stack is corrupted beyond repair. I tried to avoid this by > replacing the return 0 with exit (0) to no avail. My latest patch detects this stack corruption with 100% certainty again, see https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00459.html. However sparc has a custom nonlocal_goto MD pattern which would need fixing too.
[Bug tree-optimization/88259] vectorization failure for a typical loop for getting max value and index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88259 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > The vectorizer does not like > >[local count: 955630224]: > # best_i_25 = PHI > # best_26 = PHI > # i_27 = PHI > _1 = (long unsigned int) i_27; > _2 = _1 * 4; > _3 = data_18(D) + _2; > _4 = *_3; > best_i_11 = _4 <= best_26 ? best_i_25 : i_27; > best_13 = MAX_EXPR <_4, best_26>; > i_20 = i_27 + 1; > if (n_17(D) > i_20) > > because for the best MAX reduction we have an additional use of the > reduction value in the index reduction. This combination isn't > magically supported even though in isolation both cases are. > > t.c:4:5: note: Analyze phi: best_26 = PHI > t.c:4:5: missed: reduction used in loop. > t.c:4:5: missed: Unknown def-use cycle pattern. > t.c:4:5: note: Analyze phi: best_i_25 = PHI best_i_16(D)(18)> > t.c:4:5: note: detected reduction: need to swap operands: best_i_11 = _4 > > best_26 ? i_27 : best_i_25; > t.c:4:5: note: Detected reduction. > > if we'd been lucky and had analyzed best_i_25 before best_26 then we could > probably special-case the case of "reduction used in loop" when that appears > in other reductions. In general that's of course still not valid I think. Yeah. Disabling the check for uses in the loop: /* If this isn't a nested cycle or if the nested cycle reduction value is used ouside of the inner loop we cannot handle uses of the reduction value. */ if ((!nested_in_vect_loop || inner_loop_of_double_reduc) && (nlatch_def_loop_uses > 1 || nphi_def_loop_uses > 1)) gives us something like the vector body we want, modulo some inefficiency: .L4: ldr q4, [x2], 16 mov v3.16b, v2.16b add v2.4s, v2.4s, v6.4s cmgev5.4s, v0.4s, v4.4s cmp x3, x2 smaxv0.4s, v0.4s, v4.4s bif v1.16b, v3.16b, v5.16b bne .L4 where v0.4s ends up containing the maximum for each individual lane and v1.s contains the best_i associated with each member of v0.4s. We "just" then need to make the epilogue do the right thing with this information. Hacking out the condition above (obviously an invalid thing to do) sets "best" to the maximum of v0.s (good) but also sets "best_i" to the maximum of v1.s (bad). We need to restrict the maximum of v1.s to lanes of v0.s that contain "best" (i.e. the reduction result of v0.s): dupv2.4s, best cmpeq v2.4s, v2.4s, v0.4s andv1.4s, v1.4s, v2.4s and only then take the maximum of v1.4s. This requires "best" to come from a reassociatve conditional reduction and would require the "best_i" reduction to be marked as dependent on the "best" reduction. Might end up being a bit messy, since we'd have to be careful to retain the uses check above for all other cases.
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 --- Comment #8 from Jeffrey A. Law --- We certainly get further with your patch -- we fail qsort checking during the stage2 build, but that's nothing new. ia64 has run afoul of the qsort checking since the day qsort checking was introduced. I'll hack around it and let the bootstrap continue.
[Bug rtl-optimization/88349] [9 regression][MIPS] Redundant store instructions generated start with r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88349 --- Comment #2 from Vladimir Makarov --- Author: vmakarov Date: Fri Dec 7 16:08:17 2018 New Revision: 266894 URL: https://gcc.gnu.org/viewcvs?rev=266894&root=gcc&view=rev Log: 2018-12-07 Vladimir Makarov PR rtl-optimization/88349 * ira-costs.c (record_operand_costs): Check bigger reg class on NO_REGS. 2018-12-07 Vladimir Makarov PR rtl-optimization/88349 * gcc.target/mips/pr88349.c: New. Added: trunk/gcc/testsuite/gcc.target/mips/pr88349.c Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c trunk/gcc/testsuite/ChangeLog
[Bug target/88271] Omit test instruction after add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271 --- Comment #9 from Daniel Fruzynski --- I have idea about alternate approach to this. gcc could try to look for relations between loop control statement, and other statements which modify variables used in that control statement. With such knowledge it could try to reorganize code to better optimize it. This approach would eliminate randomness here.
[Bug other/88409] New: [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Bug ID: 88409 Summary: [9 Regression] FAIL at line 4429, options --format=gnu-v3: Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: nickc at redhat dot com Target Milestone: --- r266886 caused: ./test-demangle < /export/gnu/import/git/sources/gcc/libiberty/testsuite/demangle-expected FAIL at line 4429, options --format=gnu-v3: in: _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRNS2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateILNS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6ParserIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ_5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_10Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_ELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4TypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ out: (null)
[Bug target/88408] [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408 seurer at gcc dot gnu.org changed: What|Removed |Added Target|powerpc64-unknown-linux-gnu |powerpc64*-unknown-linux-gn ||u Build|powerpc64le-unknown-linux-g |powerpc64*-unknown-linux-gn |nu |u --- Comment #1 from seurer at gcc dot gnu.org --- Also fails on BE after further testing.
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Nick Clifton --- Created attachment 45184 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45184&action=edit Proposed patch *sigh* Yes, I forgot to run the libiberty testsuite, and of course there is one test that actually breaches the demangling limit. The attached patch resolves the problem by adding a --no-recurse-limit option to the demangler testser and then using it for the problematic test case. I felt that this was a better solution than raising the recursion limit, as it means that the limit detecting code will actually be exercised by the testsuite. Currently waiting for review of the patch...
[Bug target/88408] [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408 --- Comment #2 from pc at gcc dot gnu.org --- Author: pc Date: Fri Dec 7 16:32:34 2018 New Revision: 266895 URL: https://gcc.gnu.org/viewcvs?rev=266895&root=gcc&view=rev Log: [rs6000] mmintrin.h: fix use of "vector" A recent patch inadvertently added the use of "vector" to mmintrin.h when all such uses should be "__vector". [gcc] 2018-12-07 Paul A. Clarke PR target/88408 * config/rs6000/mmintrin.h (_mm_packs_pu16): Correctly use "__vector". Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/mmintrin.h
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-07 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- (In reply to Nick Clifton from comment #1) > Created attachment 45184 [details] > Proposed patch > > *sigh* Yes, I forgot to run the libiberty testsuite, and of course > there is one test that actually breaches the demangling limit. > > The attached patch resolves the problem by adding a --no-recurse-limit > option to the demangler testser and then using it for the problematic > test case. I felt that this was a better solution than raising the > recursion limit, as it means that the limit detecting code will actually > be exercised by the testsuite. > > Currently waiting for review of the patch... This will cause a regression since this input will fail now.
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
Nick Clifton changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Nick Clifton ---
(In reply to H.J. Lu from comment #2)
Hi H.J.
> > The attached patch resolves the problem by adding a --no-recurse-limit
> > option to the demangler testser and then using it for the problematic
> > test case. I felt that this was a better solution than raising the
> > recursion limit, as it means that the limit detecting code will actually
> > be exercised by the testsuite.
> This will cause a regression since this input will fail now.
Umm, sorry ? The change means that the old behaviour of the demangler
is restored. Ie the recursion limit is not enforced, and thus the test
will behave exactly as it used to do.
Unless you mean that there would be a problem if the test input (or
something similar) is ever generated by the compilation of a real-world
program. In which case I agree, there would be a problem. But are you
ever going to get a real-world mangled version of:
modc::parser::ParserRef::Parser::Style>
>
> >::InputType,
modc::parser::MaybeRef&&)#21}>::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>::Parser > > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>
>::Parser::Style> > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>,
modc::astParser::LocatedParser
> > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >, false> >::Type>
modc::parser::sequence
>,
modc::parser::OptionalParser::Parser > > >,
modc::astParser::LocatedParser
>::Parser::Style> > >,
modc::parser::SequenceParser,
modc::astParser::LocatedParser
> > >,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >, false>
>(modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}&&,
(modc::parser::ExtractParserType
> >&&)...)
I would have thought that that would be extremely unlikely. Am I wrong ?
[Bug rtl-optimization/88349] [9 regression][MIPS] Redundant store instructions generated start with r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88349 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed by Vlad's commit on the trunk
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #4 from H.J. Lu --- (In reply to Nick Clifton from comment #3) > (In reply to H.J. Lu from comment #2) > > Hi H.J. > > > > The attached patch resolves the problem by adding a --no-recurse-limit > > > option to the demangler testser and then using it for the problematic > > > test case. I felt that this was a better solution than raising the > > > recursion limit, as it means that the limit detecting code will actually > > > be exercised by the testsuite. > > > This will cause a regression since this input will fail now. > > Umm, sorry ? The change means that the old behaviour of the demangler > is restored. Ie the recursion limit is not enforced, and thus the test > will behave exactly as it used to do. > > Unless you mean that there would be a problem if the test input (or > something similar) is ever generated by the compilation of a real-world > program. In which case I agree, there would be a problem. But are you > ever going to get a real-world mangled version of: > > I am expecting that [hjl@gnu-cfl-1 libiberty]$ c++filt _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRNS2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateILNS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6ParserIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ_5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_10Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_ELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4TypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ continues to work. Does it work with your patch?
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #5 from Nick Clifton --- (In reply to H.J. Lu from comment #4) > I am expecting that > > [hjl@gnu-cfl-1 libiberty]$ c++filt > _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRN > S2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateIL > NS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6Par > serIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ > _5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ > ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_1 > 0Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EE > EEELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4T > ypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ > > continues to work. Does it work with your patch? No. But "c++filt -r " will work. Is that string an example of a real world mangled symbol name, or was it just invented to test the demangler ?
[Bug target/88408] [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408 pc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-07 CC||pc at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pc at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/88408] [9 regression] r266868 breaks gcc.target/powerpc/undef-bool-2.c on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408 pc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from pc at gcc dot gnu.org --- Fix checked in, per comment #2
[Bug libgomp/87995] [9 regression] libgomp.c/../libgomp.c-c++-common/cancel-taskgroup-3.c fails consistently after r265930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87995 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 45185 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45185&action=edit gcc9-pr87995.patch Ah, testsuite issue and one needs more than 64 threads for that.
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 --- Comment #9 from Jeffrey A. Law --- Jakub -- with your patch and qsort checking hacked off I got a successful ia64 bootstrap.
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #6 from H.J. Lu --- (In reply to Nick Clifton from comment #5) > (In reply to H.J. Lu from comment #4) > > > I am expecting that > > > > [hjl@gnu-cfl-1 libiberty]$ c++filt > > _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRN > > S2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateIL > > NS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6Par > > serIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ > > _5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ > > ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_1 > > 0Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EE > > EEELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4T > > ypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ > > > > continues to work. Does it work with your patch? > > No. > > But "c++filt -r " will work. > > Is that string an example of a real world mangled symbol name, or was it just > invented to test the demangler ? It came from the fix for https://sourceware.org/bugzilla/show_bug.cgi?id=14065
[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496 --- Comment #10 from Peter Bergner --- Author: bergner Date: Fri Dec 7 17:33:55 2018 New Revision: 266899 URL: https://gcc.gnu.org/viewcvs?rev=266899&root=gcc&view=rev Log: gcc/ PR target/87496 * config/rs6000/rs6000.c (rs6000_option_override_internal): Disallow -mabi=ieeelongdouble and -mabi=ibmlongdouble without -mlong-double-128. Do not error for -mabi=ibmlongdouble and no ISA 2.06 support. * doc/invoke.texi: Document -mabi=ibmlongdouble and -mabi=ieeelongdouble require -mlong-double-128. gcc/testsuite/ PR target/87496 * gcc.target/powerpc/pr87496.c: Rename from this... * gcc.target/powerpc/pr87496-1.c: ...to this. Update comment. * gcc.target/powerpc/pr87496-2.c: New test. * gcc.target/powerpc/pr87496-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr87496-1.c - copied, changed from r266898, trunk/gcc/testsuite/gcc.target/powerpc/pr87496.c trunk/gcc/testsuite/gcc.target/powerpc/pr87496-2.c trunk/gcc/testsuite/gcc.target/powerpc/pr87496-3.c Removed: trunk/gcc/testsuite/gcc.target/powerpc/pr87496.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #7 from Ian Lance Taylor --- It looks like that was a real symbol from a real program. What happens if we double the recursion limit?
[Bug target/88316] numerous big-endian issues with compatibility implementations of vector intrinsics for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88316 --- Comment #4 from pc at gcc dot gnu.org --- SSSE3 is still broken. Working on it...
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589 --- Comment #13 from Segher Boessenkool --- Yeah, that's not going to happen. Will it help to do some define_split or define_insn_and_split for this?
[Bug rtl-optimization/69633] [7/8/9 Regression] Redundant move is generated after r228097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #13 from Jeffrey A. Law --- >From my reading, it looks like we do worse now than in previous releases. Things look OK going into IRA. The IRA allocations are different, but I haven't analyzed in any detail why and if one is inherently better than the other. LRA inserts more reloads/copies on the trunk than we did way back in r228097.
[Bug target/67288] [7/8/9 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #15 from Jeffrey A. Law --- I agree that the data combine would need comes from a different block. But ISTM that there's a dominance relationship we could exploit here. Specifically blocks 2 & 3 are a class extended basic block. Information generated in bb2 (or on the edge bb2->bb3) may still be available in bb3. I don't think we're set up to exploit extended blocks in combine, but that may be something worth exploring.
[Bug c++/88410] New: internal compiler error: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410 Bug ID: 88410 Summary: internal compiler error: output_operand: invalid expression as operand Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: notorca at gmail dot com Target Milestone: --- Created attachment 45186 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45186&action=edit Preprocessed source to reproduce error I've got ../../runtime/vm/raw_object_fields.cc:218:1: internal compiler error: output_operand: invalid expression as operand when trying to build https://github.com/dart-lang/sdk Preprocessed source is attached. Build command is: g++ -MMD -MF x86/obj/runtime/vm/libdart_vm_nosnapshot_with_precompiler.raw_object_fields.o.d -D_FORTIFY_SOURCE=2 -DNDEBUG -DTARGET_ARCH_ARM -DTARGET_ARCH_ARM_6 -DNDEBUG -DDART_USE_TCMALLOC -DTARGET_OS_LINUX -DDART_NO_SNAPSHOT -DDART_PRECOMPILER -I../../runtime -I../.. -Ix86/gen -I../../runtime/include -I../../third_party/tcmalloc/gperftools/src -m32 -msse2 -mfpmath=sse -fno-exceptions -pthread -Wendif-labels -Wno-missing-field-initializers -Wno-unused-parameter -fdebug-prefix-map=/home/lorca/dart/sdk=../.. -no-canonical-prefixes -O3 -fno-ident -fdata-sections -ffunction-sections -g3 -ggdb3 -Wno-unused-parameter -Wnon-virtual-dtor -Wvla -Wno-conversion-null -Woverloaded-virtual -Wno-comments -g3 -ggdb3 -fno-rtti -fno-exceptions -O3 -fvisibility-inlines-hidden -fno-omit-frame-pointer -std=gnu++11 -fno-rtti -fno-exceptions -c preprocessed.cc Reproduces on gcc version 8.2.0 (Ubuntu 8.2.0-7ubuntu1) and gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
[Bug target/67288] [7/8/9 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 --- Comment #16 from Segher Boessenkool --- Many things in combine assume that they can move an earlier insn to later, if none of the registers it uses is set in the intermediate insns (etc.) This isn't correct if you make combine work on EBBs. Keeping the reg_stat info based on dominance relations doesn't work the way things are set up now. I have long wished for a dataflow problem that would compute known 0/1/ext bits, or value ranges, etc. Ideally this can replace reg_stat completely. This would be both more powerful and simpler and much less problematic code :-)
[Bug libfortran/88411] New: [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 Bug ID: 88411 Summary: [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gmx dot de Target Milestone: --- Created attachment 45187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45187&action=edit Compile with -fopenmp, run with OMP_NUM_THREAD=2 or higher. The attached code crashes randomly with 9.0 trunk gfortran when compiled with -fopenmp and running with 2 or more threads: At line 22 of file gfcbug153.f90 (unit = 10, file = 'file2.dat') Fortran runtime error: Write exceeds length of DIRECT access record Error termination. Backtrace: #0 0x7fc02792019d in write_buf at ../../../trunk/libgfortran/io/transfer.c:906 #1 0x7fc027920200 in unformatted_write at ../../../trunk/libgfortran/io/transfer.c:1198 #2 0x40117f in gfcbug153 at /work/dwd/git/dace_code/gfcbug153.f90:22 #3 0x401302 in main at /work/dwd/git/dace_code/gfcbug153.f90:25 Running the code under valgrind prints lots of ==30672== Thread #1: lock order "0x52BF360 before 0x647FBF0" violated ==30672== ==30672== Observed (incorrect) order is: acquisition of lock at 0x647FBF0 ==30672==at 0x4C3291C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F7D1: __gthread_mutex_trylock (gthr-default.h:757) ==30672==by 0x506F7D1: get_gfc_unit (unit.c:380) ==30672==by 0x505C462: _gfortran_st_close (close.c:64) ==30672==by 0x4012CB: MAIN__ (gfcbug153.f90:24) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== ==30672== followed by a later acquisition of lock at 0x52BF360 ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x507043B: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x507043B: close_unit_1 (unit.c:735) ==30672==by 0x4012CB: MAIN__ (gfcbug153.f90:24) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== ==30672== Required order was established by acquisition of lock at 0x52BF360 ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F73C: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x506F73C: get_gfc_unit (unit.c:332) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400F82: MAIN__ (gfcbug153.f90:20) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== ==30672== followed by a later acquisition of lock at 0x647FBF0 ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F6A9: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x506F6A9: insert_unit (unit.c:244) ==30672==by 0x506F8C7: get_gfc_unit (unit.c:356) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400F82: MAIN__ (gfcbug153.f90:20) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== ==30672== Lock at 0x52BF360 was first observed ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F73C: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x506F73C: get_gfc_unit (unit.c:332) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400A96: MAIN__ (gfcbug153.f90:11) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== Address 0x52bf360 is 0 bytes inside data symbol "_gfortrani_unit_lock" ==30672== ==30672== Lock at 0x647FBF0 was first observed ==30672==at 0x4C3273C: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x506F6A9: __gthread_mutex_lock (gthr-default.h:748) ==30672==by 0x506F6A9: insert_unit (unit.c:244) ==30672==by 0x506F8C7: get_gfc_unit (unit.c:356) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400F82: MAIN__ (gfcbug153.f90:20) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== Address 0x647fbf0 is 224 bytes inside a block of size 752 alloc'd ==30672==at 0x4C31645: calloc (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==30672==by 0x4E61C42: _gfortrani_xcalloc (memory.c:83) ==30672==by 0x506F667: insert_unit (unit.c:233) ==30672==by 0x506F8C7: get_gfc_unit (unit.c:356) ==30672==by 0x50678E8: _gfortran_st_open (open.c:880) ==30672==by 0x400F82: MAIN__ (gfcbug153.f90:20) ==30672==by 0x401302: main (gfcbug153.f90:25) ==30672== Block was alloc'd by thread #1 etc.
[Bug target/88402] inefficient code generation for mask from CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
--- Comment #3 from Alexander Monakov ---
However, this may be worthwhile when one of operands is an immediate, as in
that case there's no register pressure increase, and the xor just mutates the
immediate.
Essentially, we'd change e.g.
(signed)a < 0xabcd ? -1ul : 0
to
(a^0x8000) < 0x8000abcd ? -1ul : 0
and emit a xorl/cmpl/sbbq sequence, plus a mov if a remains live.
Not for 64-bit operands though, where the 64-bits immediates would be costly.
But unfortunately today we don't manage to use the cmp-sbb trick for unsigned
comparison against an immediate, i.e. for
unsigned long baz (unsigned int a)
{
return a < 123 ? -1ul : 0;
}
we emit
xorl%eax, %eax
cmpl$122, %edi
setbe %al
negq%rax
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 --- Comment #1 from Harald Anlauf --- Further data points: - removing the asynchronous='yes' for the first OPEN has no effect, - removing the asynchronous='yes' for the second OPEN makes the problem disappear
[Bug fortran/71860] [7/8/9 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #5 from Harald Anlauf --- Cannot reproduce with 9-trunk rev. 266866, nor gfortran 8.2.1. Also works for me with: GNU Fortran (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812] Fixed?
[Bug fortran/87449] -Wunused-variable and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87449 Martin Diehl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Martin Diehl --- It appears that b does not need to be defined for associate, so program test implicit none real :: a = 5 associate(b => a) write(6,*) b end associate end program is a valid program where b is only defined within the associate construct and no warning appears
