[Bug middle-end/54666] when do lto opitimizing with attribute (weak,alias), it will produce wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54666 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- This was fixed for GCC 5.1.0. The problem is the same as PR 32219 really.
[Bug ipa/92932] Optimizers generate wrong code due to aggressive data optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92932 Bug 92932 depends on bug 54666, which changed state. Bug 54666 Summary: when do lto opitimizing with attribute (weak,alias), it will produce wrong code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54666 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/54666] when do lto opitimizing with attribute (weak,alias), it will produce wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54666 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > This was fixed for GCC 5.1.0. The problem is the same as PR 32219 really. That is the patch which fixes PR 32219 fixed this one.
[Bug tree-optimization/102436] [11/12 Regression] Lost Load/Store Motion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102436
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|--- |11.3
Priority|P3 |P2
Keywords||missed-optimization
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2021-09-22
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
Memory reference 3: numb_moves
Memory reference 4: _24->from
...
Querying dependency of refs 3 and 4: dependent.
Querying SM WAW dependencies of ref 3 in loop 1: dependent
the issue is that we require conditional executed stores to be independent
on all other stores as we cannot re-issue other stores on exit in the proper
order.
Now, in this case the dependent stores are executed under the same condition
and in fact ordered in a way that we don't have to re-issue any dependent
store.
We're failing to handle this special case after the store-motion re-write that
fixed the TBAA issues.
Smaller testcase where we can just issue the conditional store to 'p':
unsigned p;
void foo (float *q)
{
for (int i = 0; i < 256; ++i)
{
if (p)
{
unsigned a = p;
*(q++) = 1.;
p = a + 1;
}
}
}
the following are what's very much more difficult to handle
(we have to issue a conditional sequence of two stores, and remember the
location the non-invariant store stored to _and_ verify we can re-emit that
out-of-order, and we have to remember the value stored):
unsigned p;
void foo (float *q)
{
for (int i = 0; i < 256; ++i)
{
if (p)
{
unsigned a = p;
p = a + 1;
*(q++) = 1.;
}
}
}
a bit easier (the store we have to re-issue is always executed after the
last conditional store):
unsigned p;
void foo (float *q)
{
for (int i = 0; i < 256; ++i)
{
if (p)
{
unsigned a = p;
p = a + 1;
}
*(q++) = 1.;
}
}
impossible / invalid:
unsigned p;
void foo (float *q)
{
for (int i = 0; i < 256; ++i)
{
*(q++) = 1.;
if (p)
{
unsigned a = p;
p = a + 1;
}
}
}
I will see how difficult it is to teach the already interwinded code the
"trivial" case and whether the bit easier case falls out naturally.
[Bug middle-end/100357] noinit attribute does not work sometimes (small data or with -fdata-sections)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100357 --- Comment #2 from Andrew Pinski --- -fdata-sections problem was fixed with r11-5246-gb510765dedfec5.
[Bug middle-end/100357] noinit attribute does not work sometimes (small data)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100357
Andrew Pinski changed:
What|Removed |Added
Summary|noinit attribute does not |noinit attribute does not
|work sometimes (small data |work sometimes (small data)
|or with -fdata-sections)|
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-09-22
--- Comment #3 from Andrew Pinski ---
The sbss issue can most likely be fixed by:
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 2d261b353bf..1216e76be53 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -7063,7 +7063,7 @@ categorize_decl_for_section (const_tree decl, int reloc)
}
/* If the target uses small data sections, select it. */
- else if (targetm.in_small_data_p (decl))
+ else if (!DECL_NOINIT_P (decl) && targetm.in_small_data_p (decl))
{
if (ret == SECCAT_BSS)
ret = SECCAT_SBSS;
But I have no way to test this patch.
Anyways confirmed for small data.
[Bug rtl-optimization/102441] [10/11/12 Regression] Incorrect location list in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102441
Richard Biener changed:
What|Removed |Added
Known to fail||10.3.1, 11.2.1
Target||x86_64-*-*
Status|UNCONFIRMED |NEW
Known to work||7.5.0
Summary|Incorrect location list in |[10/11/12 Regression]
|debug info |Incorrect location list in
||debug info
Component|debug |rtl-optimization
Target Milestone|--- |10.4
Last reconfirmed||2021-09-22
Keywords||wrong-debug
Priority|P3 |P2
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
probably a var-tracking issue. Works with GCC 7 and (noipa doesn't exist):
void __attribute__((noinline,noclone)) not_opt_this(int *r)
{ __asm__ volatile ("" : : :"memory"); }
int __attribute__((noinline)) foo(int x) {
int r = 0;
not_opt_this(&r);
return r;
}
int main (void) {
return foo (10);
}
GCC 7 prints the correct value, GCC 9 prints
[Bug middle-end/102415] [12 Regression] ICE in bb_seq_addr, at gimple.h:1786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102415 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c4432b2776aeeffee9125bf87ff937e4a8907bbd commit r12-3779-gc4432b2776aeeffee9125bf87ff937e4a8907bbd Author: Jakub Jelinek Date: Wed Sep 22 09:32:32 2021 +0200 openmp: Fix OpenMP expansion of scope with non-fallthrugh body [PR102415] I've used function for omp single expansion also for omp scope. That is mostly ok, but as the testcase shows, there is one important difference. The omp single expansion always has a fallthru body, because it during omp lowering expands the body as if wrapped in an if to simulate that one thread runs the body and others wait (unless nowait) until it completes and continue. omp scope is invoked by all threads and so if the body is non-fallthru, the barrier (unless nowait) at the end will not be reached by any of the threads. The following patch fixes that by handling the case where cfg pass optimizes away the exit bb of it gracefully. 2021-09-22 Jakub Jelinek PR middle-end/102415 * omp-expand.c (expand_omp_single): If region->exit is NULL, assert region->entry is GIMPLE_OMP_SCOPE region and return. * c-c++-common/gomp/scope-3.c: New test.
[Bug c++/92981] static anonymous union does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92981
Andrew Pinski changed:
What|Removed |Added
Component|ipa |c++
Summary|ICE in |static anonymous union does
|get_partitioning_class, at |not work
|symtab.c:1966 |
Keywords||link-failure
--- Comment #3 from Andrew Pinski ---
I don't know if this is a front-end issue or a middle-end issue.
The problem is unrelated to LTO really.
Take:
static union {
int yz;
int t;
};
struct ra {
static int &dy;
};
int &ra::dy = (yz);
bool
bm ()
{
return ra::dy == yz;
}
int main(void)
{
return !bm();
}
CUT -
With just -g0, we get a link failure:
/opt/compiler-explorer/gcc-trunk-20210922/bin/../lib/gcc/x86_64-linux-gnu/12.0.0/../../../../x86_64-linux-gnu/bin/ld:
/tmp/ccBdpNQh.o:(.rodata+0x0): undefined reference to `yz'
4.1.2 produced some interesting assembly too:
.local yz
.comm yz,4,4
.local yz
.comm yz,4,4
[Bug c++/92981] static anonymous union does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92981 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- So this is a dup of bug 53932. *** This bug has been marked as a duplicate of bug 53932 ***
[Bug c++/53932] [9/10/11/12 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 Andrew Pinski changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #1 from Andrew Pinski --- *** Bug 92981 has been marked as a duplicate of this bug. ***
[Bug c++/53932] [9/10/11/12 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #2 from Andrew Pinski --- For LTO, we ICE.
[Bug target/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 --- Comment #7 from CVS Commits --- The master branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:a9b3c451be58f0fe660154323ace7ba72a4211ec commit r12-3780-ga9b3c451be58f0fe660154323ace7ba72a4211ec Author: Andreas Krebbel Date: Wed Sep 22 09:32:21 2021 +0200 IBM Z: Fix PR10 Avoid emitting a strict low part move if the insv target actually affects the whole target reg. gcc/ChangeLog: PR target/10 * config/s390/s390.c (s390_expand_insv): Emit a normal move if it is actually a full copy of the source operand into the target. Don't emit a strict low part move if source and target mode match. gcc/testsuite/ChangeLog: * gcc.target/s390/pr10.c: New test.
[Bug ipa/102443] New: IPA CP and/or IPA VRP into OpenMP/OpenACC outlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102443
Bug ID: 102443
Summary: IPA CP and/or IPA VRP into OpenMP/OpenACC outlined
functions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
If IPA CP or IPA VRP can handle
struct whatever x;
x.fld1 = 123; // for IPA CP
if (y > 123 || y < 42) __builtin_unreachable ();
x.fld2 = y; // for IPA VRP
foo (&x);
and foo using x->fld1 or x->fld2 shortly after start, then it shouldn't be far
from handling also propagation into OpenMP/OpenACC regions, but there is one
big obstackle.
As can be seen in:
void
foo (void)
{
int x = 5;
int vla[x];
__builtin_memset (vla, 0, sizeof (vla));
#pragma omp parallel firstprivate (x)
{
x++;
}
#pragma omp teams firstprivate (x)
{
x++;
}
#pragma omp task firstprivate (x)
{
x++;
}
#pragma omp task firstprivate (x) firstprivate (vla)
{
x++;
vla[0]++;
}
#pragma omp taskwait
#pragma omp target firstprivate (x)
{
x++;
}
}
with -O2 -fopenmp, the outlined functions are never called directly, but
through a __builtin_GOMP_* function. So, would it be possible for IPA CP/VRP
purposes (but not for inlining etc.) treat e.g.
__builtin_GOMP_parallel (fn1, &struct1obj, ...)
as if it was fn1 (&struct1obj) call?
Similarly for
__builtin_GOMP_teams_reg (fn2, &struct2obj, ...)
as if it was fn2 (&struct2obj), or
__builtin_GOMP_task (fn3, &struct3obj, NULL, ...)
as if it was fn3 (&struct3obj). __builtin_GOMP_task has another case,
__builtin_GOMP_task (fn4, &struct4obj, cpyfn4, ...)
needs to be treated as
{
struct ... temp; // different from type of struct4obj
cpyfn4 (&temp, &struct4obj);
fn4 (&temp);
}
Finally, __builtin_GOMP_target_ext is more complicated, but if we handle only
firstprivate propagation perhaps still doable. And OpenACC has its own
builtins as well.
Now, because all the structs are compiler generated, omp-low.c could if it
would be beneficial to IPA propagation add some magic attributes (with spaces
in names) to certain fields (e.g. those that act as read-only with the body of
function, where value is never stored back and therefore it is ok to e.g.
replace all reads from that field with constants or annotate all reads from
that field into SSA_NAME with VRP data.
For IPA CP, at least for target one would need to limit to propagation of
INTEGER_CSTs/REAL_CSTs etc., but avoid propagation of static variable addresses
etc.
I'm unfortunately not very familiar with the jump functions/ipa propagation and
how to achieve the above.
[Bug c++/102444] New: class definition not allowed to change meaning of previously used name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102444
Bug ID: 102444
Summary: class definition not allowed to change meaning of
previously used name
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalo.gadeschi at gmail dot com
Target Milestone: ---
See http://eel.is/c++draft/class.member.lookup#6
[class.member.lookup]/p6: "If it [the result of the search] differs from the
result of a search in T for N from immediately after the class-specifier of T,
the program is ill-formed, no diagnostic required." A class definition is not
allowed to change the meaning of a name that was already used earlier in the
class definition.
While no diagnostic is required, I think a quality implementation like gcc
should produce a diagnostic here and reject this program since it is
ill-formed.
Example: https://gcc.godbolt.org/z/jhEj68Kq8
struct plus {
template
using invoke = void;
};
template
using invoke = typename Fn::template invoke;
template
struct compose
{
template
using F = invoke;
template
using invoke = invoke;
};
using Q = compose::F;
Is accepted by gcc.
[Bug libstdc++/102445] New: [meta-bug] std::regex issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445 Bug ID: 102445 Summary: [meta-bug] std::regex issues Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: ---
[Bug c++/102444] class definition not allowed to change meaning of previously used name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102444 Andrew Pinski changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill |a/show_bug.cgi?id=46983 |a/show_bug.cgi?id=96593 --- Comment #1 from Andrew Pinski --- I actually think this is a dup of bug 96593.
[Bug libstdc++/82164] AddressSanitizer: stack-buffer-overflow while constructing std::regex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82164 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Jonathan Wakely --- Closing after no response in three years. I can't reproduce this with any version of GCC either.
[Bug tree-optimization/102446] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446
Bug ID: 102446
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This seems to be a long-latent miscompilation, affecting GCC 5.1 and later.
[583] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210922 (experimental) [master r12-3777-g578b7687338] (GCC)
[584] %
[584] % gcctk -O2 small.c; ./a.out
[585] %
[585] % gcctk -O3 small.c
[586] % ./a.out
Segmentation fault
[587] %
[587] % cat small.c
int a = 1, c, e, f, *j, k, o, *r = &f, s;
char b, l;
short d, *g;
unsigned h;
static void m(void);
static void n(int);
void p(int *q) {
while (1) {
if (*q)
break;
if (*g)
o = c;
while (l)
;
}
}
void t() {
for (; s < 8; s++)
m();
}
void m() {
int aa = 0, i = 0;
for (; i < 3; i++)
if (k < 0)
aa |= *j;
if (d)
c = (h + *g + 2) & c;
n(aa);
}
void n(int ac) {
char *ad = &b, u = ac, *v = &b;
int ae = *ad = a;
u && (*v = e > 0);
*r = c;
p(&ae);
}
int main() {
t();
return 0;
}
[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84865 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Jonathan Wakely --- I'm closing this as a dup of one of the existing bugs about stack overflow. *** This bug has been marked as a duplicate of bug 86164 ***
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 Jonathan Wakely changed: What|Removed |Added CC||shaoqin2 at illinois dot edu --- Comment #10 from Jonathan Wakely --- *** Bug 84865 has been marked as a duplicate of this bug. ***
[Bug libstdc++/77744] Data race on std::regex_iterator using openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77744 --- Comment #7 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #3) > More importantly, the OpenMP version does not wait for the loop to finish > (or at least, I see "#pragma omp for nowait" in the GIMPLE dump), so there > is no happens-before relation between the loop body and the reTest > destructor. It does wait, the nowait there is just an optimization to avoid an unnecessary extra barrier when there is one at the end of the parallel (the inital thread doesn't continue until all other threads encountered the final barrier). Current OpenMP (5.0+) allows lambdas, but we don't really know if there is any race condition, as I said in #c5, tsan doesn't understand the libgomp barriers and locking which are done using atomics and futexes, so in order to use -fsanitize=thread together with libgomp the library needs to be built with --disable-linux-futex, then it uses pthread_* APIs tsan understands.
[Bug libstdc++/102445] [meta-bug] std::regex issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-09-22
[Bug c++/102444] class definition not allowed to change meaning of previously used name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102444 gnzlbg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from gnzlbg --- I think you are correct, closing this one as duplicate. Will repost my example there. *** This bug has been marked as a duplicate of bug 96593 ***
[Bug c++/96593] No "declaration changes meaning" diagnostic for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96593 gnzlbg changed: What|Removed |Added CC||gonzalo.gadeschi at gmail dot com --- Comment #2 from gnzlbg --- *** Bug 102444 has been marked as a duplicate of this bug. ***
[Bug c++/96593] No "declaration changes meaning" diagnostic for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96593
--- Comment #3 from gnzlbg ---
>From 102444 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102444):
See http://eel.is/c++draft/class.member.lookup#6
[class.member.lookup]/p6: "If it [the result of the search] differs from the
result of a search in T for N from immediately after the class-specifier of T,
the program is ill-formed, no diagnostic required." A class definition is not
allowed to change the meaning of a name that was already used earlier in the
class definition.
While no diagnostic is required, I think a quality implementation like gcc
should produce a diagnostic here and reject this program since it is
ill-formed.
Example (found in the wild): https://gcc.godbolt.org/z/jhEj68Kq8
struct plus {
template
using invoke = void;
};
template
using invoke = typename Fn::template invoke;
template
struct compose
{
template
using F = invoke;
template
using invoke = invoke;
};
using Q = compose::F;
Is accepted by gcc.
[Bug libstdc++/102447] New: std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447
Bug ID: 102447
Summary: std::regex incorrectly accepts invalid bracket
expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 102445
Target Milestone: ---
#include
#include
int main()
{
try {
std::regex{"[\\w-a]"};
assert(!"here");
} catch (const std::regex_error& e) {
assert(e.code() == std::regex_constants::error_range);
}
}
This should run and exit successfully, but with GCC we get:
a.out: reg.C:8: int main(): Assertion `!"here"' failed.
Aborted (core dumped)
The bracket expression [\w-a] is invalid.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
[Bug 102445] [meta-bug] std::regex issues
[Bug libstdc++/84110] Null character in regex throws std::regex_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84110 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-22
[Bug target/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:22b25535b8b2f9961e4772b1cc7cce5dc2f60719 commit r11-9025-g22b25535b8b2f9961e4772b1cc7cce5dc2f60719 Author: Andreas Krebbel Date: Wed Sep 22 09:32:21 2021 +0200 IBM Z: Fix PR10 Avoid emitting a strict low part move if the insv target actually affects the whole target reg. gcc/ChangeLog: PR target/10 * config/s390/s390.c (s390_expand_insv): Emit a normal move if it is actually a full copy of the source operand into the target. Don't emit a strict low part move if source and target mode match. gcc/testsuite/ChangeLog: * gcc.target/s390/pr10.c: New test. (cherry picked from commit a9b3c451be58f0fe660154323ace7ba72a4211ec)
[Bug tree-optimization/102446] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-09-22 Keywords||wrong-code Version|unknown |12.0 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. Happens with -O3 -fno-inline as well, -fdisable-tree-cunroll "fixes it", not further investigated.
[Bug tree-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|wrong code at -O3 on|[9/10/11/12 Regression] |x86_64-linux-gnu|wrong code at -O3 on ||x86_64-linux-gnu Target Milestone|--- |9.5 --- Comment #2 from Jakub Jelinek --- Started with r5-6477-g3620b606822f80863488ca4883542d848d41f9f9
[Bug tree-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446
--- Comment #3 from Richard Biener ---
void m() {
int aa = 0, i = 0;
for (; i < 3; i++)
if (k < 0)
aa |= *j;
Dump of assembler code for function m:
0x00400540 <+0>: mov0x200b16(%rip),%edi# 0x60105c
0x00400546 <+6>: mov0x200b13(%rip),%rax# 0x601060
0x0040054d <+13>:sar$0x1f,%edi
=> 0x00400550 <+16>:and(%rax),%edi
0x00400552 <+18>:cmpw $0x0,0x200af6(%rip)# 0x601050
so we're loading *j before checking k < 0. On GIMPLE that's OK:
[local count: 268435456]:
k.5_1 = k;
j.6_2 = j;
if (k.5_1 < 0)
goto ; [41.00%]
else
goto ; [59.00%]
[local count: 110058537]:
j.6__lsm0.31_28 = *j.6_2;
[local count: 268435456]:
# aa_9 = PHI
but RTL if-conversion makes the load unconditional.
(insn 13 12 35 3 (set (reg/v:SI 89 [ j.6__lsm0.31 ])
(mem:SI (reg/f:DI 83 [ j.6_2 ]) [1 *j.6_2+0 S4 A32])) 77
{*movsi_internal}
(expr_list:REG_DEAD (reg/f:DI 83 [ j.6_2 ])
(nil)))
I don't see any flags marking it as not trapping?
Re: [Bug tree-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
> Started with r5-6477-g3620b606822f80863488ca4883542d848d41f9f9 This only affects early inlining decisions, so it may be useful to bisect this with --param early-inlining-insns=14 Honza
[Bug tree-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 --- Comment #4 from Jan Hubicka --- > Started with r5-6477-g3620b606822f80863488ca4883542d848d41f9f9 This only affects early inlining decisions, so it may be useful to bisect this with --param early-inlining-insns=14 Honza
[Bug rtl-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Component|tree-optimization |rtl-optimization
[Bug rtl-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 --- Comment #5 from Richard Biener --- (In reply to Jan Hubicka from comment #4) > > Started with r5-6477-g3620b606822f80863488ca4883542d848d41f9f9 > This only affects early inlining decisions, so it may be useful to > bisect this with --param early-inlining-insns=14 > > Honza It's also miscompiled with -fno-inline.
[Bug preprocessor/82469] ICE in _cpp_process_line_notes, at libcpp/lex.c:1066
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82469 --- Comment #2 from Heiko Eißfeldt --- I took me a while to find a platform of mine where I got this error. Right now it happens here as well: Message: cpp --traditional -ffreestanding -P gcc_82469.c : internal compiler error: in _cpp_process_line_notes, at libcpp/lex.c:1163 OS: Raspberry Pi, 32-Bit, Linux uname -a Linux raspberrypi 5.10.17-v7l+ #1421 SMP Thu May 27 14:00:13 BST 2021 armv7l GNU/Linux file /usr/bin/arm-linux-gnueabihf-cpp-8: /usr/bin/arm-linux-gnueabihf-cpp-8: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=f4424fc857eedcaef7da81cf953c3ae2788523e7, stripped gcc --version gcc (Raspbian 8.3.0-6+rpi1) 8.3.0 cpp --version cpp (Raspbian 8.3.0-6+rpi1) 8.3.0 Hardware is a Raspberry Pi Model 4 with 4GB. Thanks.
[Bug rtl-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446
--- Comment #6 from Jakub Jelinek ---
int a = 1, c, e, f, *j, k, o, *r = &f, s;
char b, l;
short d, *g;
unsigned h;
static void m(void);
static inline void n(int);
void p(int *q) {
while (1) {
if (*q)
break;
if (*g)
o = c;
while (l)
;
}
}
void t() {
for (; s < 8; s++)
m();
}
__attribute__((noinline)) void m() {
int aa = 0, i = 0;
for (; i < 3; i++)
if (k < 0)
aa |= *j;
if (d)
c = (h + *g + 2) & c;
n(aa);
}
static inline __attribute__((always_inline)) void n(int ac) {
char *ad = &b, u = ac, *v = &b;
int ae = *ad = a;
u && (*v = e > 0);
*r = c;
p(&ae);
}
int main() {
t();
return 0;
}
ICEs already in r105000.
[Bug rtl-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 --- Comment #7 from Jakub Jelinek --- I mean segfaults at runtime, not ICEs.
[Bug rtl-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=23567 --- Comment #8 from Andrew Pinski --- (In reply to Richard Biener from comment #3) > I don't see any flags marking it as not trapping? Related to PR 23567 (which was fixed but maybe not fully).
[Bug rtl-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 --- Comment #9 from Jakub Jelinek --- I think PR23567 is quite different, that was about stores to a place that might not be writable, this is about making a possibly trapping conditional load being unconditional.
[Bug preprocessor/102432] [11/12 Regression] ICE in _cpp_lex_direct with function like macro without arguments within "pragma omp" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102432 --- Comment #4 from Jakub Jelinek --- Started with r11-4686-g8bd9a00f4349ebcd65223e3dcdfe83867e417287
[Bug middle-end/102415] [12 Regression] ICE in bb_seq_addr, at gimple.h:1786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102415 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/102448] New: [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448 Bug ID: 102448 Summary: [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tnfchris at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Since g:24f99147b9264f8f7d9cfb2fa6bd431edfa252d2 we've been getting a segfault on gcc in spec2017. It looks like ira_init has been miscompiled and an additional unconditional store materialized: Before: add x1, x19, #0x4 add x2, x19, #0x14 ldr q0, [x0,#4064] str q0, [x1],#16 After: add x19, x19, #0x4 ldr q0, [x0,#4000] str q0, [x19],#16 str q0, [x19],#16 so it's pushing 16 bytes more into x19 than it did before. Trying to see if I can reduce a testcase
[Bug c++/102449] New: template parameter with default argument is used without being verified during explicit specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102449
Bug ID: 102449
Summary: template parameter with default argument is used
without being verified during explicit specialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The following snippet code should be rejected because "First" should be checked
with its default argument which is "char"
template
void foo(First,T){}
template<>
void foo(int,double){}
[Bug ada/102450] New: GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 Bug ID: 102450 Summary: GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-* (32-bit) Target: hppa*-*-* (32-bit) Build: hppa*-*-* (32-bit) /home/dave/gnu/gcc/objdir/./gcc/xgcc -B/home/dave/gnu/gcc/objdir/./gcc/ -B/opt/g nu/gcc/gcc-12/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-12/hppa2.0w-hp-hpux1 1.11/lib/ -isystem /opt/gnu/gcc/gcc-12/hppa2.0w-hp-hpux11.11/include -isystem /o pt/gnu/gcc/gcc-12/hppa2.0w-hp-hpux11.11/sys-include -fchecking=1 -c -g -O2 -f PIC -W -Wall -gnatpg -nostdinc s-regpat.adb -o s-regpat.o during GIMPLE pass: lower +===GNAT BUG DETECTED==+ | 12.0.0 20210922 (experimental) (hppa2.0w-hp-hpux11.11) GCC error:| | in set_min_and_max_values_for_integral_type, at stor-layout.c:2851 | | Error detected around s-regpat.adb:345:4 | | Compiling s-regpat.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). system.ads s-regpat.adb s-regpat.ads s-io.ads ada.ads a-charac.ads a-chahan.ads a-unccon.ads s-exctab.ads s-stalib.ads a-except.ads s-parame.ads s-traent.ads s-valint.ads s-unstyp.ads s-valuns.ads s-valueu.ads s-valuei.ads s-imgcha.ads s-secsta.ads s-stoele.ads s-imgint.ads s-imagei.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:414 make[7]: *** [../gcc-interface/Makefile:300: s-regpat.o] Error 1 make[7]: Leaving directory '/home/dave/gnu/gcc/objdir/gcc/ada/rts' make[6]: *** [gcc-interface/Makefile:627: gnatlib] Error 2 make[6]: Leaving directory '/home/dave/gnu/gcc/objdir/gcc/ada' make[5]: *** [gcc-interface/Makefile:662: gnatlib-shared-default] Error 2 make[5]: Leaving directory '/home/dave/gnu/gcc/objdir/gcc/ada' Also occurs on Linux: https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=hppa&ver=1%3A20210918-1&stamp=1632002454&raw=0
[Bug tree-optimization/102448] [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448 Richard Biener changed: What|Removed |Added Target||aarch64 Target Milestone|--- |12.0 --- Comment #1 from Richard Biener --- The rev. in question should only affect alignment info on a SSA name.
[Bug tree-optimization/102451] New: Suspicious null-pointer dereference in delete_dead_or_redundant_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102451
Bug ID: 102451
Summary: Suspicious null-pointer dereference in
delete_dead_or_redundant_call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
Target Milestone: ---
In the code snippet:
if (lhs)
{
if (gsi_replace (gsi, new_stmt, true))
bitmap_set_bit (need_eh_cleanup, gimple_bb (stmt)->index);
}
else
{
if (gsi_remove (gsi, true))
bitmap_set_bit (need_eh_cleanup, gimple_bb (stmt)->index);
}
It is known that "gsi" points to "stmt", and gsi_replace/gsi_remove will clear
basic block of "stmt". Then bitmap_set_bit will dereference "index" from null
bb.
[Bug c++/102413] [12 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102413 --- Comment #1 from Jakub Jelinek --- Created attachment 51493 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51493&action=edit gcc12-pr102413.patch Untested fix.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 --- Comment #12 from CVS Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:3087d1b0a2cbe8880ccbbb67744726ff4e5d390e commit r12-3791-g3087d1b0a2cbe8880ccbbb67744726ff4e5d390e Author: Jiufu Guo Date: Wed Sep 22 13:20:29 2021 +0800 Set bound/cmp/control for until wrap loop. In patch r12-3136, niter->control, niter->bound and niter->cmp are derived from number_of_iterations_lt. While for 'until wrap condition', the calculation in number_of_iterations_lt is not align the requirements on the define of them and requirements in determine_exit_conditions. This patch calculate niter->control, niter->bound and niter->cmp in number_of_iterations_until_wrap. gcc/ChangeLog: 2021-09-22 Jiufu Guo PR tree-optimization/102087 * tree-ssa-loop-niter.c (number_of_iterations_until_wrap): Update bound/cmp/control for niter. gcc/testsuite/ChangeLog: 2021-09-22 Jiufu Guo * gcc.dg/pr102087.c: New test. PR tree-optimization/102087
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-09-22 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- what's MAX_BITSIZE_MODE_ANY_INT in insn-modes.h? (in the build directory) I think it should correspond to TImode and thus be 16 * BITS_PER_UNIT which means that we're building an INTEGER_TYPE bigger than TImode - can you confirm that? Unfortunately gnat doesn't provide backtraces, so a backtrace from gdb would also be nice.
[Bug tree-optimization/102451] Suspicious null-pointer dereference in delete_dead_or_redundant_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102451 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-09-22 CC||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Version|unknown |12.0 --- Comment #1 from Richard Biener --- Confirmed. Mind fixing it by recording the basic-block index before removing/replacing?
[Bug c/102452] New: Structs with flexible array members are not optimized on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102452
Bug ID: 102452
Summary: Structs with flexible array members are not optimized
on stack
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at peterzhu dot ca
Target Milestone: ---
Created attachment 51494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51494&action=edit
test.c
Structs with flexible array members are not optimized on the stack. Testing
with the test.c file shown below (which outputs the runtime in seconds), we see
that the compiled program is significantly slower when the struct has a
flexible array member than when it does not. This was tested on GCC 9.3.0 and
10.3.0 on Ubuntu 20.04.
$ gcc -O3 test.c
$ ./a.out
0.302769
$ gcc -O3 -DUSE_FLEX_ARR=1 test.c
$ ./a.out
0.728760
clang does not have this issue.
$ clang -O3 test.c
$ ./a.out
0.312194
$ clang -O3 -DUSE_FLEX_ARR=1 test.c
$ ./a.out
0.301175
This is what test.c looks like:
#include
#include
#include
#include
struct Test {
long is_a;
union {
struct {
long one;
long two;
long three;
} a;
struct {
int one;
int two;
int three;
int four;
#if USE_FLEX_ARR
char arr[];
#endif
} b;
} as;
};
#define COUNT 1
static inline struct Test make_test_a(struct Test *test)
{
if (test->is_a) {
return *test;
} else {
struct Test ret;
ret.as.a.one = test->as.b.one;
ret.as.a.two = test->as.b.two;
ret.as.a.three = test->as.b.three;
return ret;
}
}
/* This function should be optimized to not allocate struct Test on the stack
* since it only uses attribute "three". */
static inline long get_three(struct Test *test)
{
return make_test_a(test).as.a.three;
}
int main(int argc, char *argv[])
{
struct timespec start, end;
struct Test *mem = malloc(sizeof(struct Test) * COUNT);
memset(mem, 0, sizeof(struct Test) * COUNT);
clock_gettime(CLOCK_MONOTONIC, &start);
{
for (int i = 0; i < COUNT; i++) {
long three = get_three(&mem[i]);
if (three) {
/* Impossible case. */
printf("what\n");
}
}
}
clock_gettime(CLOCK_MONOTONIC, &end);
double time = (end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) /
10.0;
printf("%f\n", time);
return 0;
}
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #2 from dave.anglin at bell dot net --- On 2021-09-22 9:14 a.m., rguenth at gcc dot gnu.org wrote: > what's MAX_BITSIZE_MODE_ANY_INT in insn-modes.h? (in the build directory) > I think it should correspond to TImode and thus be 16 * BITS_PER_UNIT which > means that we're building an INTEGER_TYPE bigger than TImode - can you confirm > that? #define BITS_PER_UNIT (8) #define MAX_BITSIZE_MODE_ANY_INT (16*BITS_PER_UNIT) #define MAX_BITSIZE_MODE_ANY_MODE (32*BITS_PER_UNIT) However, TImode is not supported on this target. (gdb) ignor 1 325 Will ignore next 325 crossings of breakpoint 1. (gdb) r Starting program: /home/dave/gnu/gcc/objdir/gcc/gnat1 -quiet -nostdinc -O2 -Wext ra -Wall -dumpbase s-regpat.adb -dumpbase-ext .adb -gnatwa -fchecking=1 -g -fPIC -gnatpg -gnatO s-regpat.o s-regpat.adb -o s-regpat.s Breakpoint 1, _Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop (type=, precision=256, sgn=UNSIGNED) at ../../gcc/gcc/stor-layout.c:2851 2851 gcc_assert (precision <= WIDE_INT_MAX_PRECISION); (gdb) p precision $2 = 256 (gdb) disass $pc-16,$pc+16 Dump of assembler code from 0xfbc244 to 0xfbc264: 0x00fbc244 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+36>: stw r7,-70(sp) 0x00fbc248 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+40>: stw r6,-6c(sp) 0x00fbc24c <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+44>: cmpib,>= 0,r25,0xfbc2d4 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+180> 0x00fbc250 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+48>: copy r26,r3 => 0x00fbc254 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+52>: ldi c0,ret0 0x00fbc258 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+56>: cmpb,< ret0,r25,0xfbc2fc <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+220> 0x00fbc25c <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+60>: copy r24,r25 0x00fbc260 <_Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop+64>: ldo -98(sp),r6 End of assembler dump. (gdb) p $ret0 $3 = 8388608 (gdb) p 0xc0 $4 = 192 (gdb) p $r25 $5 = 256 (gdb) bt #0 _Z40set_min_and_max_values_for_integral_typeP9tree_nodei6signop ( type=, precision=256, sgn=UNSIGNED) at ../../gcc/gcc/stor-layout.c:2851 #1 0x00fc0b9c in _Z18make_unsigned_typei (precision=256) at ../../gcc/gcc/stor-layout.c:2885 #2 0x000da2b4 in _Z18gnat_type_for_sizeji (precision=256, unsignedp=256) at ../../gcc/gcc/ada/gcc-interface/utils.c:3670 #3 0x00b05c2c in gimple_fold_builtin_memory_op(gimple_stmt_iterator*, tree_node*, tree_node*, built_in_function) (v=@0x79aebb68, reserve=256, exact=true) at ../../gcc/gcc/gimple-fold.c:1004 #4 0x00afffac in _ZL11fold_stmt_1P20gimple_stmt_iteratorbPFP9tree_nodeS2_E ( gsi=0x7a001018, inplace=true, valueize=0x79ae8b58) at ../../gcc/gcc/gimple-fold.c:5054 #5 0x00b13668 in _ZL10lower_stmtP20gimple_stmt_iteratorP10lower_data ( gsi=..., data=0x7a000fa4) at ../../gcc/gcc/gimple-low.c:390 #6 0x00b1405c in _ZL17lower_gimple_bindP20gimple_stmt_iteratorP10lower_data ( gsi=0x7a000f98, data=0x7a000fa4) at ../../gcc/gcc/gimple-low.c:217 #7 0x00b146a0 in _ZN12_GLOBAL__N_113pass_lower_cf7executeEP8function ( this=0x79ab92a0) at ../../gcc/gcc/gimple-low.c:110 #8 0x00e8b140 in _Z16execute_one_passP8opt_pass (pass=0x40716078) at ../../gcc/gcc/passes.c:2567 #9 0x00e8ba2c in _ZL19execute_pass_list_1P8opt_pass (pass=0x40716078) at ../../gcc/gcc/passes.c:2656 ---Type to continue, or q to quit--- #10 0x00e8bad0 in _Z17execute_pass_listP8functionP8opt_pass (fn=0x79ab92a0, pass=0x100) at ../../gcc/gcc/passes.c:2667 #11 0x00906578 in _ZN11cgraph_node7analyzeEv (this=) at ../../gcc/gcc/cgraphunit.c:680 #12 0x009098e0 in _ZL17analyze_functionsb (first_time=148) at ../../gcc/gcc/cgraphunit.c:1234 #13 0x0090a6c8 in _ZN12symbol_table25finalize_compilation_unitEv ( this=0x79c59000) at ../../gcc/gcc/cgraphunit.c:2508 #14 0x00fcd444 in _ZL12compile_filev () at ../../gcc/gcc/toplev.c:483 #15 0x00fd0d5c in _ZN6toplev4mainEiPPc (this=0x7a000a98, argc=0, argv=0x0) at ../../gcc/gcc/toplev.c:2233 #16 0x01461b40 in main (argc=20, argv=0x7a0008f4) at ../../gcc/gcc/main.c:39
[Bug rtl-optimization/102062] powerpc suboptimal unrolling simple array sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062 Nicholas Piggin changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Nicholas Piggin --- gcc-11 -O2 -mcpu=power10 now generates identical code that Bill listed for trunk: .L2: lwz 4,4(9) lwz 5,12(9) lwz 6,8(9) lwzu 8,16(9) add 10,4,10 add 10,10,5 add 7,6,7 add 7,7,8 bdnz .L2 Thanks all.
[Bug rtl-optimization/102356] [11/12 Regression] compile-time explosion at -O3 -g in var-tracking since r11-209-g74dc179a6da33cd0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102356 --- Comment #3 from Vladimir Makarov --- (In reply to Martin Liška from comment #2) > If I see correctly, it started with r11-209-g74dc179a6da33cd0. Yes, I am confirming that my patch triggered the slow down. But the actual problem is not RA, it is in scalability of var-tracking pass. I'll investigate more can I fix it in RA and is it worth to fix it in RA.
[Bug c++/100493] Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493 Mathias Stearn changed: What|Removed |Added CC||redbeard0531 at gmail dot com --- Comment #2 from Mathias Stearn --- This is making it harder for us to transition to -std=c++20, since we can't have the same code be warning-clean in both versions. I really don't think the warning for [=, this] is helpful given that it is the pattern that is now recommended.
[Bug c++/100493] Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493 --- Comment #3 from Mathias Stearn --- When reading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82611, I noticed that C++17 actually requires the warning on [=, this] from a conforming implementation: https://timsong-cpp.github.io/cppwp/n4659/expr.prim.lambda.capture#2. However, given that this requirement was lifted in C++20, would it be possible to only warn about that in -std=c++17 (or lower) with -pedantic? It seems counterproductive to warn about it without -pedantic.
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #3 from dave.anglin at bell dot net --- This occurs in stage3, so it's probably an optimization bug.
[Bug middle-end/102453] New: buffer overflow by atomic built-ins not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102453
Bug ID: 102453
Summary: buffer overflow by atomic built-ins not diagnosed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The buffer overflow by the straight assignment in f() below is diagnosed as
expected but the equivalent overflow by the atomic built-in in g() is not even
though both should be. The problem is simply that due to an oversight, the
access warnings lack support for atomic built-ins.
$ cat y.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout y.c
extern _Atomic char x;
void f (void)
{
long *p = (long*)&x;
*p = 0;
}
void g (void)
{
long *p = (long*)&x;
__atomic_store_n (p, 0, 0);
}
y.c: In function ‘f’:
y.c:7:3: warning: array subscript ‘long int[0]’ is partly outside array bounds
of ‘_Atomic char[1]’ [-Warray-bounds]
7 | *p = 0;
| ^~
y.c:1:21: note: object ‘x’ of size 1
1 | extern _Atomic char x;
| ^
;; Function f (f, funcdef_no=0, decl_uid=1979, cgraph_uid=1, symbol_order=0)
void f ()
{
[local count: 1073741824]:
MEM[(long int *)&x] = 0;
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1983, cgraph_uid=2, symbol_order=1)
void g ()
{
[local count: 1073741824]:
__atomic_store_8 (&x, 0, 0); [tail call]
return;
}
[Bug middle-end/102453] buffer overflow by atomic built-ins not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102453 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Keywords||diagnostic Blocks||56456 Ever confirmed|0 |1 Last reconfirmed||2021-09-22 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c++/102412] Template argument deduction fails when using concept as defaulted non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102412 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9329344a6d81a6a5e3bd171167ebc7b158bb44f4 commit r12-3822-g9329344a6d81a6a5e3bd171167ebc7b158bb44f4 Author: Patrick Palka Date: Wed Sep 22 11:16:53 2021 -0400 c++: concept-ids and value-dependence [PR102412] The problem here is that uses_template_parms returns true for all concept-ids (even those with non-dependent arguments), so when a concept-id is used as a default template argument then during deduction the default argument is considered dependent even after substituting into it, which leads to deduction failure (from type_unification_real). This patch fixes this by implementing the resolution of CWG 2446 which says a concept-id is dependent only if its arguments are. DR 2446 PR c++/102412 gcc/cp/ChangeLog: * constexpr.c (cxx_eval_constant_expression) : Check value_dependent_expression_p instead of processing_template_decl. * pt.c (value_dependent_expression_p) : Return true only if any_dependent_template_arguments_p. (instantiation_dependent_r) : Remove this case. : Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-nondep2.C: New test. * g++.dg/cpp2a/concepts-nondep3.C: New test.
[Bug c++/102454] New: [12 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102454
Bug ID: 102454
Summary: [12 Regression] ICE in gimplify_var_or_parm_decl, at
gimplify.c:2958
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-12.0.0-alpha20210919 snapshot (g:32731fa5b0abf092029b8e2be64319b978bda514)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/g++.dg/coroutines/torture/co-yield-04-complex-local-state.C, w/
-fcoroutines -fno-exceptions:
#include
#include
template
struct looper {
struct promise_type {
auto get_return_object () { return handle_type::from_promise (*this); }
auto initial_suspend () { return suspend_always_prt {}; }
auto final_suspend () noexcept { return suspend_always_prt {}; }
void return_value (T);
void unhandled_exception ();
};
using handle_type = std::coroutine_handle;
looper (handle_type);
struct suspend_always_prt {
bool await_ready () noexcept;
void await_suspend (handle_type) noexcept;
void await_resume () noexcept;
};
};
template
looper
with_ctorable_state (T)
{
co_return T ();
}
auto
foo ()
{
return with_ctorable_state;
}
% g++-12.0.0 -fcoroutines -fno-exceptions -c n7pshqai.C
n7pshqai.C: In function 'looper with_ctorable_state(T) [with T =
std::__cxx11::basic_string]':
n7pshqai.C:27:1: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:2958
27 | with_ctorable_state (T)
| ^~~
0x7984d0 gimplify_var_or_parm_decl
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:2958
0xe96100 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:15029
0xeaefd3 gimplify_modify_expr
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:5960
0xe960ed gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:14568
0xeb0f2b gimplify_cleanup_point_expr
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:7006
0xe964f1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:14961
0xe999d6 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:7006
0xe9746b gimplify_statement_list
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:1997
0xe9746b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:15013
0xe999d6 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:7006
0xe9a28f gimplify_bind_expr
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:1426
0xe967b4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:14769
0xeb04d6 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:7006
0xeb04d6 gimplify_body(tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:15814
0xeb094d gimplify_function_tree(tree_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/gimplify.c:15968
0xcce107 cgraph_node::analyze()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/cgraphunit.c:670
0xcd0d57 analyze_functions
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/cgraphunit.c:1234
0xcd1a3d symbol_table::finalize_compilation_unit()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210919/work/gcc-12-20210919/gcc/cgraphunit.c:2508
[Bug c++/102455] New: ICE in verify_ctor_sanity, at cp/constexpr.c:4451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102455
Bug ID: 102455
Summary: ICE in verify_ctor_sanity, at cp/constexpr.c:4451
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5 (with -std=c++14) :
$ cat z1.cc
typedef int v4si;
typedef float v4sf __attribute__ ((vector_size(4)));
constexpr v4sf foo (v4si) { for (;;) {} }
template constexpr v4sf b = foo (v4si {});
$ g++-12-20210919 -c z1.cc
z1.cc:4:49: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:4451
4 | template constexpr v4sf b = foo (v4si {});
| ^
0x6e1221 verify_ctor_sanity
../../gcc/cp/constexpr.c:4450
0x6ef919 cxx_eval_bare_aggregate
../../gcc/cp/constexpr.c:4493
0x6e5e73 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6793
0x6e353b cxx_bind_parameters_in_call
../../gcc/cp/constexpr.c:1644
0x6e353b cxx_eval_call_expression
../../gcc/cp/constexpr.c:2617
0x6e7174 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6336
0x6e5bb5 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6828
0x6e964b cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:7368
0x6ec82a fold_non_dependent_expr_template
../../gcc/cp/constexpr.c:7720
0x87abb4 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:777
0x73210d check_initializer
../../gcc/cp/decl.c:7277
0x734457 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:8077
0x7f3caf cp_parser_init_declarator
../../gcc/cp/parser.c:22665
0x7f6ba6 cp_parser_single_declaration
../../gcc/cp/parser.c:31569
0x7f6dc5 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:31134
0x7f758b cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:31400
0x7f758b cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:31419
0x7f97e9 cp_parser_declaration
../../gcc/cp/parser.c:14750
0x7fa4ab cp_parser_translation_unit
../../gcc/cp/parser.c:4978
0x7fa4ab c_parse_file()
../../gcc/cp/parser.c:47694
[Bug fortran/102456] New: ICE in gfc_check_rank, at fortran/check.c:4594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102456 Bug ID: 102456 Summary: ICE in gfc_check_rank, at fortran/check.c:4594 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p type t integer :: a end type type(t) :: x[*] print *, rank(x[1]) end $ gfortran-12-20210919 -c z1.f90 -fcoarray=single $ $ gfortran-12-20210919 -c z1.f90 -fcoarray=lib f951: internal compiler error: Segmentation fault 0xc8446f crash_signal ../../gcc/toplev.c:328 0x6afceb gfc_check_rank(gfc_expr*) ../../gcc/fortran/check.c:4594 0x6eddf9 do_check ../../gcc/fortran/intrinsic.c:4786 0x6eddf9 check_specific ../../gcc/fortran/intrinsic.c:4799 0x6f81b4 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:5036 0x74a859 resolve_unknown_f ../../gcc/fortran/resolve.c:2937 0x74a859 resolve_function ../../gcc/fortran/resolve.c:3281 0x74a859 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7115 0x750d44 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7082 0x750d44 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11876 0x74f68f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10892 0x74fa58 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11866 0x752397 resolve_codes ../../gcc/fortran/resolve.c:17479 0x75245e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17514 0x73a874 resolve_all_program_units ../../gcc/fortran/parse.c:6511 0x73a874 gfc_parse_file() ../../gcc/fortran/parse.c:6763 0x78761f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102457] New: [PDT] ICE in fold_convert_const_int_from_real, at fold-const.c:2034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102457 Bug ID: 102457 Summary: [PDT] ICE in fold_convert_const_int_from_real, at fold-const.c:2034 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r8 (type mismatch/non-constant) : $ cat z1.f90 subroutine s real :: m = 2 type t(n) integer, len :: n = 1 character(n*n) :: c end type type(t(m)) :: x call h(x) end $ gfortran-12-20210919 -c z1.f90 -O2 during GIMPLE pass: ccp z1.f90:1:12: 1 | subroutine s |^ internal compiler error: in fold_convert_const_int_from_real, at fold-const.c:2034 0x98904b fold_convert_const_int_from_real ../../gcc/fold-const.c:2034 0x98904b fold_convert_const ../../gcc/fold-const.c:2280 0x99f05d const_unop(tree_code, tree_node*, tree_node*) ../../gcc/fold-const.c:1741 0x10773fe gimple_resimplify1 ../../gcc/gimple-match-head.c:212 0x11ab337 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*)) ../../gcc/gimple-match-head.c:948 0x9d289f gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*)) ../../gcc/gimple-fold.c:7350 0xd6e279 ccp_fold ../../gcc/tree-ssa-ccp.c:1289 0xd6e279 evaluate_stmt ../../gcc/tree-ssa-ccp.c:2207 0xd6f92d visit_assignment ../../gcc/tree-ssa-ccp.c:2840 0xdfaad3 ssa_propagation_engine::simulate_stmt(gimple*) ../../gcc/tree-ssa-propagate.c:230 0xdfad4a ssa_propagation_engine::simulate_block(basic_block_def*) ../../gcc/tree-ssa-propagate.c:337 0xdfb252 ssa_propagation_engine::ssa_propagate() ../../gcc/tree-ssa-propagate.c:504 0xd65725 do_ssa_ccp ../../gcc/tree-ssa-ccp.c:2959 0xd65725 execute ../../gcc/tree-ssa-ccp.c:3003 --- z1.f90:1:12: 1 | subroutine s |^ Error: type mismatch in binary expression integer(kind=4) real(kind=4) real(kind=4) _5 = m.1_3 * m.2_4; z1.f90:1:12: internal compiler error: 'verify_gimple' failed 0xe7461d verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:5228 0xb16a51 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:15897 0xb16cf7 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:15968 0x9338c7 cgraph_node::analyze() ../../gcc/cgraphunit.c:670 0x936a86 analyze_functions ../../gcc/cgraphunit.c:1234 0x937c8d symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2508
[Bug fortran/102458] New: ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 Bug ID: 102458 Summary: ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 subroutine s integer :: a(command_argument_count()) = 1 print *, a end $ gfortran-12-20210919 -c z1.f90 z1.f90:1:12: 1 | subroutine s |1 internal compiler error: tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136 0x6938d8 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:8689 0x7de241 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3427 0x7de241 gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../gcc/fortran/trans-array.c:6133 0x81f1b0 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:8014 0x7ff6ca gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1940 0x80324f generate_local_decl ../../gcc/fortran/trans-decl.c:5989 0x7b3592 do_traverse_symtree ../../gcc/fortran/symbol.c:4170 0x80479c generate_local_vars ../../gcc/fortran/trans-decl.c:6195 0x80479c gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6854 0x77be66 translate_all_program_units ../../gcc/fortran/parse.c:6572 0x77be66 gfc_parse_file() ../../gcc/fortran/parse.c:6841 0x7c90df gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- There are several variants : $ cat z3.f90 subroutine s integer :: a(num_images()) = 1 print *, a end $ cat z4.f90 subroutine s integer :: a(this_image()) = 1 print *, a end $ cat z7.f90 subroutine s integer :: a(command_argument_count()) = 1 a = 2 end $ cat z8.f90 program p block integer :: a(command_argument_count()) = 1 print *, a end block end $ cat za.f90 function f() integer :: a(command_argument_count()) = 0 a = 1 end $ cat zb.f90 program p block integer :: n(command_argument_count()) = 0 n = 1 end block end $ gfortran-12-20210919 -c zb.f90 zb.f90:3:44: 3 | integer :: n(command_argument_count()) = 0 |1 internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:6426 0x797a5b gfc_trans_auto_array_allocation(tree_node*, gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-array.c:6426 0x7b1f17 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-decl.c:4921 0x8054e1 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2311 0x78e4a7 trans_code ../../gcc/fortran/trans.c:2014 0x7b4c04 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6919 0x73af76 translate_all_program_units ../../gcc/fortran/parse.c:6572 0x73af76 gfc_parse_file() ../../gcc/fortran/parse.c:6841 0x78761f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102459] New: [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102459 Bug ID: 102459 Summary: [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3549 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20210523 and 20210530, with an array a : $ cat z1.f90 program p type t integer :: a(2) end type type(t) :: x(8) !$omp task depend (iterator(j=1:8), out:x(j)%a) !$omp end task end $ gfortran-12-20210919 -c z1.f90 -fopenmp z1.f90:6:50: 6 |!$omp task depend (iterator(j=1:8), out:x(j)%a) | 1 internal compiler error: Segmentation fault 0xe2831f crash_signal ../../gcc/toplev.c:328 0x7d88a6 gfc_conv_scalarized_array_ref ../../gcc/fortran/trans-array.c:3549 0x7d95c4 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc/fortran/trans-array.c:3700 0x81b5ce gfc_conv_variable ../../gcc/fortran/trans-expr.c:3093 0x81623a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9041 0x820212 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool) ../../gcc/fortran/trans-expr.c:9141 0x85e1e4 gfc_trans_omp_clauses ../../gcc/fortran/trans-openmp.c:2864 0x867ae8 gfc_trans_omp_task ../../gcc/fortran/trans-openmp.c:6380 0x867ae8 gfc_trans_omp_directive(gfc_code*) ../../gcc/fortran/trans-openmp.c:7206 0x7d1857 trans_code ../../gcc/fortran/trans.c:2212 0x804a75 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6919 0x77be66 translate_all_program_units ../../gcc/fortran/parse.c:6572 0x77be66 gfc_parse_file() ../../gcc/fortran/parse.c:6841 0x7c90df gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug ipa/102452] Structs with flexible array members are not optimized on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102452 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization CC||marxin at gcc dot gnu.org Component|c |ipa --- Comment #1 from Andrew Pinski --- The difference shows up during inlining
[Bug c++/102454] [12 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102454 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug fortran/102460] New: fortran internal compile error in coverage.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460 Bug ID: 102460 Summary: fortran internal compile error in coverage.c Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: davidsch at fedoraproject dot org Target Milestone: --- Created attachment 51495 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51495&action=edit two source files and the compile commands to reproduce the issue the exact version of GCC: gcc-gfortran-11.2.1-1.fc34.x86_64 GNU Fortran (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) the system type: Fedora 34 the options given when GCC was configured/built: Not sure, Fedoras default the complete command line that triggers the bug: f95 -ftest-coverage -save-temps -c MOD2.f the compiler output (error messages, warnings, etc.): during IPA pass: profile MOD2.f:6:9: 6 | USE MOD1,only : f1 | ^ internal compiler error: in coverage_begin_function, at coverage.c:662 Please submit a full bug report, with preprocessed source if appropriate. the preprocessed file (*.i*) that triggers the bug: No *.i* files are generated. I have attached two source files and the compile commands as attachment. PS: I have observed the same issue on debian with gcc 10, while gcc 8 works. PPS: Without coverage instruction, no error is raised.
[Bug c++/102455] ICE in verify_ctor_sanity with vector types in constexpr and variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102455
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|ICE in verify_ctor_sanity |ICE in verify_ctor_sanity
|with vector types in|with vector types in
|constexpr |constexpr and variable
||template
Status|UNCONFIRMED |NEW
Keywords||ice-on-valid-code
Last reconfirmed||2021-09-22
--- Comment #1 from Andrew Pinski ---
The infinite loop is not needed:
typedef int v4si;
typedef float v4sf __attribute__ ((vector_size(4)));
constexpr v4sf foo (v4si a) { return (v4sf)a;}
template constexpr v4sf b = foo (v4si {});
[Bug rtl-optimization/102147] IRA dependent on 32-bit vs 64-bit pointer size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147
--- Comment #7 from Vladimir Makarov ---
I've been thinking about ways to fix this problem but only come to the
following patch. The patch results in working mostly the same for 64-bit
targets and different for 32-bit targets. In any case the profitability is only
an estimation so I think the patch is ok. Avoiding 4 stage bootstrap is more
important than a bit slower RA on 32-bit targets (which is questionable) on few
border cases.
I am going to commit the patch this Friday.
--- a/gcc/ira-build.c
+++ b/gcc/ira-build.c
@@ -629,7 +629,7 @@ ior_hard_reg_conflicts (ira_allocno_t a, const_hard_reg_set
set)
bool
ira_conflict_vector_profitable_p (ira_object_t obj, int num)
{
- int nw;
+ int nbytes;
int max = OBJECT_MAX (obj);
int min = OBJECT_MIN (obj);
@@ -638,9 +638,14 @@ ira_conflict_vector_profitable_p (ira_object_t obj, int
num)
in allocation. */
return false;
- nw = (max - min + IRA_INT_BITS) / IRA_INT_BITS;
- return (2 * sizeof (ira_object_t) * (num + 1)
- < 3 * nw * sizeof (IRA_INT_TYPE));
+ nbytes = (max - min) / 8 + 1;
+ STATIC_ASSERT (sizeof (ira_object_t) <= 8);
+ /* Don't use sizeof (ira_object_t), use constant 8. Size of ira_object_t (a
+ pointer) is different on 32-bit and 64-bit targets. Usage sizeof
+ (ira_object_t) can result in different code generation by GCC built as
32-
+ and 64-bit program. In any case the profitability is just an estimation
+ and border cases are rare. */
+ return (2 * 8 /* sizeof (ira_object_t) */ * (num + 1) < 3 * nbytes);
}
/* Allocates and initialize the conflict vector of OBJ for NUM
[Bug middle-end/98865] Missed transform of (a >> 63) * b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98865 --- Comment #5 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:8f571e64713cc72561f84241863496e473eae4c6 commit r12-3824-g8f571e64713cc72561f84241863496e473eae4c6 Author: Roger Sayle Date: Wed Sep 22 19:17:49 2021 +0100 More NEGATE_EXPR folding in match.pd As observed by Jakub in comment #2 of PR 98865, the expression -(a>>63) is optimized in GENERIC but not in GIMPLE. Investigating further it turns out that this is one of a few transformations performed by fold_negate_expr in fold-const.c that aren't yet performed by match.pd. This patch moves/duplicates them there, and should be relatively safe as these transformations are already performed by the compiler, but just in different passes. This revised patch adds a Boolean simplify argument to tree-ssa-sccvn.c's vn_nary_build_or_lookup_1 to control whether simplification should be performed before value numbering, updating the callers, but then avoiding simplification when constructing/value-numbering NEGATE_EXPR. This avoids the regression of gcc.dg/tree-ssa/ssa-free-88.c, and enables the new test case(s) to pass. 2021-09-22 Roger Sayle Richard Biener gcc/ChangeLog * match.pd (negation simplifications): Implement some negation folding transformations from fold-const.c's fold_negate_expr. * tree-ssa-sccvn.c (vn_nary_build_or_lookup_1): Add a SIMPLIFY argument, to control whether the op should be simplified prior to looking up/assigning a value number. (vn_nary_build_or_lookup): Update call to vn_nary_build_or_lookup_1. (vn_nary_simplify): Likewise. (visit_nary_op): Likewise, but when constructing a NEGATE_EXPR now call vn_nary_build_or_lookup_1 disabling simplification. gcc/testsuite/ChangeLog * gcc.dg/fold-negate-1.c: New test case.
[Bug fortran/102459] [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102459 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/102448] [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448 --- Comment #2 from Tamar Christina --- I have double checked the revision and it does start happening with it. Though I can only reproduce it with -flto. the codegen without lto seems the same. Any ideas how to debug further?
[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534 --- Comment #15 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:83aac698835edcdb3e6d96b856bef1c5f92e5e24 commit r12-3825-g83aac698835edcdb3e6d96b856bef1c5f92e5e24 Author: Tobias Burnus Date: Wed Sep 22 20:58:35 2021 +0200 Fortran: Improve -Wmissing-include-dirs warnings [PR55534] It turned out that enabling the -Wmissing-include-dirs for libcpp did output too many warnings â at least as run with -B and similar options during the GCC build and warning for internal include dirs like finclude, unlikely of relevance to for a real-world user. This patch now only warns for -I and -J by default but permits to get the full warnings including libcpp ones with -Wmissing-include-dirs. It additionally documents this in the manual. With that change, the -Wno-missing-include-dirs could be removed from libgfortran's configure and libgomp's testsuite always cflags. This reverts those bits of the previous commit r12-3722-g417ea5c02cef7f000e66d1af22b066c2c1cda047 Additionally, it turned out that all call to load_file called exit explicitly - except for the main file via gfc_init -> gfc_new_file. The latter also output a file not existing fatal error, such that two errors where printed. Now exit is called in line with the other users of load_file. Finally, when compileing with "nonexisting/file.f90", first a warning that "nonexisting" does not exist as include path was printed before the file not found error was printed. Now the directory in which the physical file is located is added silently, relying on the file-not-found diagnostic for those. PR fortran/55534 gcc/ChangeLog: * doc/invoke.texi (-Wno-missing-include-dirs.): Document Fortran behavior. gcc/fortran/ChangeLog: * cpp.c (gfc_cpp_register_include_paths, gfc_cpp_post_options): Add new bool verbose_missing_dir_warn argument. * cpp.h (gfc_cpp_post_options): Update prototype. * f95-lang.c (gfc_init): Remove duplicated file-not found diag. * gfortran.h (gfc_check_include_dirs): Takes bool verbose_missing_dir_warn arg. (gfc_new_file): Returns now void. * options.c (gfc_post_options): Update to warn for -I and -J, only, by default but for all when user requested. * scanner.c (gfc_do_check_include_dir): (gfc_do_check_include_dirs, gfc_check_include_dirs): Take bool verbose warn arg and update to avoid printing the same message twice or never. (load_file): Fix indent. (gfc_new_file): Return void and exit when load_file failed as all other load_file users do. libgfortran/ChangeLog: * configure.ac (AM_FCFLAGS): Revert r12-3722 by removing -Wno-missing-include-dirs. * configure: Regenerate. libgomp/ChangeLog: * testsuite/libgomp.fortran/fortran.exp (ALWAYS_CFLAGS): Revert r12-3722 by removing -Wno-missing-include-dirs. * testsuite/libgomp.oacc-fortran/fortran.exp (ALWAYS_CFLAGS): Likewise. gcc/testsuite/ChangeLog: * gfortran.dg/include_14.f90: Add -J testcase and update dg-output. * gfortran.dg/include_15.f90: Likewise. * gfortran.dg/include_16.f90: Likewise. * gfortran.dg/include_17.f90: Likewise. * gfortran.dg/include_18.f90: Likewise. * gfortran.dg/include_19.f90: Likewise.
[Bug target/89954] missed optimization for signed extension for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954 --- Comment #7 from Uroš Bizjak --- Created attachment 51496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51496&action=edit Prototype patch
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Last reconfirmed||2021-09-22 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from anlauf at gcc dot gnu.org --- I think the problem is we consider command_argument_count() as a pure function, so that gfc_is_constant_expr returns true. As a consequence, is_non_constant_shape_array thinks that 'a' has constant shape, thus erroneously allowing the initialization. We need a better concept of "constant"...
[Bug fortran/102456] ICE in gfc_check_rank, at fortran/check.c:4594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102456
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Priority|P3 |P4
Last reconfirmed||2021-09-22
--- Comment #1 from kargl at gcc dot gnu.org ---
The following diff stops the ICE, which is a null pointer dereference.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 851af1b30dc..2a250d73a28 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -4589,9 +4589,14 @@ gfc_check_rank (gfc_expr *a)
/* Functions returning pointers are regarded as variable, cf. F2008, R602.
*/
if (a->expr_type == EXPR_FUNCTION)
-is_variable = a->value.function.esym
- ? a->value.function.esym->result->attr.pointer
- : a->symtree->n.sym->result->attr.pointer;
+{
+ if (a->value.function.esym && a->value.function.esym->result)
+ is_variable = a->value.function.esym->result->attr.pointer;
+ else if (a->symtree->n.sym->result)
+ is_variable = a->symtree->n.sym->result->attr.pointer;
+ else
+ is_variable = false;
+}
if (a->expr_type == EXPR_OP
|| a->expr_type == EXPR_NULL
But, the patch yields
% gfcx -c -fcoarray=lib a.f90
a.f90:6:17:
6 |print *, rank(x[1])
| 1
Error: The argument of the RANK intrinsic at (1) must be a data object
and Gerhard indicates the code is legal. I don't use coarrays say cannot
confirm or deny this assertion. I do note that if one pokes around in
gdb that one finds
(gdb) p *a->value.function.actual->expr->symtree->n.sym->as
$11 = {rank = 0, corank = 1, type = AS_EXPLICIT, cotype = AS_EXPLICIT,
lower = {0x203627620, 0x0 }, upper = {
0x0 }, cray_pointee = false, cp_was_assumed = false,
resolved = true}
which is the only place I can locate rank and corank info. I'll also
note that we do have
(gdb) p a->rank
$13 = 0
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 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 anlauf from comment #2) > I think the problem is we consider command_argument_count() as a pure > function, > so that gfc_is_constant_expr returns true. Well, it is a pure function. Fortran 2018, page 327, All standard intrinsic functions are pure.
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #3) > Well, it is a pure function. Fortran 2018, page 327, > > All standard intrinsic functions are pure. Of course you are correct. I wanted to express that in this context one cannot interpret PURE == (compile time) constant.
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #3) > (In reply to anlauf from comment #2) > > I think the problem is we consider command_argument_count() as a pure > > function, > > so that gfc_is_constant_expr returns true. > > Well, it is a pure function. Fortran 2018, page 327, > > All standard intrinsic functions are pure. I think we need to look at the specific function in gfc_is_constant_expr. The Fortran standard has 10.1.12 Constant expression A constant expression is an expression with limitations that make it suitable for use as a kind type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, and each primary is ... (5) a reference to an elemental standard intrinsic function, where each argument is a constant expression, (6) a reference to a standard intrinsic function that is transformational, other than COMMAND_ARGUMENT_COUNT, GET_TEAM, NULL, NUM_IMAGES, TEAM_NUMBER, THIS_IMAGE, or TRANSFER, where each argument is a constant expression, So, if I untangle (6), gfortran needs to reject the listed intrinsic function except for TRANSFER where a different restrict applies.
[Bug rtl-optimization/7061] Access of bytes in struct parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7061 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #7 from Gabriel Ravier --- Compiling this under ia64 seems to now be optimized perfectly as of at least GCC 10, though the other ones look like they're still badly handled.
[Bug target/101543] extra zeroing of empty struct argument/return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #3 from Gabriel Ravier --- Seems to be fixed on trunk.
[Bug target/101543] extra zeroing of empty struct argument/return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543 --- Comment #4 from Gabriel Ravier --- Nevermind, didn't see this was an aarch64 bug
[Bug rtl-optimization/78778] non-atomic load moved to before atomic load with std::memory_order_acquire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78778 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Fixed by r8-2879 aka PR 57448 (and others).
[Bug rtl-optimization/78778] non-atomic load moved to before atomic load with std::memory_order_acquire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78778 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > Fixed by r8-2879 aka PR 57448 (and others). I should say fixed for GCC 8+.
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #6 from anlauf at gcc dot gnu.org --- Created attachment 51497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51497&action=edit Patch Thanks for the research, Steve. The attached patch fixes the PR by excluding the listed functions.
[Bug c++/80987] Existence of a std::initializer_list constructor breaks deduction guides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80987 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Target Milestone|--- |8.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Patrick Palka --- Fixed ever since r8-1965.
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #51497|0 |1 is obsolete|| --- Comment #7 from anlauf at gcc dot gnu.org --- Created attachment 51498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51498&action=edit Revised patch including testcase This regtests ok and has the right logic.
[Bug c/102461] New: overflow in omp parallel for schedule (static,chunk_size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102461
Bug ID: 102461
Summary: overflow in omp parallel for schedule
(static,chunk_size)
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: michelemartone at users dot sourceforge.net
Target Milestone: ---
Created attachment 51499
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51499&action=edit
`git diff` output of gcc/omp-expand.c against revision 7ca388565af aka tag:
releases/gcc-11.2.0
Hi,
I am the author of the LIBRSB library [http://librsb.sourceforge.net/] for
Sparse BLAS (sparse linear algebra_ computations.
I've received a bug report [https://savannah.gnu.org/bugs/?60042#comment4]
where an OpenMP-parallelized loop between i=0.. ended up
executing the loop body with i=-1.
The original loop in question had static scheduling and chunk_size=1, and
even one thread is sufficient to cause the problem.
I reduced the problem and can reproduce it with gcc-11.2.0 (built from sources,
GIT tag releases/gcc-11.2.0) and older ones; arch x86_64.
I could not reproduce the problem with clang-11.0.1 or icc-19.0.5.281.
// # gcc -Wall -Wextra -pedantic -fopenmp -std=c11 -O0 overflow.c
#include // abort
#include // INT_MAX
#include // compile with -fopenmp
int main ()
{
const int chunk_size = 1000;
const int n = INT_MAX - 100; // 2147483547
int l = 0;
#pragma omp parallel for schedule (static,chunk_size) num_threads (1)
for (int i = 0; i < n; ++i)
{
l = i;
if(i < 0)
abort ();
}
if ( l != n-1 )
abort ();
return 0;
}
I made some experiments in gcc/omp-expand.c and came up with a fix to insert
overflow detection code when computing the lower and upper boundaries of the
current chunk, thus avoiding the loop body from being executed with i=-1.
Invoking patched gcc like:
FIX1=1 FIX2=1 FIX3=1 gcc -fopenmp -Wall -pedantic -O0 overflow_mini.c -o
overflow -fdump-tree-all
and looking at the *.ompexp file it dumps, one can get an idea of what was
going wrong with the original flow.
Unfortunately I was not able to make my patch generate correct code for -O1 or
more.
I am attaching `git diff` output of gcc/omp-expand.c against revision
7ca388565af aka tag: releases/gcc-11.2.0 -- so one may use this as a base to
fix the bug fully.
I hope this information is enough for you GCC/OpenMP folks to fix this problem!
Michele
[Bug c/102461] overflow in omp parallel for schedule (static,chunk_size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102461 Michele Martone changed: What|Removed |Added CC||michelemartone at users dot source ||forge.net --- Comment #1 from Michele Martone --- Created attachment 51500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51500&action=edit a slightly longer reproducer listing I add a slightly longer reproducer listing.
[Bug c/102461] overflow in omp parallel for schedule (static,chunk_size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102461 --- Comment #2 from Michele Martone --- Created attachment 51501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51501&action=edit original *ompexp file with the OMP region tree I am attaching original *ompexp file with the OMP region tree.
[Bug c/102461] overflow in omp parallel for schedule (static,chunk_size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102461 --- Comment #3 from Michele Martone --- Created attachment 51502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51502&action=edit patched gcc *ompexp file with the OMP region tree. I am attaching patched gcc *ompexp file with the OMP region tree. Notice the negative values checks.
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #8 from Steve Kargl --- On Wed, Sep 22, 2021 at 09:17:18PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > Attachment #51497|0 |1 > is obsolete|| > > --- Comment #7 from anlauf at gcc dot gnu.org --- > Created attachment 51498 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51498&action=edit > Revised patch including testcase > I think TRANSFER needs to be handled differently. >From the same section of the Fortran standard, TRANSFER is rejected if the following does not apply. (8) a reference to the intrinsic function TRANSFER where each argument is a constant expression and each ultimate pointer component of the SOURCE argument is disassociated, So, one should be able to do something like integer,parameter :: n = 4 integer,parameter :: x(transfer(n, n)) = 1 print *, x end which gfortran will give % gfortran10 -o z a.f90 % ./z 1 1 1 1 If you remove TRANSFER from the patch, it looks good to me. We can revisit TRANSFER when Gerhard breaks gfortran, again! ;-)
[Bug middle-end/80270] ICE in extract_bit_field_1 at gcc/expmed.c:1798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80270 Andrew Pinski changed: What|Removed |Added Known to fail||4.8.1 --- Comment #4 from Andrew Pinski --- Interesting GCC 4.7's C front-end rejected this by: :20:22: error: data type of 'b' isn't suitable for a register But the C++ front-end rejected this due to not having vector[i] being implemented.
[Bug middle-end/80270] [9/10/11/12 Regression ICE in extract_bit_field_1 at gcc/expmed.c:1798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80270 Andrew Pinski changed: What|Removed |Added Summary|ICE in extract_bit_field_1 |[9/10/11/12 Regression ICE |at gcc/expmed.c:1798|in extract_bit_field_1 at ||gcc/expmed.c:1798 Target Milestone|--- |9.5 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80173 Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #5 from Andrew Pinski --- Related to PR 80173. The difference between that bug and this one is simple: b.s2f1.s1f[i]; vs b.s2f1.s1f[3];
[Bug fortran/101334] gfortran fails to enforce C838 on disallowed uses of assumed-rank variable names + bogus errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101334 --- Comment #1 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:7a40f2e74815a926c5f47416c29efbc17aa1ef43 commit r12-3827-g7a40f2e74815a926c5f47416c29efbc17aa1ef43 Author: Sandra Loosemore Date: Sun Sep 19 17:32:03 2021 -0700 Fortran: Fixes for F2018 C838 (PR fortran/101334) The compiler was failing to diagnose the error required by F2018 C838 when passing an assumed-rank array argument to a non-assumed-rank dummy. It was also incorrectly giving an error for calls to the 2-argument form of the ASSOCIATED intrinsic, which is supposed to be permitted by C838. 2021-09-19 Sandra Loosemore PR fortran/101334 gcc/fortran/ * check.c (gfc_check_associated): Allow an assumed-rank array for the pointer argument. * interface.c (compare_parameter): Also give rank mismatch error on assumed-rank array. gcc/testsuite/ * gfortran.dg/c-interop/c535b-2.f90: Remove xfails. * gfortran.dg/c-interop/c535b-3.f90: Likewise.
