[Bug tree-optimization/88975] ICE: Segmentation fault (in dominated_by_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88975 Arseny Solokha changed: What|Removed |Added Known to fail||10.0, 9.3.0 Summary|ICE: Segmentation fault (in |ICE: Segmentation fault (in |verify_ssa or gimple_code) |dominated_by_p) --- Comment #2 from Arseny Solokha --- Only the testcase from comment 1 fails for me now, as of gcc-10.0.1-alpha20200315 snapshot (g:9d74caf21be7025db8fef997e87ebf3b85acaf4a).
[Bug rtl-optimization/94026] combine missed opportunity to simplify comparisons with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #4 from Fei Yang ---
(In reply to Fei Yang from comment #0)
> Created attachment 47966 [details]
> proposed patch to fix this issue
>
> Simple test case:
> int
> foo (int c, int d)
> {
> int a = (c >> d) & 7;
>
> if (a >= 2) {
> return 1;
> }
>
> return 0;
> }
>
> Compile option: gcc -S -O2 test.c
>
>
> On aarch64, GCC trunk emits 4 instrunctions:
> asr w0, w0, 8
> tst w0, 6
> csetw0, ne
> ret
>
> which can be further simplified into:
> tst x0, 1536
> csetw0, ne
> ret
>
> We see the same issue on other targets such as i386 and x86-64.
>
> Attached please find proposed patch for this issue.
The previously posted test case is not correct.
Test case should be:
int fifth (int c)
{
int a = (c >> 8) & 7;
if (a >= 2) {
return 1;
} else {
return 0;
}
}
[Bug other/94182] Document -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182
--- Comment #3 from Roland Illig ---
(In reply to Andrew Pinski from comment #2)
> Considering it is documented in another place where char is signed or
> unsigned. I don't know if this needs to change.
Given only the compiler warning about "char subscript", how could I possibly
get to the documentation you linked?
> int demo(char ch, int *data) {
> return data[ch];
> }
When I try to compile this code, I get:
> bad.c:2:16: warning: array subscript has type 'char' [-Wchar-subscripts]
>From there I can look up the documentation of that command line option. But how
could I get from there to your documentation? And, considering an _average_ GCC
user (instead of an active GCC developer), would I have a chance of
understanding the underlying problem and fixing it correctly? The GCC
documentation should at least try to educate the reader a bit.
[Bug tree-optimization/94125] [9/10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125 --- Comment #8 from CVS Commits --- The master branch has been updated by Bin Cheng : https://gcc.gnu.org/g:e4e9a59105a81cdd6c1328b0a5ed9fe4cc82840e commit r10-7184-ge4e9a59105a81cdd6c1328b0a5ed9fe4cc82840e Author: Bin Cheng Date: Mon Mar 16 11:09:14 2020 +0800 Update post order number for merged SCC. Function loop_distribution::break_alias_scc_partitions needs to compute SCC with runtime alias edges skipped. As a result, partitions could be re-assigned larger post order number than SCC's precedent partition and distributed before the precedent one. This fixes the issue by updating the merged partition to the minimal post order in SCC. gcc/ PR tree-optimization/94125 * tree-loop-distribution.c (loop_distribution::break_alias_scc_partitions): Update post order number for merged scc. gcc/testsuite/ PR tree-optimization/94125 * gcc.dg/tree-ssa/pr94125.c: New test.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #36 from Segher Boessenkool --- The kernel jumps back to an instruction *before* the syscall?!? (I do not want to know about that any more, then, I am sure :-) )
[Bug c++/94186] New: compiler incorrectly accepts a requires clause with predicate of non-bool type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94186
Bug ID: 94186
Summary: compiler incorrectly accepts a requires clause with
predicate of non-bool type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
The following program should fail to compile in C++20 because the type of the
predicate in requires-clause is not bool.
```
template
struct is_small
{
enum { value = sizeof(T) <= 4 };
};
template
requires is_small::value
void fun(T) {}
template
void fun(T) {}
int main()
{
fun(1); // expected hard compiler error
}
```
[Bug c++/93248] [8/9/10 Regression] ICE in decltype of template constructor with default argument within a class template since r8-2712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93248 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed for 8.5/9.4/10.
[Bug c++/92068] [8/9/10 Regression] ICE on invalid in process_partial_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92068 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed for 8.5/9.4/10.
[Bug c++/92909] [8/9/10 Regression] ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed for 8.5/9.4/10.
[Bug c++/92909] [8/9/10 Regression] ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c3747bca3849b1e06358db9cb2389d8089c49e3e commit r9-8379-gc3747bca3849b1e06358db9cb2389d8089c49e3e Author: Jason Merrill Date: Sat Mar 14 17:10:39 2020 -0400 c++: Find parameter pack in typedef in lambda [92909]. find_parameter_packs_r doesn't look through typedefs, which is normally correct, but that means we need to handle their declarations specially. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/92909 * pt.c (find_parameter_packs_r): [DECL_EXPR]: Walk DECL_ORIGINAL_TYPE of a typedef.
[Bug c++/92909] [8/9/10 Regression] ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:eee8f2161e072c1b9da4f334f882c385a27baa1f commit r8-10128-geee8f2161e072c1b9da4f334f882c385a27baa1f Author: Jason Merrill Date: Sat Mar 14 17:10:39 2020 -0400 c++: Find parameter pack in typedef in lambda [92909]. find_parameter_packs_r doesn't look through typedefs, which is normally correct, but that means we need to handle their declarations specially. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/92909 * pt.c (find_parameter_packs_r): [DECL_EXPR]: Walk DECL_ORIGINAL_TYPE of a typedef.
[Bug c++/92068] [8/9/10 Regression] ICE on invalid in process_partial_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92068 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fed9ac72ee6c1b36d20a9550803835daaac174db commit r8-10127-gfed9ac72ee6c1b36d20a9550803835daaac174db Author: Jason Merrill Date: Sat Mar 14 17:10:39 2020 -0400 c++: Fix ICE-after-error on partial spec [92068] Here the template arguments for the partial specialization are valid arguments for the template, but not for a partial specialization, because 'd' can never be deduced to anything other than an empty pack. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/92068 * pt.c (process_partial_specialization): Error rather than crash on extra pack expansion.
[Bug c++/93248] [8/9/10 Regression] ICE in decltype of template constructor with default argument within a class template since r8-2712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93248 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:23690790dd739f1cdd33a8249304b8f17e296c38 commit r8-10126-g23690790dd739f1cdd33a8249304b8f17e296c38 Author: Jason Merrill Date: Sat Mar 14 17:10:39 2020 -0400 c++: Fix CTAD with multiple-arg ctor template [93248]. When cp_unevaluated_operand is set, tsubst_decl thinks that if it sees a PARM_DECL that isn't already in local_specializations, we're in a decltype in a trailing return type or some such, and so we only want a substitution for a single PARM_DECL. In this case, we want the whole chain, so make sure cp_unevaluated_operand is cleared. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/93248 * pt.c (build_deduction_guide): Clear cp_unevaluated_operand for substituting DECL_ARGUMENTS.
[Bug c++/93248] [8/9/10 Regression] ICE in decltype of template constructor with default argument within a class template since r8-2712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93248 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:cb05d702a17476fb658a59a6661d1f69394da786 commit r9-8377-gcb05d702a17476fb658a59a6661d1f69394da786 Author: Jason Merrill Date: Sat Mar 14 17:10:39 2020 -0400 c++: Fix CTAD with multiple-arg ctor template [93248]. When cp_unevaluated_operand is set, tsubst_decl thinks that if it sees a PARM_DECL that isn't already in local_specializations, we're in a decltype in a trailing return type or some such, and so we only want a substitution for a single PARM_DECL. In this case, we want the whole chain, so make sure cp_unevaluated_operand is cleared. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/93248 * pt.c (build_deduction_guide): Clear cp_unevaluated_operand for substituting DECL_ARGUMENTS.
[Bug c++/92068] [8/9/10 Regression] ICE on invalid in process_partial_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92068 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2fa5f9e380b794053a0dd8a8cc63f8bfab370d22 commit r9-8378-g2fa5f9e380b794053a0dd8a8cc63f8bfab370d22 Author: Jason Merrill Date: Sat Mar 14 17:10:39 2020 -0400 c++: Fix ICE-after-error on partial spec [92068] Here the template arguments for the partial specialization are valid arguments for the template, but not for a partial specialization, because 'd' can never be deduced to anything other than an empty pack. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/92068 * pt.c (process_partial_specialization): Error rather than crash on extra pack expansion.
[Bug target/61872] Assigning to "long double" causes memset to be improperly elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61872 Alexander Cherepanov changed: What|Removed |Added CC||ch3root at openwall dot com --- Comment #4 from Alexander Cherepanov --- This looks like a dup of pr93270, so: - this is invalid because assignments can change padding; - this is probably fixed together with pr94103.
[Bug c++/94185] New: gcc-10 crashes with "error: unable to generate reloads for {*zero_extendsidi2} internal compiler error: in curr_insn_transform, at lra-constraints.c:4006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185
Bug ID: 94185
Summary: gcc-10 crashes with "error: unable to generate reloads
for {*zero_extendsidi2} internal compiler error: in
curr_insn_transform, at lra-constraints.c:4006
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 48037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48037=edit
bug.cc
Originally observed on smartmontools-7.0, reduced with creduce down to:
struct a {
int b;
int c();
a() : b(c()) {}
~a();
char *e();
};
struct f {
void g(int);
};
struct ar {
int au[256];
f h(int);
} bb;
a i();
a j(int);
long k(int, ar);
int d;
void l(char *, ar m, long n) {
switch (m.au[d])
case 0:
n &= 4294967295;
bb.h(0).g(n);
}
void o() {
ar bd;
a bh, bi, attrname = j(0) = i();
int be = k(0, bd);
l(attrname.e(), bd, be);
}
Exact command to crash gcc-master:
$ ./xg++ -B. -O2 -c -o /tmp/bug.o /tmp/bug.cc -fstack-protector-strong -fPIE
/tmp/bug.cc: In function 'void o()':
/tmp/bug.cc:30:1: error: unable to generate reloads for:
30 | }
| ^
(insn 62 61 63 8 (set (mem/c:DI (plus:DI (reg/f:DI 19 frame)
(const_int -2152 [0xf798])) [7 %sfp+-2104 S8 A64])
(zero_extend:DI (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -2152 [0xf798])) [7 %sfp+-2104 S4
A64]))) "/tmp/bug.cc":22:7 114 {*zero_extendsidi2}
(nil))
during RTL pass: reload
/tmp/bug.cc:30:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:4006
0x7fc532a94dd9 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler is built as:
$ ./xg++ -B. -v
Reading specs from ./specs
COLLECT_GCC=./xg++
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
--with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200315 (experimental) (GCC)
[Bug middle-end/68785] [6 Regression] valgrind reports issues with folding on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68785 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #14 from David Binderman --- Interestingly, I ran the code in comment 8 through a valgrind version of recent gcc trunk, with the compiler flag -O2, and got this: ./gcc.dg/pr68785.c ==49861== Invalid read of size 1 ==49861==at 0xD9CDDD: count_nonzero_bytes(tree_node*, unsigned long, unsigned long, unsigned int*, bool*, bool*, bool*, vr_values const*, ssa_name_limit_t&) (tree-ssa-strlen.c:4891) ==49861==by 0xD9CF17: count_nonzero_bytes(tree_node*, unsigned long, unsigned long, unsigned int*, bool*, bool*, bool*, vr_values const*, ssa_name_limit_t&) (tree-ssa-strlen.c:4801) ==49861==by 0xDA19EE: count_nonzero_bytes (tree-ssa-strlen.c:4920) ==49861==by 0xDA19EE: handle_integral_assign(gimple_stmt_iterator*, bool*, vr_values const*) (tree-ssa-strlen.c:5547)
[Bug c++/94184] Global variable inline constructor elision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94184 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- There is another bug about this already.
[Bug other/94182] Document -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182 --- Comment #2 from Andrew Pinski --- Considering it is documented in another place where char is signed or unsigned. I don't know if this needs to change. https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Characters-implementation.html#Characters-implementation Which of signed char or unsigned char has the same range, representation, and behavior as “plain” char (C90 6.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5, C99 and C11 6.3.1.1). Determined by ABI. The options -funsigned-char and -fsigned-char change the default. See Options Controlling C Dialect. - CUT - Plus -funsigned-char/-fsigned-char
[Bug c++/94184] New: Global variable inline constructor elision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94184
Bug ID: 94184
Summary: Global variable inline constructor elision.
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
struct A {
int a_;
A(int a) : a_(a) {}
};
struct B {
int a_;
constexpr B(int a) : a_(a) {}
};
A a{1};
B b{1};
When compiled with `gcc-9.2 -O3 -march=skylake -mtune=skylake -std=gnu++17`
generates a call to `A` constructor for variable `a`:
_GLOBAL__sub_I_a:
movDWORD PTR [rip+0x200bd6],0x1# 601030 <__TMC_END__>
ret
And no call for `B` constructor for variable `b`, as expected of `constexpr`.
`clang-9.0 -O3 -march=skylake -mtune=skylake -std=gnu++17`, however, elides the
constructor calls for both `a` and `b` global variables, regardless of
`constexpr`.
Why can't `gcc` elide the call to `A` constructor for `a`, since `A` constuctor
is an inline function with a clear side-effect?
https://gcc.godbolt.org/z/5y3cD5
[Bug inline-asm/93903] invalid input constraint in __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93903
Frédéric Recoules changed:
What|Removed |Added
CC||frederic.recoules@univ-gren
||oble-alpes.fr
--- Comment #2 from Frédéric Recoules
---
(In reply to Frédéric Recoules from comment #1)
> I am pretty sure the error comes from the space you left in "r ".
> Yet, in the "Simple-Constraints" documentation, it is said that space are
> ignored
> to allow visual alignment but, in fact, I realized a while ago it generates
> an error.
>
> I think it would not be a big change to either update the documentation at
> https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html#Simple-
> Constraints or to make the parser ignore the blank.
I read me again and see how my comment was useless but, I really wanted to
help.
In fact I found that space are authorized for output but not for input.
In the file stmt.c:
In the function parse_input_constraint, the default case starts with:
if (!ISALPHA (*p))
break;
So it just exits the switch and continue, while the default case of
parse_input_constraint starts with:
if (! ISALPHA (constraint[j]))
{
error ("invalid punctuation %qc in constraint", constraint[j]);
return false;
}
Yet, I would add in the switch for both:
case ' ':
break;
[Bug inline-asm/94183] New: If constraints allow but only memory, expression should be an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94183 Bug ID: 94183 Summary: If constraints allow but only memory, expression should be an lvalue Product: gcc Version: unknown Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: frederic.recou...@univ-grenoble-alpes.fr Target Milestone: --- In the file gimplify.c in the function gimplify_asm_expr, it is said: /* If the operand is a memory input, it should be an lvalue. */ The fact is that it is documented nowhere in the online documentation. I would stand to be corrected on that, but it is my understanding that the "m" constraint alone is "point me to the address of the lvalue whatever its value" while "m" with a register constraint is "give me the value of the expression in the memory whatever its address". If I am right and it is principled, it is very important to document it.
[Bug other/94182] Document -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182 --- Comment #1 from Roland Illig --- https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
[Bug other/94182] New: Document -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182 Bug ID: 94182 Summary: Document -Wchar-subscripts Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- The current documentation on the -Wchar-subscripts option is nearly useless since it doesn't explain anything. I've made an attempt to summarize and explain the situation here: https://stackoverflow.com/a/60696378 The GCC documentation should at least include some pointers where to find more information about this warning, especially since there are so many ways to fix the warning incorrectly.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #35 from Rich Felker --- > Oh, your real code is different, and $10 doesn't work for that? I see. No, the real code is exactly that. What you're missing is that the kernel, entered through syscall, has a jump back to the addu after it's clobbered all the registers in the clobberlist if the syscall is interrupted and needs to be restarted.
[Bug inline-asm/87733] local register variable not honored with earlyclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733 --- Comment #34 from Segher Boessenkool --- Oh, your real code is different, and $10 doesn't work for that? I see.
[Bug inline-asm/93952] Giving an array in an operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93952 Frédéric Recoules changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Frédéric Recoules --- Ok, it is said nowhere but in the code, but if constraint only allows memory, expression are considered as lvalue, thus arrays do not decay to pointer.
[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 --- Comment #33 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:9d74caf21be7025db8fef997e87ebf3b85acaf4a commit r10-7182-g9d74caf21be7025db8fef997e87ebf3b85acaf4a Author: H.J. Lu Date: Sun Mar 15 10:21:08 2020 -0700 i386: Use ix86_output_ssemov for SFmode TYPE_SSEMOV There is no need to set mode attribute to V16SFmode since ix86_output_ssemov can properly encode xmm16-xmm31 registers with and without AVX512VL. gcc/ PR target/89229 * config/i386/i386.c (ix86_output_ssemov): Handle MODE_SI and MODE_SF. * config/i386/i386.md (*movsf_internal): Call ix86_output_ssemov for TYPE_SSEMOV. Remove TARGET_PREFER_AVX256, TARGET_AVX512VL and ext_sse_reg_operand check. gcc/testsuite/ PR target/89229 * gcc.target/i386/pr89229-6a.c: New test. * gcc.target/i386/pr89229-6b.c: Likewise. * gcc.target/i386/pr89229-6c.c: Likewise.
[Bug c/94179] [10 Regression] ICE in gimplify_expr, at gimplify.c:14399 since r10-7127-gcb99630f254aaec6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94179 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 48036 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48036=edit gcc10-pr94179.patch Untested fix. And/or we could limit the match.pd optimization to GIMPLE only, as at least the C FE doesn't seem to be prepared to handle MEM_REFs and it is unclear if this is the only spot that needs fixing.
[Bug ada/94181] New: Misidentified dangling reference in container implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94181 Bug ID: 94181 Summary: Misidentified dangling reference in container implementation Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Created attachment 48035 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48035=edit Reproducer This arose in a simple implementation of a Container’s Reference function: type Reference_Type (Element : not null access Element_Type) is record Dummy : Integer := raise Program_Error with "uninitialized reference"; end record; function Reference (C : aliased in out Container; Position : in Cursor) return Reference_Type is pragma Unreferenced (C); begin return (Element => Position.The_Node.all.The_Element'Access, Dummy => 1); end Reference; With GCC 9, this was fine (so long as that .all is in there! Weird). With GCC 10.0.1 20200206 (experimental) (GCC), we get 3.function Reference 4. (C : aliased in out Container; Position : in Cursor) 5. return Reference_Type 6.is 7. pragma Unreferenced (C); 8.begin 9. return (Element => Position.The_Node.all.The_Element'Access, Dummy => 1); | >>> access discriminant in return aggregate would be a dangling reference 10.end Reference; This (the same style as used in Ada.Containers) is OK. function Reference_With_Extended_Return (C : aliased in out Container; Position : in Cursor) return Reference_Type is pragma Unreferenced (C); begin return R : constant Reference_Type := (Element => Position.The_Node.The_Element'Unchecked_Access, Dummy => 1) do null; end return; end Reference_With_Extended_Return; Randy Brukardt[1] thinks there should be no difference. [1] https://groups.google.com/d/msg/comp.lang.ada/IUQ6DUe3Shw/wULgGGjqAgAJ
[Bug other/17898] Incorrect usage of isdigit, etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17898 John David Anglin changed: What|Removed |Added Status|SUSPENDED |NEW CC||danglin at gcc dot gnu.org --- Comment #6 from John David Anglin --- The usage of ISDIGIT in adadecode.c now causes a warning and build failure: /test/gnu/gcc/objdir/./prev-gcc/xg++ -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/bin/ -nostdinc++ -B/test/gnu/gcc/objdir/prev -hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/test/gnu/gcc/objdir/prev-hppa2. 0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -I/test/gnu/gcc/objdir/prev-hppa2. 0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objd ir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc+ +-v3/libsupc++ -L/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/sr c/.libs -L/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++ /.libs -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -fno-checking -DIN_GCC -fno-exc eptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-s trings -Wcast-qual -Wno-error=format-diag -mdisable-indexing -Wmissing-format-at tribute -Woverloaded-virtual -Wno-long-long -Wno-variadic-macros -Wno-overlength -strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../ gcc/gcc/ada -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gmp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o ada/adadecode.o -MT ada/adadecode.o -MMD -MP -MF ada/.deps/adadecode.TPo ../../gcc/gcc/ada/adadecode.c In file included from ../../gcc/gcc/ada/adadecode.c:35: ../../gcc/gcc/ada/adadecode.c: In function 'void __gnat_decode(const char*, char*, int)': ../../gcc/gcc/ada/adadecode.c:260:34: error: array subscript has type 'char' [-Werror=char-subscripts] 260 | while (ISDIGIT (ada_name[last]) && last > 0) | ~^ ../../gcc/gcc/ada/adadecode.c:260:12: note: in expansion of macro 'ISDIGIT' 260 | while (ISDIGIT (ada_name[last]) && last > 0) |^~~ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:1117: ada/adadecode.o] Error 1
[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94157 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #6 from Rainer Orth --- The new test FAILs on (at least) Solaris with the native assembler (and probably others like Darwin and HP-UX): +FAIL: gcc.dg/lto/pr94157 c_lto_pr94157_0.o assemble, -O0 -fipa-vrp -flto -Wa,--noexecstack -Wa,--noexecstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack +UNRESOLVED: gcc.dg/lto/pr94157 c_lto_pr94157_0.o-c_lto_pr94157_0.o execute -O0 -fipa-vrp -flto -Wa,--noexecstack -Wa,--noexecstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack +UNRESOLVED: gcc.dg/lto/pr94157 c_lto_pr94157_0.o-c_lto_pr94157_0.o link -O0 -fipa-vrp -flto -Wa,--noexecstack -Wa,--noexecstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack /usr/ccs/bin/as: error: unknown option '-'^M /usr/ccs/bin/as: error: unknown option '-'^M /usr/ccs/bin/as: error: unknown option 'e'^M /usr/ccs/bin/as: error: unknown option 'xecstack'^M /usr/ccs/bin/as: error: unknown option '-'^M /usr/ccs/bin/as: error: unknown option 'e'^M /usr/ccs/bin/as: error: unknown option 'xecstack'^M [...] Either use something portable here or restrict the test to assemblers supporing --execstack/--noexecstack.
[Bug inline-asm/94180] New: inconsistent operand constraints: "+X"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94180
Bug ID: 94180
Summary: inconsistent operand constraints: "+X"
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: frederic.recou...@univ-grenoble-alpes.fr
Target Milestone: ---
Consider the following code snippet:
int main (int argc, char *argv[])
{
int k = 0;
asm ("" : "+X" (k));
return k;
}
It produces the following error:
: In function 'main':
:17:5: error: inconsistent operand constraints in an 'asm'
17 | asm ("" : "+X" (k));
| ^~~
[Bug c/94179] [10 Regression] ICE in gimplify_expr, at gimplify.c:14399 since r10-7127-gcb99630f254aaec6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94179
--- Comment #1 from Martin Liška ---
A better test-case:
struct kgem_bo {
int rq;
int list;
int pinned_batches[];
} a;
int b;
void fn1() {
(struct kgem_bo *)((char *)_batches[b > 4096] -
(char *)&((struct kgem_bo *)0)->list);
}
[Bug c/94179] [10 Regression] ICE in gimplify_expr, at gimplify.c:14399 since r10-7127-gcb99630f254aaec6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94179 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||10.0 Version|9.0 |10.0 Last reconfirmed||2020-03-15 Known to work||9.3.0 Target Milestone|--- |10.0 Priority|P3 |P1
[Bug c/94179] New: [10 Regression] ICE in gimplify_expr, at gimplify.c:14399 since r10-7127-gcb99630f254aaec6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94179
Bug ID: 94179
Summary: [10 Regression] ICE in gimplify_expr, at
gimplify.c:14399 since r10-7127-gcb99630f254aaec6
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
I see the following ICE isolated from xf86-video-intel package:
$ cat kgem.i
struct kgem_bo {
int rq;
int list;
int pinned_batches[];
} a;
void
fn1() {
int b = (struct kgem_bo *)((char *)a.pinned_batches[b > 4096] -
(char *)&((struct kgem_bo *)0)->list);
}
$ gcc kgem.i -c
kgem.i: In function ‘fn1’:
kgem.i:9:30: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
9 | int b = (struct kgem_bo *)((char *)a.pinned_batches[b > 4096] -
| ^
kgem.i:9:11: warning: initialization of ‘int’ from ‘struct kgem_bo *’ makes
integer from pointer without a cast [-Wint-conversion]
9 | int b = (struct kgem_bo *)((char *)a.pinned_batches[b > 4096] -
| ^
kgem.i:9:57: internal compiler error: in gimplify_expr, at gimplify.c:14399
9 | int b = (struct kgem_bo *)((char *)a.pinned_batches[b > 4096] -
| ~~^~
0x69d747 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:14399
0xb83ce1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:14369
0xb8409f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13705
0xb8b079 gimplify_compound_lval
/home/marxin/Programming/gcc/gcc/gimplify.c:3079
0xb83845 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13554
0xb8409f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13705
0xb8409f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13705
0xb8641e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13761
0xb8c625 gimplify_addr_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:6171
0xb84284 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13649
0xb8409f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13705
0xb8409f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13705
0xb81ce7 gimplify_modify_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:5766
0xb83e98 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13602
0xb87976 gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:6823
0xb90518 gimplify_and_add(tree_node*, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:486
0xb90518 gimplify_decl_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:1816
0xb8509d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13799
0xb87976 gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:6823
0xb886fe gimplify_bind_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:1424
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/67960] [8/9 Regression] Prefixing a function with [[deprecated]] produces multiple warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #9 from Martin Liška --- commit r10-7159-g80a13af724aedfb360893dcc16aa7cc12ca49799 Author: Patrick Palka Date: Thu Mar 12 14:38:42 2020 -0400 c++: Redundant -Wdeprecated-declarations warning in build_over_call [PR67960] In build_over_call, we are emitting a redundant -Wdeprecated-declarations warning about the deprecated callee function, first from mark_used and again from build_addr_func <- decay_conversion <- cp_build_addr_expr <- mark_used. It seems this second deprecation warning coming from build_addr_func will always be redundant, so we can safely use a warning_sentinel to disable it before calling build_addr_func. (And any deprecation warning that could come from build_addr_func would be for FN, so we wouldn't be suppressing too much.) gcc/cp/ChangeLog: PR c++/67960 * call.c (build_over_call): Use a warning_sentinel to disable warn_deprecated_decl before calling build_addr_func. gcc/testsuite/ChangeLog: PR c++/67960 * g++.dg/diagnostic/pr67960.C: New test. * g++.dg/diagnostic/pr67960-2.C: New test.
[Bug c/94040] [9 Regression] ICE on a call to an invalid redeclaration of strftime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94040 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- commit r10-7164-g45ee7a35f347e59f003d65bce0d43d5123d827cf Author: Martin Sebor Date: Fri Mar 13 12:29:33 2020 -0600 PR c/94040 - ICE on a call to an invalid redeclaration of strftime gcc/testsuite/ChangeLog: * gcc.dg/torture/pr54261-1.c: Correct built-in declartion.
[Bug rtl-optimization/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #13 from Martin Liška --- commit r10-7165-ga4504f32c056db781a2bdc104dffa1b29684c930 Author: Vladimir N. Makarov Date: Fri Mar 13 14:58:57 2020 -0400 PR92303: Try to simplify memory subreg. 2020-03-13 Vladimir Makarov PR rtl-optimization/92303 * lra-spills.c (remove_pseudos): Try to simplify memory subreg.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #50 from Martin Liška --- commit r10-7160-g5c7e6d4bdf879b437b43037e10453275acabf521 Author: Segher Boessenkool Date: Thu Mar 12 07:12:50 2020 + df: Don't abuse bb->aux (PR94148, PR94042) The df dataflow solvers use the aux field in the basic_block struct, although that is reserved for any use by passes. And not only that, it is required that you set all such fields to NULL before calling the solvers, or you quietly get wrong results. This changes the solvers to use a local array for last_change_age instead, just like it already had a local array for last_visit_age. PR rtl-optimization/94148 PR rtl-optimization/94042 * df-core.c (BB_LAST_CHANGE_AGE): Delete. (df_worklist_propagate_forward): New parameter last_change_age, use that instead of bb->aux. (df_worklist_propagate_backward): Ditto. (df_worklist_dataflow_doublequeue): Use a local array last_change_age.
[Bug analyzer/94105] ICE in get_region, at analyzer/region-model.h:1744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94105 --- Comment #3 from Martin Liška --- commit r10-7168-g5c048755ec98645f8436b630df3f9294ca9cbc2a Author: David Malcolm Date: Tue Mar 10 19:03:37 2020 -0400 analyzer: handle NOP_EXPR in get_lvalue [PR94099,PR94105] PR analyzer/94099 and PR analyzer/94105 both report ICEs relating to calling region_model::get_lvalue on a NOP_EXPR. PR analyzer/94099's ICE happens when generating a checker_path when encountering an unhandled tree code (NOP_EXPR) in get_lvalue with a NULL context (from for_each_state_change). PR analyzer/94105 ICE happens when handling an ARRAY_REF where the first operand is a NOP_EXPR: the unhandled tree code gives us a symbolic_region, but the case for ARRAY_REF assumes we have an array_region. This patch fixes the ICEs by handling NOP_EXPR within region_model::get_lvalue, and bulletproofs both of the above sources of failure. gcc/analyzer/ChangeLog: PR analyzer/94099 PR analyzer/94105 * diagnostic-manager.cc (for_each_state_change): Bulletproof against errors in get_rvalue by passing a tentative_region_model_context and rejecting if there's an error. * region-model.cc (region_model::get_lvalue_1): When handling ARRAY_REF, handle results of error-handling. Handle NOP_EXPR. gcc/testsuite/ChangeLog: PR analyzer/94099 PR analyzer/94105 * gcc.dg/analyzer/pr94099.c: New test. * gcc.dg/analyzer/pr94105.c: New test.
[Bug analyzer/94099] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874 since r10-7023-g3d66e153b40ed000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94099 --- Comment #3 from Martin Liška --- commit r10-7168-g5c048755ec98645f8436b630df3f9294ca9cbc2a Author: David Malcolm Date: Tue Mar 10 19:03:37 2020 -0400 analyzer: handle NOP_EXPR in get_lvalue [PR94099,PR94105] PR analyzer/94099 and PR analyzer/94105 both report ICEs relating to calling region_model::get_lvalue on a NOP_EXPR. PR analyzer/94099's ICE happens when generating a checker_path when encountering an unhandled tree code (NOP_EXPR) in get_lvalue with a NULL context (from for_each_state_change). PR analyzer/94105 ICE happens when handling an ARRAY_REF where the first operand is a NOP_EXPR: the unhandled tree code gives us a symbolic_region, but the case for ARRAY_REF assumes we have an array_region. This patch fixes the ICEs by handling NOP_EXPR within region_model::get_lvalue, and bulletproofs both of the above sources of failure. gcc/analyzer/ChangeLog: PR analyzer/94099 PR analyzer/94105 * diagnostic-manager.cc (for_each_state_change): Bulletproof against errors in get_rvalue by passing a tentative_region_model_context and rejecting if there's an error. * region-model.cc (region_model::get_lvalue_1): When handling ARRAY_REF, handle results of error-handling. Handle NOP_EXPR. gcc/testsuite/ChangeLog: PR analyzer/94099 PR analyzer/94105 * gcc.dg/analyzer/pr94099.c: New test. * gcc.dg/analyzer/pr94105.c: New test.
[Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 --- Comment #8 from Martin Liška --- commit r10-7169-g50c96067c8ed60f4b3fcbee89fe31c905241b356 Author: Aaron Sawdey Date: Fri Mar 13 18:14:22 2020 -0500 Fix UBSAN error, shifting 64 bit value by 64. 2020-03-13 Aaron Sawdey PR target/92379 * config/rs6000/rs6000.c (num_insns_constant_multi) Don't shift a 64-bit value by 64 bits (UB).
[Bug ipa/94178] [10 Regression] wrong code with -fipa-sra + invalid -Wuninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94178 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r10-3311-gff6686d2e5f797d6c6a36ad14a7084bc1dc350e4. I bet this is a dup. *** This bug has been marked as a duplicate of bug 93385 ***
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #15 from Jakub Jelinek --- *** Bug 94178 has been marked as a duplicate of this bug. ***
[Bug preprocessor/88974] [9 Regression] ICE: Segmentation fault (in linemap_resolve_location)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88974 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- Interestingly, a valgrind enabled version of recent gcc trunk does this: ./c-c++-common/cpp/pr88974.c:4:31: error: missing terminating > character 4 | #if __has_include (
[Bug ipa/94178] New: [10 Regression] wrong code with -fipa-sra + invalid -Wuninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94178 Bug ID: 94178 Summary: [10 Regression] wrong code with -fipa-sra + invalid -Wuninitialized warning Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 48034 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48034=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O -fno-dce -fipa-sra -fno-tree-dce testcase.c -Wuninitialized testcase.c: In function 'main': testcase.c:10:5: warning: 'y' is used uninitialized in this function [-Wuninitialized] 10 | y /= (u128) x; | ^~ testcase.c:8:1: note: 'y' was declared here 8 | foo (u32 x, u8 y) | ^~~ testcase.c:10:8: warning: 'x' is used uninitialized in this function [-Wuninitialized] 10 | y /= (u128) x; |^~~~ testcase.c:8:1: note: 'x' was declared here 8 | foo (u32 x, u8 y) | ^~~ $ ./a.out Floating point exception The generated assembly code: mov edx, 0 mov ecx, 0 mov edi, 0 mov esi, 0 call__udivti3 shows it tries to do a 0/0 operation. (I failed to search gcc bugs with keyword "wrong-code", I just can't find the Keywords field at the Search page) $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r10-7179-20200315012740-g9c3cdb43c2b-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r10-7179-20200315012740-g9c3cdb43c2b-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.1 20200315 (experimental) (GCC)
[Bug middle-end/93566] [8/9 Regression] tree-nested.c ICE on C OpenMP array section reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93566 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] |tree-nested.c ICE on C |tree-nested.c ICE on C |OpenMP array section|OpenMP array section |reduction |reduction --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/94125] [9/10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125
--- Comment #7 from bin cheng ---
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542038.html
It's a latent bug exposed by the mentioned alias analysis change, however:
unsigned char b, f;
short d[1][8][1], *g = [0][3][0];
int
main ()
{
int k[] = { 0, 0, 0, 4, 0, 0 };
for (int c = 2; c >= 0; c--)
{
b = f;
*g = k[c + 3];
k[c + 1] = 0;
}
for (int i = 0; i < 8; i++)
if (d[0][i][0] != 0)
__builtin_abort ();
return 0;
}
We can't tell no-alias info for pairs and . Is this expected or
should be improved?
Thanks
