[Bug c/106503] New: "const char []" in local scope never initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106503
Bug ID: 106503
Summary: "const char []" in local scope never initialized
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eb at emlix dot com
Target Milestone: ---
Given the following test program:
#include
#include
#define WRITEL(str) \
do { \
wdata[wpos].iov_base = (void*)(str); \
wdata[wpos].iov_len = strlen(str); \
wlen += wdata[wpos].iov_len; \
wpos++; \
} while (0)
int main(int argc, char **argv)
{
struct iovec wdata[20];
unsigned int wpos = 0;
ssize_t wlen = 0;
int i = (argc > 1) ? 1 : 0;
WRITEL("foo");
if (argc) {
const char junk[] = "abc";
WRITEL(junk + i);
} else {
const char *junk = "def";
WRITEL(junk + i);
}
WRITEL("baz\n");
return writev(1, wdata, wpos) > 0 ? 0 : 1;
}
For gcc 10 and before, and gcc 11, 12, or 13
(b06a282921c71bbc5cab69bc515804bd80f55e92) when used with -O0, this outputs:
$ ./Ch
fooabcbaz
>From gcc 11 on when using -O1 or more it does not seem to initialize the "junk"
buffer, so it may output random things:
$ ./Ch
foocbaz
$ ./Ch
foo�baz
$ ./Ch
foo+baz
$ ./Ch
foo baz
$ ./Ch
foo[baz
I have seen the same behavior on both amd64 and sparc32, with distro compilers
(openSUSE, Gentoo) as well as an unpatched gcc13 built with Gentoo ebuilds.
[Bug c/106503] "const char []" in local scope never initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106503 --- Comment #1 from Rolf Eike Beer --- If you turn the "const char []" into a "const char *" in line 21 it works fine.
[Bug c/106503] "const char []" in local scope never initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106503 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- const char junk[] Goes out of scope and you still have a reference to it. -fsanitize=address sometimes can detect this kind of problems at runtime.
[Bug c/106503] "const char []" in local scope never initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106503 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > -fsanitize=address sometimes can detect this kind of problems at runtime. Program returned: 1 = ==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7f9235600030 at pc 0x7f9237ebcc9b bp 0x7ffc8cccff60 sp 0x7ffc8cccf720 READ of size 3 at 0x7f9235600030 thread T0 #0 0x7f9237ebcc9a (/opt/compiler-explorer/gcc-snapshot/lib64/libasan.so.8+0x4ac9a) (BuildId: f4e296dda2fcdab4980780e7f32c752a3e412556) #1 0x7f9237ebcf37 in writev (/opt/compiler-explorer/gcc-snapshot/lib64/libasan.so.8+0x4af37) (BuildId: f4e296dda2fcdab4980780e7f32c752a3e412556) #2 0x401673 in main (/app/output.s+0x401673) (BuildId: af556f86dec87e7467f73a633f83c822f3afe85a) #3 0x7f923790b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2) (BuildId: 9fdb74e7b217d06c93172a8243f8547f947ee6d1) #4 0x4010ed in _start (/app/output.s+0x4010ed) (BuildId: af556f86dec87e7467f73a633f83c822f3afe85a) Address 0x7f9235600030 is located in stack of thread T0 at offset 48 in frame #0 0x4011b5 in main (/app/output.s+0x4011b5) (BuildId: af556f86dec87e7467f73a633f83c822f3afe85a) This frame has 2 object(s): [48, 52) 'junk' (line 22) <== Memory access at offset 48 is inside this variable [64, 384) 'wdata' (line 15) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-use-after-scope (/opt/compiler-explorer/gcc-snapshot/lib64/libasan.so.8+0x4ac9a) (BuildId: f4e296dda2fcdab4980780e7f32c752a3e412556) Shadow bytes around the buggy address: 0x0ff2c6ab7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff2c6ab7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff2c6ab7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff2c6ab7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff2c6ab7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0ff2c6ab8000: f1 f1 f1 f1 f1 f1[f8]f2 00 00 00 00 00 00 00 00 0x0ff2c6ab8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff2c6ab8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff2c6ab8030: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 0x0ff2c6ab8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff2c6ab8050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==1==ABORTING fooabcbaz
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #13 from Tomasz Kłoczko --- Thank you for the explanation.
[Bug c/106503] "const char []" in local scope never initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106503
--- Comment #4 from Rolf Eike Beer ---
You are right, but if you switch the if clause a little bit:
if (argc) {
const char junk[] = "abc";
WRITEL(junk + i);
WRITEL("something else");
}
and then stop in the debugger on the second WRITEL you can see that junk has
never been initialized at all. So even within that scope it has the wrong
contents.
[Bug c/106503] "const char []" in local scope never initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106503 --- Comment #5 from Jonathan Wakely --- Because when you enable optimizations the compiler can see that the contents of junk are never used while still in scope, so the initialization is optimized away. Your program has undefined behaviour, that means the WHOLE program, including inside that block.
[Bug target/102961] Build fails for AIX 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102961 John Parke changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #4 from John Parke --- It appears from looking at config files, that AIX 6.1 is no longer supported...
[Bug c/106503] "const char []" in local scope never initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106503 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > Your program has undefined behaviour, that means the WHOLE program, > including inside that block. Or in the case where you copy the pointer, and then overwrite it with another value, that isn't undefined, but the value is not used. The point of optimization is to remove unnecessary code, like setting bytes in memory that will never get read back again. If the contents of junk are not needed, why waste cycles initializing those bytes?
[Bug c++/106502] Three calls to __attribute__((const)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106502 --- Comment #4 from Richard Biener --- Once you enable optimization a single cat () call remains (as expected). The FE does 9931 if (TREE_SIDE_EFFECTS (argarray[0])) 9932argarray[0] = save_expr (argarray[0]); 9933 t = build_pointer_type (TREE_TYPE (fn)); 9934 fn = build_vfn_ref (argarray[0], DECL_VINDEX (fn)); but argarray[0] doesn't have TREE_SIDE_EFFECTS set, it even has TREE_READONLY set on the CONVERT_EXPR wrapping the call. Note that save_expr would do nothing on this tree as well (because TREE_READONLY and !TREE_SIDE_EFFECTS).
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #14 from Richard Biener --- In addition to that, -flto-partition=none is almost never a good idea either. Note I think that we should honor flatten only during early inlining to avoid all kinds of funny behavior when applying cross TU.
[Bug c++/106502] Three calls to __attribute__((const)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106502 --- Comment #5 from Jonathan Wakely --- I noticed this by adding a printf statement to the const function for temporary debugging purposes, which is obviously incorrect and not a problem for real code. It's not observable that it gets called more than once, it just makes unoptimized code a bit slower.
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #15 from Tomasz Kłoczko --- (In reply to Richard Biener from comment #14) > In addition to that, -flto-partition=none is almost never a good idea either. > > Note I think that we should honor flatten only during early inlining to > avoid all kinds of funny behavior when applying cross TU. Issue is that in few cases AFAIK it is only solution to some still unresolved LTO issues :/
[Bug middle-end/106504] New: [OpenMP] 'for simd linear(i:1)' should be rejected with 'parallel private(i)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106504
Bug ID: 106504
Summary: [OpenMP] 'for simd linear(i:1)' should be rejected
with 'parallel private(i)'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The following program is a bit odd – and prints at runtime 10 for one thread –
and 6 for all others.
And I believe it is invalid for the reason given below:
Pre-remark: the 'for simd' directive has a predetermined 'linear(i:1)',
which can also be explicitly be specified without affecting the program.
#include
int main()
{
int i;
#pragma omp parallel private (i)
{
i = 6;
#pragma omp for simd
for (i = 1; i < 10; i++)
;
printf ("%i\n", i);
}
return 0;
}
--
I think the following applies:
"17.2 Clauses on Combined and Composite Constructs"
"If a list item of the linear clause is the iteration variable of a *simd* or
worksharing-loop SIMD construct and it is not declared in the construct, the
effect on the outer leaf constructs is as if the list item was specified in a
*lastprivate* clause on the combined or composite construct with the rules
specified above applied."
And:
"Restrictions to the *lastprivate* clause are as follows:
* A list item must not appear in a *lastprivate* clause on a work-distribution
construct if the corresponding region binds to the region of a
parallelism-generating construct in which the list item is private."
[Bug lto/90957] 453.povray is miscompiled with -flto -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90957 Maxim Kuvyrkov changed: What|Removed |Added Resolution|--- |WONTFIX Status|WAITING |RESOLVED --- Comment #2 from Maxim Kuvyrkov --- >From further analysis it seems this problem was due to how old armv7 kernels (3.10) allocated process stack. The stack bumped against special kernel-provided page, so, when compiler generate bigger-than-usual stack frames, the stack would overflow and process would crash. Non-ancient kernels don't have this problem.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 90957, which changed state. Bug 90957 Summary: 453.povray is miscompiled with -flto -static https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90957 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #16 from Martin Liška --- > Issue is that in few cases AFAIK it is only solution to some still > unresolved LTO issues :/ Well, in most cases it's used for symbol versioning which is implemented by assembly directives. However, we offer symver function attribute that survives LTO partitioning. One more reason can be usage of top-level asm, which can be mitigated by -fno-lto for units that use it.
[Bug tree-optimization/106497] [13 Regression] ICE in duplicate_block, at cfghooks.cc:1115 since r13-1753-g26cea5f108e0facd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106497 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0f3514756e0b4d8993ee43dcd958974eb1424061 commit r13-1929-g0f3514756e0b4d8993ee43dcd958974eb1424061 Author: Richard Biener Date: Tue Aug 2 12:19:25 2022 +0200 tree-optimization/106497 - more forward threader can-copy-bb This adds EDGE_COPY_SRC_JOINER_BLOCK sources to the set of blocks we need to check we can duplicate. PR tree-optimization/106497 * tree-ssa-threadupdate.cc (fwd_jt_path_registry::update_cfg): Also verify we can copy EDGE_COPY_SRC_JOINER_BLOCK. * gcc.dg/torture/pr106497.c: New testcase.
[Bug tree-optimization/106497] [13 Regression] ICE in duplicate_block, at cfghooks.cc:1115 since r13-1753-g26cea5f108e0facd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106497 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/97333] [meta-bug] [gimple_can_duplicate_bb_p == false, tree-ssa-threadupdate] ICE in duplicate_block, at cfghooks.c:1093
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97333 Bug 97333 depends on bug 106497, which changed state. Bug 106497 Summary: [13 Regression] ICE in duplicate_block, at cfghooks.cc:1115 since r13-1753-g26cea5f108e0facd https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106497 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/106505] New: DCE depends on whether if or else is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106505
Bug ID: 106505
Summary: DCE depends on whether if or else is used
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tmayerl at student dot ethz.ch
Target Milestone: ---
In some cases, the compiler's ability to eliminate dead code depends on whether
the if expression is left as it is or negated and the body moved to the else
block.
GCC detects that the if expressions in the following code snippet evaluate to
false and thus removes the dead code:
#include
#include
void DCEMarker0_();
void f(bool s, bool c) {
if (!c == !s) {
if (s && !c) {
DCEMarker0_();
}
}
}
In the following snippet, the inner if has been negated and the body has been
moved to the else block. However, GCC cannot eliminate the dead code anymore:
#include
#include
void DCEMarker0_();
void f(bool s, bool c) {
if (!c == !s) {
if (!(s && !c)) {}
else {
DCEMarker0_();
}
}
}
This can also be seen via the following Compiler Explorer link:
https://godbolt.org/z/P4a61nsdq
If s and c in the inner if expression are swapped, it is the other way round.
Without the else, the compiler cannot eliminate the dead code:
#include
#include
void DCEMarker0_();
void f(bool s, bool c) {
if (!c == !s) {
if (c && !s) {
DCEMarker0_();
}
}
}
However, it suddenly can optimise the code when the if expression is negated
and the body is moved to the else:
#include
#include
void DCEMarker0_();
void f(bool s, bool c) {
if (!c == !s) {
if (!(c && !s)) {}
else {
DCEMarker0_();
}
}
}
This can also be seen via the following Compiler Explorer link:
https://godbolt.org/z/95jo3Gv45
Due to the order issue this might be related to the following bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106379
However, this example only works with C as a source language. With C++, it is
fine. Thus, this might be related to the following bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106381
Another example is given below. In this case, only one variable is needed.
However, this only works with the datatype unsigned instead of bool. Therefore,
it might be related to the following bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380
Version with dead code eliminated:
#include
#include
void DCEMarker0_();
void f(unsigned s) {
if (!s == !!s) {
DCEMarker0_();
}
}
Version with dead code not eliminated:
#include
#include
void DCEMarker0_();
void f(unsigned s) {
if (!(!s == !!s)) {}
else {
DCEMarker0_();
}
}
This can also be seen via the following Compiler Explorer link:
https://godbolt.org/z/zYfoTs3PE
[Bug tree-optimization/106506] New: g++.dg/opt/pr94589-2.C FAILS after enabling floats in VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106506 Bug ID: 106506 Summary: g++.dg/opt/pr94589-2.C FAILS after enabling floats in VRP Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aldyh at gcc dot gnu.org CC: amacleod at redhat dot com, jakub at gcc dot gnu.org Target Milestone: --- As mentioned in this thread, enabling frange operators in range-op-float.cc causes g++.dg/opt/pr94589-2.C to fail: https://gcc.gnu.org/pipermail/gcc/2022-July/239207.html I've marked it as XFAIL. It's all yours Jakub ;-).
[Bug lto/78407] [6 Regression] LTO breaks separate overriding of symbol aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78407
--- Comment #7 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:353fd1ec3df92fbe66ce1513c5a86bdd5c5e22d1
commit r13-1934-g353fd1ec3df92fbe66ce1513c5a86bdd5c5e22d1
Author: Richard Biener
Date: Tue Aug 2 09:58:44 2022 +0200
Properly honor param_max_fsm_thread_path_insns in backwards threader
I am trying to make sense of back_threader_profitability::profitable_path_p
and the first thing I notice is that we do
/* Threading is profitable if the path duplicated is hot but also
in a case we separate cold path from hot path and permit optimization
of the hot path later. Be on the agressive side here. In some
testcases,
as in PR 78407 this leads to noticeable improvements. */
if (m_speed_p
&& ((taken_edge && optimize_edge_for_speed_p (taken_edge))
|| contains_hot_bb))
{
if (n_insns >= param_max_fsm_thread_path_insns)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, " FAIL: Jump-thread path not considered: "
"the number of instructions on the path "
"exceeds PARAM_MAX_FSM_THREAD_PATH_INSNS.\n");
return false;
}
...
}
else if (!m_speed_p && n_insns > 1)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, " FAIL: Jump-thread path not considered: "
"duplication of %i insns is needed and optimizing for
size.\n",
n_insns);
return false;
}
...
return true;
thus we apply the n_insns >= param_max_fsm_thread_path_insns only
to "hot paths". The comment above this isn't entirely clear whether
this is by design ("Be on the aggressive side here ...") but I think
this is a mistake. In fact the "hot path" check seems entirely
useless since if the path is not hot we simply continue threading it.
This was caused by r12-324-g69e5544210e3c0 and the following simply
reverts the offending change.
* tree-ssa-threadbackward.cc
(back_threader_profitability::profitable_path_p): Apply
size constraints to all paths again.
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #17 from Tomasz Kłoczko --- (In reply to Martin Liška from comment #16) [..] > Well, in most cases it's used for symbol versioning which is implemented by > assembly directives. However, we offer symver function attribute that > survives LTO partitioning. One more reason can be usage of top-level asm, > which can be mitigated by -fno-lto for units that use it. Yes I know however many project still is not usig that macro. BTW I just realised that as long as low level versioning symbols is handled it turns ouit that this bug seems is only arount he code which is handling versioned symbols taken from sym file. It should not be so hard to fix that. Am I right? This bug is in the queue for et least two years. What is the difficultu with fixing that?
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #18 from Martin Liška --- > It should not be so hard to fix that. Am I right? Do you mean the usage of symver attribute? No, it's quite a straightforward transformation many projects have already done.
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #19 from Tomasz Kłoczko --- (In reply to Martin Liška from comment #18) > > It should not be so hard to fix that. Am I right? > > Do you mean the usage of symver attribute? No, it's quite a straightforward > transformation many projects have already done. No, no .. I mean IIRC therea are few cases when versioned sym file is incorrectly handled if -flto-partition=none is not used.
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #20 from Martin Liška --- > No, no .. I mean IIRC therea are few cases when versioned sym file is > incorrectly handled if -flto-partition=none is not used. I'm not aware of any..
[Bug analyzer/106298] RFE: analyzer handling of dup, dup2, and dup3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106298 --- Comment #3 from CVS Commits --- The master branch has been updated by Immad Mir : https://gcc.gnu.org/g:6a11f2d974a912aaaedb0ce32cdfde10193003cd commit r13-1936-g6a11f2d974a912aaaedb0ce32cdfde10193003cd Author: Immad Mir Date: Tue Aug 2 22:22:07 2022 +0530 analyzer: support for creat, dup, dup2 and dup3 [PR106298] This patch extends the state machine in sm-fd.cc to support creat, dup, dup2 and dup3 functions. Lightly tested on x86_64 Linux. gcc/analyzer/ChangeLog: PR analyzer/106298 * sm-fd.cc (fd_state_machine::on_open): Add creat, dup, dup2 and dup3 functions. (enum dup): New. (fd_state_machine::valid_to_unchecked_state): New. (fd_state_machine::on_creat): New. (fd_state_machine::on_dup): New. gcc/testsuite/ChangeLog: PR analyzer/106298 * gcc.dg/analyzer/fd-1.c: Add tests for 'creat'. * gcc.dg/analyzer/fd-2.c: Likewise. * gcc.dg/analyzer/fd-4.c: Likewise. * gcc.dg/analyzer/fd-dup-1.c: New tests. Signed-off-by: Immad Mir
[Bug fortran/106507] New: Invalid structure constructor for extending derive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106507
Bug ID: 106507
Summary: Invalid structure constructor for extending derive
type
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
The following snippet triggers a compilation error
test.f90:17:25:
17 | inst = type2("test", 1)
| 1
Error: Too many components in structure constructor at (1)
when compiled with
gfortran -c test.f90
although being standard compliant. The problem seems to be the deferred length
character component. If the component is changed to fixed length (but still has
the allocatable attribute), the compiler happily compiles it.
--> test.f90 <--
module mod2
implicit none
type :: type1
character(:), allocatable :: name
end type type1
type, extends(type1) :: type2
integer :: data
end type
contains
subroutine mysub()
type(type2) :: inst
inst = type2("test", 1)
end subroutine mysub
end module mod2
[Bug analyzer/106298] RFE: analyzer handling of dup, dup2, and dup3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106298 Immad Mir changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Immad Mir --- Analyzer can now recognize these functions. See the commit above.
[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 Bug 106003 depends on bug 106298, which changed state. Bug 106298 Summary: RFE: analyzer handling of dup, dup2, and dup3 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106298 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/106300] RFE: analyzer support for more ways of obtaining an open file descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106300 Immad Mir changed: What|Removed |Added CC||mir at gcc dot gnu.org --- Comment #1 from Immad Mir --- I committed a patch (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6a11f2d974a912aaaedb0ce32cdfde10193003cd) for the support of creat, dup, dup2 and dup3.
[Bug c++/106508] New: Extra warnings with lambda captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106508
Bug ID: 106508
Summary: Extra warnings with lambda captures
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ozixtheorange at gmail dot com
Target Milestone: ---
The following will not work, because `this` needs to be captured to access
`member`. Seems like GCC should be able to detect that `member` is a class
member and warn that `this` is not being captured:
int outer;
struct A{
int member = 0;
auto fn(){
return [&]{
outer = member; // invalid
};
}
};
The following also fails, this time because `val` goes out of scope and so the
reference to `val` is invalid. I don't know if it is feasible for GCC to detect
this scenario, e.g. the lambda's lifetime extends beyond the scope of
captured-by-reference variables; but, a warning in this case would be nice as
well.
int outer;
auto fn1(int val = 0){
return [&]{
outer = val; // invalid
};
}
std::thread lambda;
void fn2(int val = 0){
lambda = std::thread([&]{
outer = val; // invalid
});
}
The reason I suggest this is because the compilation will succeed without
warning, but the binary can segfault and it is difficult to trace where the
source of the problem is. The first case is more subtle (forgetting `this`),
the second perhaps a bit easier to recognize though when debugging.
[Bug tree-optimization/106474] DCE depends on how if expressions are nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:87dd4c8c83768aafad92588853fd84a6070553d6 commit r13-1938-g87dd4c8c83768aafad92588853fd84a6070553d6 Author: Andrew MacLeod Date: Fri Jul 29 12:05:38 2022 -0400 Check equivalencies when calculating range on entry. When propagating on-entry values in the cache, checking if any equivalence has a known value can improve results. No new calculations are made. Only queries via dominators which do not populate the cache are checked. PR tree-optimization/106474 gcc/ * gimple-range-cache.cc (ranger_cache::fill_block_cache): Query range of equivalences that may contribute to the range. gcc/testsuite/ * g++.dg/pr106474.C: New.
[Bug fortran/106509] New: executable hangs if -static is included in compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106509 Bug ID: 106509 Summary: executable hangs if -static is included in compile Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Gary.White at ColoState dot edu Target Milestone: --- Created attachment 53398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53398&action=edit gfortran code to reproduce this bug When the attached code is compiled as: gfortran bug.f90 -fopenmp -o bug.exe -static the executable hangs even with a STOP message shown. If -static is removed, the code executes. Also, if the number of threads specified is equal to the number available, the code executes with -static . But the combination of -static and fewer threads specified than available on the machine causes the code to hang. This bug only occurs with gfortran 12.1. The identical code compiled with gfortran 11 does not hang.
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #21 from Tomasz Kłoczko --- FYI I've opened libfabric ticket https://github.com/ofiwg/libfabric/issues/7916 Thank you one more time for all your explanations :)
[Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106499 --- Comment #22 from Tomasz Kłoczko --- (In reply to Martin Liška from comment #6) > Doctor it hurts! Then don't do it. Sorry, seriously, it's caused by the > flatten attribute and I can reproduce it for our openSUSE package. If may I ask yet another question 😋 Martin can you tell how did you manage to diagnose that it was exactly that cause in this case?🤔 Thank you in advance.
[Bug target/106510] New: arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510 Bug ID: 106510 Summary: arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 53399 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53399&action=edit C source code For the C testsuite file ./gcc.c-torture/execute/ieee/compare-fp-4.c compiled by recent gcc trunk 32 bit ARM cross compiler, does this: during GIMPLE pass: threadfull ./gcc.c-torture/execute/ieee/compare-fp-4.c: In function â<80><98>ineâ<80><99>: ./gcc.c-torture/execute/ieee/compare-fp-4.c:42:5: internal compiler error: in gimple_range_operand1, at gimple-range-fold.cc:485 42 | int ine (float x, float y, int ok) | ^~~ 0x88a481 gimple_range_operand1(gimple const*) /home/dcb/gcc/trunk.git/gcc/gimple-range-fold.cc:485 0x88a481 gimple_range_operand1(gimple const*) /home/dcb/gcc/trunk.git/gcc/gimple-range-fold.cc:483 Flag -O2 required. I will have my usual go at reduction.
[Bug fortran/106509] executable hangs if -static is included in compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106509 --- Comment #1 from Andrew Pinski --- -static and glibc and pthreads (which openmp uses) has always been problematic. Why do you want to use -static?
[Bug tree-optimization/106510] [13 Regression] arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Summary|arm : ice in|[13 Regression] arm : ice |gimple_range_operand1, at |in gimple_range_operand1, |gimple-range-fold.cc:485|at gimple-range-fold.cc:485 Version|12.0|13.0
[Bug libfortran/106509] executable hangs if -static is included in compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106509 --- Comment #2 from GARY.WHITE at ColoState dot edu --- (In reply to Andrew Pinski from comment #1) > -static and glibc and pthreads (which openmp uses) has always been > problematic. Why do you want to use -static? Because I'm distributing a large code to users that do not have gfortran available.
[Bug tree-optimization/106510] [13 Regression] arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510
--- Comment #1 from David Binderman ---
Reduced C code seems to be:
void ine_ok() {
float y, x;
if (x < y || x > y || y)
abort();
}
Same problem exists on native x86_64, so I will have a go at finding a git
range.
[Bug c++/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466
--- Comment #10 from tt_1 ---
so I simply did use valgrind as in < /usr/bin/valgrind gcc command > , heres
the result:
==32586== Memcheck, a memory error detector
==32586== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32586== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==32586== Command: /usr/bin/aarch64-unknown-linux-gnu-g++
-DHWY_DISABLED_TARGETS=(HWY_SVE|HWY_SVE2|HWY_SVE_256|HWY_SVE2_128|HWY_RVV)
-D__DATE__="redacted" -D__TIMESTAMP__="redacted" -D__TIME__="redacted"
-I/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms
-O2 -pipe -save-temps -fno-rtti -funwind-tables -fno-omit-frame-pointer -fPIC
-fvisibility=hidden -fvisibility-inlines-hidden
-fmacro-prefix-map=/var/tmp/portage/media-libs/libjxl-/work/libjxl-=.
-Wno-builtin-macro-redefined -Wall -Wno-psabi -DJPEGXL_BUNDLE_SKCMS=1 -include
/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/../lib/jxl/enc_jxl_skcms.h
-std=c++11 -MD -MT third_party/CMakeFiles/skcms-obj.dir/skcms/skcms.cc.o -MF
third_party/CMakeFiles/skcms-obj.dir/skcms/skcms.cc.o.d -o
third_party/CMakeFiles/skcms-obj.dir/skcms/skcms.cc.o -c
/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms/skcms.cc
==32586==
--32586-- WARNING: unhandled arm64-linux syscall: 293
--32586-- You may be able to write your own handler.
--32586-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--32586-- Nevertheless we consider this a bug. Please report
--32586-- it at http://valgrind.org/support/bug_reports.html.
aarch64-unknown-linux-gnu-g++: warning: '-pipe' ignored because '-save-temps'
specified
during GIMPLE pass: fre
/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms/skcms.cc:
In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)':
/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms/skcms.cc:1004:6:
internal compiler error: Segmentation fault
1004 | bool skcms_Parse(const void* buf, size_t len, skcms_ICCProfile*
profile) {
| ^~~
0x7f82d9707b __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f82d9714b __libc_start_main_impl
../csu/libc-start.c:389
[Bug tree-optimization/106510] [13 Regression] arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510 --- Comment #2 from Andrew Pinski --- Most likely caused by r13-1933-g24012539ae3410 .
[Bug tree-optimization/106510] [13 Regression] arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510 --- Comment #3 from David Binderman --- Git range seems to be 82ac4cd213867be9..6d41f7c39cff9fb5, a range of 22 commits.
[Bug c++/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 --- Comment #11 from tt_1 --- Created attachment 53400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53400&action=edit a more verbose output with valgrind --leak-check=full
[Bug tree-optimization/106510] [13 Regression] arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510 David Binderman changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #4 from David Binderman --- Most likely commit is in git range, so perhaps Aldy might be willing to offer an opinion ?
[Bug tree-optimization/106474] DCE depends on how if expressions are nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Macleod --- Presumably this is about functionality rather than the actual DCE pass. The committed patch fixes this in any of the VRP passes.
[Bug tree-optimization/106510] [13 Regression] arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-08-02
Status|UNCONFIRMED |NEW
CC||amacleod at redhat dot com
Ever confirmed|0 |1
--- Comment #5 from Aldy Hernandez ---
BTW, (In reply to David Binderman from comment #1)
> Reduced C code seems to be:
>
> void ine_ok() {
> float y, x;
> if (x < y || x > y || y)
> abort();
> }
>
> Same problem exists on native x86_64, so I will have a go at finding a git
> range.
BTW, test exhibits undefined behavior, though putting x and y as arguments also
ICEs.
GORI wants all the relational operators defined, and is asserting so.
What's missing is the LGBT operator ;-).
diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 4fbd96a7479..1725c73e39c 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -747,6 +747,7 @@ floating_op_table::floating_op_table ()
set (UNGE_EXPR, fop_relop_unknown);
set (UNGT_EXPR, fop_relop_unknown);
set (UNEQ_EXPR, fop_relop_unknown);
+ set (LTGT_EXPR, fop_relop_unknown);
set (ORDERED_EXPR, fop_ordered);
set (UNORDERED_EXPR, fop_unordered);
}
I won't be able to get to this today. If someone could test and push, it'd be
great. Otherwise, I'll get to it tomorrow.
[Bug middle-end/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 tt_1 changed: What|Removed |Added Attachment #53400|0 |1 is obsolete|| --- Comment #12 from tt_1 --- Created attachment 53401 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53401&action=edit a more verbose output with debug-gcc and valgrind --leak-check=full recompiled gcc with -ggdb for more usefull output I hope this is usefull? If not please leave a comment with directions :)
[Bug middle-end/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 tt_1 changed: What|Removed |Added Attachment #53374|0 |1 is obsolete|| --- Comment #13 from tt_1 --- Created attachment 53402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53402&action=edit compressed preprocessed source reattached preprocessed source from the current valgrind run
[Bug middle-end/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 --- Comment #14 from Andrew Pinski --- I suspect this is a GC (garbage collection) issue. It might be easier to reduce it using --param ggc-min-expand=1 --param ggc-min-heapsize=1 (and then moving them both to 0 afterwards). https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction?highlight=%28reduce%29
[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:8d783f0f6955e6aa7af218490b068004669b09e0 commit r10-10926-g8d783f0f6955e6aa7af218490b068004669b09e0 Author: Lewis Hyatt Date: Sat Jul 9 16:12:21 2022 -0400 c: Fix location for _Pragma tokens [PR97498] The handling of #pragma GCC diagnostic uses input_location, which is not always as precise as needed; in particular the relative location of some tokens and a _Pragma directive will crucially determine whether a given diagnostic is enabled or suppressed in the desired way. PR97498 shows how the C frontend ends up with input_location pointing to the beginning of the line containing a _Pragma() directive, resulting in the wrong behavior if the diagnostic to be modified pertains to some tokens found earlier on the same line. This patch fixes that by addressing two issues: a) libcpp was not assigning a valid location to the CPP_PRAGMA token generated by the _Pragma directive. b) C frontend was not setting input_location to something reasonable. With this change, the C frontend is able to change input_location to point to the _Pragma token as needed. This is just a two-line fix (one for each of a) and b)), the testsuite changes were needed only because the location on the tested warnings has been somewhat improved, so the tests need to look for the new locations. gcc/c/ChangeLog: PR preprocessor/97498 * c-parser.c (c_parser_pragma): Set input_location to the location of the pragma, rather than the start of the line. libcpp/ChangeLog: PR preprocessor/97498 * directives.c (destringize_and_run): Override the location of the CPP_PRAGMA token from a _Pragma directive to the location of the expansion point, as is done for the tokens lexed from it. gcc/testsuite/ChangeLog: PR preprocessor/97498 * c-c++-common/pr97498.c: New test. * gcc.dg/pragma-message.c: Adapt for improved warning locations. (cherry picked from commit 0587cef3d7962a8b0f44779589ba2920dd3d71e5)
[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:d431d48c4e503c3ff17ccd51e504877f3fc9ce0e commit r11-10188-gd431d48c4e503c3ff17ccd51e504877f3fc9ce0e Author: Lewis Hyatt Date: Sat Jul 9 16:12:21 2022 -0400 c: Fix location for _Pragma tokens [PR97498] The handling of #pragma GCC diagnostic uses input_location, which is not always as precise as needed; in particular the relative location of some tokens and a _Pragma directive will crucially determine whether a given diagnostic is enabled or suppressed in the desired way. PR97498 shows how the C frontend ends up with input_location pointing to the beginning of the line containing a _Pragma() directive, resulting in the wrong behavior if the diagnostic to be modified pertains to some tokens found earlier on the same line. This patch fixes that by addressing two issues: a) libcpp was not assigning a valid location to the CPP_PRAGMA token generated by the _Pragma directive. b) C frontend was not setting input_location to something reasonable. With this change, the C frontend is able to change input_location to point to the _Pragma token as needed. This is just a two-line fix (one for each of a) and b)), the testsuite changes were needed only because the location on the tested warnings has been somewhat improved, so the tests need to look for the new locations. gcc/c/ChangeLog: PR preprocessor/97498 * c-parser.c (c_parser_pragma): Set input_location to the location of the pragma, rather than the start of the line. libcpp/ChangeLog: PR preprocessor/97498 * directives.c (destringize_and_run): Override the location of the CPP_PRAGMA token from a _Pragma directive to the location of the expansion point, as is done for the tokens lexed from it. gcc/testsuite/ChangeLog: PR preprocessor/97498 * c-c++-common/pr97498.c: New test. * gcc.dg/pragma-message.c: Adapt for improved warning locations. (cherry picked from commit 0587cef3d7962a8b0f44779589ba2920dd3d71e5)
[Bug libfortran/106509] executable hangs if -static is included in compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106509 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to gary.wh...@colostate.edu from comment #2) > (In reply to Andrew Pinski from comment #1) > > -static and glibc and pthreads (which openmp uses) has always been > > problematic. Why do you want to use -static? > > Because I'm distributing a large code to users that do not have gfortran > available. Does it hang if you use -static-libgfortran? BTW, works fine on FreeBSD.
[Bug bootstrap/43301] top-level configure script ignores ---with-build-time-tools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #6 from Iain Sandoe --- JFTR, I had cause to use this today on powerpc-darwin9, and it seemed to DTRT - so it would be useful to establish what it was that did not work before, that was fixed by the patch. /src-local/gcc-git-11/configure --prefix=/opt/iains/powerpc-apple-darwin9/gcc-11-3Dr2d --build=powerpc-apple-darwin9 --enable-languages=all --with-tune-cpu=G5 --enable-libphobos --with-libphobos-druntime-only CC=powerpc-apple-darwin-gcc CXX=powerpc-apple-darwin-g++ --with-build-time-tools=/opt/iains/powerpc-apple-darwin9/gcc-11-3Dr2d/bin Without the "--with-build-time-tools=/opt/iains/powerpc-apple-darwin9/gcc-11-3Dr2d/bin" the system linker and assembler are found and used (which fails to work with D, causing a bootstrap fail) with the option, the relevant tools are found and bootstrap succeeded (so I am not sure what the original problem was since $build is not specified in the summary, I guess we must assume it was i686-pc-cygwin so perhaps the problem is specific to that setup?)
[Bug tree-optimization/106510] [13 Regression] arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510 --- Comment #6 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:70daecc03235aa7187b03681cebed6e04b32678e commit r13-1940-g70daecc03235aa7187b03681cebed6e04b32678e Author: Andrew MacLeod Date: Tue Aug 2 17:31:37 2022 -0400 Do not register edges for statements not understood. Previously, all gimple_cond types were undserstoof, with float values, this is no longer true. We should gracefully do nothing if the gcond type is not supported. PR tree-optimization/106510 gcc/ * gimple-range-fold.cc (fur_source::register_outgoing_edges): Check for unsupported statements early. gcc/testsuite * gcc.dg/pr106510.c: New.
[Bug tree-optimization/106510] [13 Regression] arm : ice in gimple_range_operand1, at gimple-range-fold.cc:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Macleod --- fixed.
[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
Last reconfirmed||2022-08-03
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
cat test.c
extern int a;
int foo (int b){
return a + b;
}
on ppc64le, with option "-mcpu=power9 -fpatchable-function-entry=5,3", the
generated assembly looks like:
.LPFE1:
nop
nop
nop
.type foo, @function
foo:
nop
nop
.LFB0:
.cfi_startproc
.LCF0:
0: addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry foo,.-foo
std 31,-8(1)
Jakub's #c0 noted that the "after" nops should be placed after local entry, but
there seem two choices to put the "before" nops, such as:
1)
0: addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
nop
nop
nop
.localentry foo,.-foo
nop
nop
std 31,-8(1)
2)
0: nop
nop
nop
addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry foo,.-foo
nop
nop
std 31,-8(1)
For either of them, the "before" nops only take effects when it's entered from
global entry, both are counted as five insns in global entry area, there is no
differences from these two perspectives. I'd like to go with 1) if no
objections.
[Bug rtl-optimization/105653] [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105653
--- Comment #2 from Arseny Solokha ---
Created attachment 53403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53403&action=edit
A shorter testcase
% aarch64-linux-gnu-g++-13.0.0 -O2 -fcompare-debug -fno-gcse -c wo91465u.cpp
aarch64-linux-gnu-g++-13.0.0: error: wo91465u.cpp: '-fcompare-debug' failure
(length)
--- wo91465u.cpp.gkd2022-08-03 10:02:59.526593546 +0700
+++ wo91465u.gk.cpp.gkd 2022-08-03 10:02:59.554593642 +0700
@@ -47,10 +47,7 @@
(zero_extend:DI (mem:SI (plus:DI (mult:DI (reg:DI 1 x1 [orig:96 D.
] [96])
(const_int 4 [0x4]))
(reg/f:DI 4 x4 [orig:93 _7 ] [93])) [ MEM[(int *)_7 +
ivtmp.6_16 * 4]+0 S4 A32]))) "wo91465u.cpp":10:7# {*zero_extendsidi2_aarch64}
- (expr_list:REG_EQUIV (mem:SI (plus:DI (mult:DI (reg:DI 1 x1 [orig:96
D. ] [96])
-(const_int 4 [0x4]))
-(reg/f:DI 4 x4 [orig:93 _7 ] [93])) [ MEM[(int *)_7 +
ivtmp.6_16 * 4]+0 S4 A32])
-(nil)))
+ (nil))
(jump_insn:TI # 0 0 (set (pc)
(if_then_else (eq (reg:SI 2 x2 [orig:104 MEM[(int *)_7 + ivtmp.6_16 *
4] ] [104])
(const_int 0 [0]))
[Bug rtl-optimization/104771] '-fcompare-debug' failure w/ -mno-vsx -O1 -frename-registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104771 --- Comment #2 from Arseny Solokha --- I too cannot reproduce it w/ gcc 13.0.0 20220731 snapshot.
[Bug rtl-optimization/104771] '-fcompare-debug' failure w/ -mno-vsx -O1 -frename-registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104771 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME CC||linkw at gcc dot gnu.org --- Comment #3 from Kewen Lin --- Marked resolved as Arseny's latest comment.
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #19 from Xionghu Luo (luoxhu at gcc dot gnu.org) ---
(In reply to Xionghu Luo (luo...@gcc.gnu.org) from comment #15)
> In combine: vec_select(vec_concat and the followed vec_select are combined
> to a single extract instruction, which seems reasonable for both LE and BE?
>
> R146: 0 1 2 3
> R141: 4 5 6 7
> R150: 2 6 3 7// vec_select(vec_concat(r146:V4SI,r141:V4SI),[2 6 3 7])
> R151: R150[3]// vec_select(r150:V4SI,3)
>
> =>
>
> R151: R141[3] // vec_select(r141:V4SI,3)
>
>
>
> Trying 21 -> 24:
>21: r150:V4SI=vec_select(vec_concat(r146:V4SI,r141:V4SI),parallel)
> REG_DEAD r146:V4SI
> REG_DEAD r141:V4SI
>24: {r151:SI=vec_select(r150:V4SI,parallel);clobber scratch;}
> Failed to match this instruction:
> (parallel [
> (set (reg:SI 151)
> (vec_select:SI (reg:V4SI 141)
> (parallel [
> (const_int 3 [0x3])
> ])))
> (clobber (scratch:SI))
> (set (reg:V4SI 150)
> (vec_select:V4SI (vec_concat:V8SI (reg:V4SI 146)
> (reg:V4SI 141))
> (parallel [
> (const_int 2 [0x2])
> (const_int 6 [0x6])
> (const_int 3 [0x3])
> (const_int 7 [0x7])
> ])))
> ])
> Failed to match this instruction:
> (parallel [
> (set (reg:SI 151)
> (vec_select:SI (reg:V4SI 141)
> (parallel [
> (const_int 3 [0x3])
> ])))
> (set (reg:V4SI 150)
> (vec_select:V4SI (vec_concat:V8SI (reg:V4SI 146)
> (reg:V4SI 141))
> (parallel [
> (const_int 2 [0x2])
> (const_int 6 [0x6])
> (const_int 3 [0x3])
> (const_int 7 [0x7])
> ])))
> ])
> Successfully matched this instruction:
> (set (reg:V4SI 150)
> (vec_select:V4SI (vec_concat:V8SI (reg:V4SI 146)
> (reg:V4SI 141))
> (parallel [
> (const_int 2 [0x2])
> (const_int 6 [0x6])
> (const_int 3 [0x3])
> (const_int 7 [0x7])
> ])))
> Successfully matched this instruction:
> (set (reg:SI 151)
> (vec_select:SI (reg:V4SI 141)
> (parallel [
> (const_int 3 [0x3])
> ])))
> allowing combination of insns 21 and 24
> original costs 4 + 4 = 8
> replacement costs 4 + 4 = 8
> modifying insn i221:
> r150:V4SI=vec_select(vec_concat(r146:V4SI,r141:V4SI),parallel)
> REG_DEAD r146:V4SI
> deferring rescan insn with uid = 21.
> modifying insn i324: {r151:SI=vec_select(r141:V4SI,parallel);clobber
> scratch;}
> REG_DEAD r141:V4SI
> deferring rescan insn with uid = 24.
>
>
> I guess the previous unspec implementation bypassed the LE + LE swap check,
> so now in split2, we should generate vextuwlx instead of vextuwrx on little
> endian?
This nested vec_select+vec_select+vec_concat optimization is introduced by Uros
in simplify-rtx.c by PR32661, unfortunately it only works for Power BE
platforms, disable that piece of code could work due to not combined the nested
vec_select optimizations...
For Power LE, firstly:
Trying 21 -> 24:
R146: 3 2 1 0
R141: 7 6 5 4
R150: 7 3 6 2// vec_select(vec_concat(r146:V4SI,r141:V4SI),[2 6 3 7])
R151: R150[3]// vec_select(r150:V4SI,3)
=>
currently:
R151: R141[3] // vec_select(r141:V4SI,3)
But it should be:
R151: R146[3] // vec_select(r146:V4SI,3)
Which means current:
R151: R150[3] R141[3]
R153: R150[2] R146[3]
R155: R150[1] R141[2]
R157: R150[0] R146[2]
Should be optimized to after the first nested vec_select optimization:
R151: R150[3] R146[3]
R153: R150[2] R141[3]
R155: R150[1] R146[2]
R157: R150[0] R141[2]
With some little endian check and swap could achieve the result (swap op00 and
op01). But
Secondly there is another "nested vec_select" optimisation which produces
R151=R165[3]:
Trying 21 -> 26:
...
R146 R165 R163 [7 3 6 2]
R151: R146[3] => R165[3] (this is wrong!)
While R162, R163, R164, R165 is input value R0 R1 R2 R3. the
vsx_extract_v4si_di_p9 index should be "0" instead of "3".
correct should be:
R151: R165[0]
R153: R164[0]
R155: R163[0]
R157: R162[0]
(insn 44 2 4 2 (set (reg:V4SI 162)
(reg:V4SI 66 2 [ R0 ])) "q.C":36:1 1157 {vsx_movv4si_64bit}
(expr_list:REG_DEAD (reg:V4SI 66 2 [ R0 ])
(nil)))
(note 4 44 45 2 NOTE_INSN_DELETED)
(insn 45 4 5 2 (set (reg:V4SI 163)
(reg:V4SI 67 3 [ R1 ])) "q.C":36:1 1157 {vsx_movv4si_64bit}
(expr_list:REG_DEAD (reg:V4SI 67 3 [ R1 ])
(nil)))
(note 5 45 46 2 NOTE_INSN_DELETED)
(insn 46 5 6 2 (set (reg:V4SI 164)
(reg:V4SI 68 4 [ R2 ])) "q.C":36:1 1157 {vsx_movv4si_64bit}
(expr_list:REG_DE
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069 --- Comment #20 from Xionghu Luo (luoxhu at gcc dot gnu.org) --- Another reference is manually change the generated assembly with modifying the source and index vspltw to verify: luoxhu@gcc135 build $ diff q.bad.s q.good.s -U12 --- q.bad.s 2022-08-03 06:30:08.298451116 + +++ q.good.s2022-08-03 06:30:52.887250451 + @@ -18,31 +18,31 @@ addi 2,2,.TOC.-.LCF0@l .localentry _Z3fooPhPjDv4_jS1_S1_S1_,.-_Z3fooPhPjDv4_jS1_S1_S1_ mflr %r0 std %r0,16(%r1) std %r30,-16(%r1) std %r31,-8(%r1) stdu %r1,-112(%r1) .cfi_def_cfa_offset 112 .cfi_offset 65, 16 .cfi_offset 30, -16 .cfi_offset 31, -8 mr %r30,%r3 - vspltw %v0,%v2,0 + vspltw %v0,%v5,3 mfvsrwz %r7,%vs32 - vspltw %v0,%v3,0 + vspltw %v0,%v4,3 mfvsrwz %r6,%vs32 - vspltw %v0,%v4,0 + vspltw %v0,%v3,3 mfvsrwz %r5,%vs32 - vspltw %v0,%v5,0 + vspltw %v0,%v2,3 mfvsrwz %r31,%vs32 rldicl %r7,%r7,0,32 rldicl %r6,%r6,0,32 rldicl %r5,%r5,0,32 rldicl %r4,%r31,0,32 addis %r3,%r2,.LC0@toc@ha addi %r3,%r3,.LC0@toc@l bl printf nop stb %r31,0(%r30) addi %r1,%r1,112 .cfi_def_cfa_offset 0 luoxhu@gcc135 build $ gcc q.good.s -o q.good luoxhu@gcc135 build $ ./q.good B0: 41fcef98, 91648e8b,7dca18c6,61707865 Which means both register and index are incorrectly used in LE nested vec_select optimization.
