[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904 --- Comment #6 from sandra at gcc dot gnu.org --- On further investigation, it appears that both the C and C++ front ends are at least attempting to parse the context selectors in the correct scope, although C++ trips over a "use of parameter outside function body" error. If that's fixed, a code walk would find these things easily enough. I guess we'd only want to do the function wrapper around the expression if it actually references parameters? Certainly not for constants, at least. I'd need help figuring out what to do for Fortran as I'm less familiar both with the language semantics and the front end implementation. I guess there are additional complications due to supporting nested functions/modules.
[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904 --- Comment #5 from sandra at gcc dot gnu.org --- Per TR12, these are the rules for the scoping/evaluation of these expressions: "For the match clause of a declare variant directive, any argument of the base function that is referenced in an expression that appears in the context selector is treated as a reference to the expression that is passed into that argument at the call to the base function. Otherwise, a variable or procedure reference in an expression that appears in a context selector is a reference to the variable or procedure of that name that is visible at the location of the directive on which the context selector appears." C: "Any expressions in the match clause are interpreted as if they appeared in the scope of arguments of the base function." C++: "any expressions in the match clause are interpreted as if they appeared at the scope of the trailing return type of the base function." Plus, confusingly, it also says: "All variables referenced by these expressions are considered to be referenced at the call site." "All variables that are referenced in an expression that appears in the context selector of a match clause must be accessible at each call site to the base function according to the base language rules." So maybe the intent is that the variables be parsed in the scope of the directive but then the expressions be inserted inline at the call site, rather than wrapping them with an internal function? :-S
[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596 --- Comment #7 from sandra at gcc dot gnu.org --- OK, I will do no more work on the old implementation, adjust the broken testcases, and proceed with getting the my new implementation ready for stage 1 submission. I don't know if I'll be able to easily disentangle the bug fixes from the new functionality, though everything is kind of mixed up together with changes in representation and interfaces to get metadirectives and "declare variant" using the same functions to score and sort the candidate variants. (My previously-posted set of metadirective patches also had a scoring bug that I'm addressing with this set of changes.)
[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596 --- Comment #5 from sandra at gcc dot gnu.org --- Tobias, it looks to me like you missed the connection between the first half of item (1) in 7.3 (I'm still looking at the 5.2 spec): "Each trait selector for which the corresponding trait appears in the construct trait set in the OpenMP context is given the value 2**(p−1) where p is the position of the corresponding trait, cp, in the context construct trait set..." And this part of section 7.1: "Specifically, the ordering of the set of constructs is c1 , ... , cN , where c1 is the construct at the outermost nesting level and cN is the construct at the innermost nesting level." So, the outermost construct has the *lowest* position and *lowest* score. In this case, the "teams" construct is outermost, has p=1, and contributes 2**0 to the score. And to get the highest score for the duplicated construct traits, it should prefer the innermost ones. Re the adding one to the final score, that is also explicit in the spec, item 6 at the very end of section 7.3.
[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596 --- Comment #1 from sandra at gcc dot gnu.org --- Created attachment 57883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57883=edit patch to add instrumentation as diagnostic aid
[Bug middle-end/114596] New: [OpenMP] "declare variant" scoring seems incorrect for construct selectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
Bug ID: 114596
Summary: [OpenMP] "declare variant" scoring seems incorrect for
construct selectors
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
Created attachment 57882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57882=edit
reduced test case
Background: I've been working on integrating the dynamic selector support added
for "metadirective" (patches previously submitted but not yet approved) with
the existing support for "declare variant", rewriting a bunch of code so that
they both share the same representations and functions for matching, scoring,
and sorting. Those patches aren't yet ready to submit and are stage 1
material, but in comparing differences in test results between my new
implementation and the previous behavior, it looks to me like the scoring for
construct selectors in "declare variant" is pretty borked on mainline.
The attached testcase is a reduced version of
c-c++-common/gomp/declare-variant-12.c. The "16+8+4" comment on f14 agrees
with what the code is doing, but it seems incorrect according to the spec. By
my reading, the OpenMP context at the point of call to f17 is {teams, parallel,
for, parallel, for} with associated scores {1, 2, 4, 8, 16}, per sections 7.1
and 7.3 of the 5.2 spec, respectively. My understanding of the latter part of
item (1) in 7.3
"if the traits that correspond to the construct selector set appear multiple
times in the OpenMP context, the highest valued subset of context traits that
contains all selectors in the same order are used"
is that the matching selectors don't have to appear contiguously, so the score
would be 1+8+16. In discussion with Tobias, he thinks there is still some
ambiguity about which of the duplicates is preferred for the match, though.
I added some instrumentation to the code to try to figure out how it was coming
up with "16+8+4"; the patch is attached, and produced output
$ install/bin/x86_64-linux-gnu-gcc declare-variant-12.c -fopenmp
-foffload=disable -S
codes[0] = omp_for
codes[1] = omp_parallel
codes[2] = omp_for
codes[3] = omp_parallel
codes[4] = omp_teams
constructs[0] = omp_for
constructs[1] = omp_parallel
constructs[2] = omp_teams
omp_teams, i = 2, j = 4, position = 4
omp_parallel, i = 1, j = 3, position = 3
omp_for, i = 0, j = 2, position = 2
constructs[0] = omp_for, scores[0] = 4, score = 16
constructs[1] = omp_parallel, scores[1] = 3, score = 8
constructs[2] = omp_teams, scores[2] = 2, score = 4
For selector construct = {teams, parallel, for}
score1 = 29 score2 = 29
The "codes" array is the OpenMP context, "constructs" are the traits in the
construct selector, and the "scores" array does not contain scores, but rather
the positions of the elements of the "constructs" array in the "codes" array.
I believe there are at least three bugs here:
(1) The constructs array is being processed backwards from n-1 to 0, but the
scores array is indexed from 0 to n-1, and later it's assumed both arrays are
in the same order.
(2) The codes array is backwards and so are the position values, and there's no
adjustment to subtract the position from the length of the "codes" array in
computing the corresponding score.
(3) It's choosing the wrong subset from the duplicate traits, preferring the
should-be-lower-valued outer ones over the higher-valued inner ones.
I don't know if anybody wants to tackle a bug fix for this code for GCC 14. As
I've said, I've got a complete rewrite I'm planning to submit early in stage 1,
which I hope will be an improvement from an engineering perspective in terms of
readability/maintainability, with cleaner and better-documented interfaces and
references to the spec to explain what it is doing.
[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904 --- Comment #4 from sandra at gcc dot gnu.org --- Dynamic selectors are completely broken on mainline, since the patches that at least partially implements this feature for metadirectives has not been approved or committed yet. I'm also very much aware that there is not even a proposed patch to make this work for "declare variant" yet, although the metadirectives work provides the underlying primitives that ought to be adaptable for "declare variant" as well. I suggest not messing around with incremental fixes meanwhile that would step on the already-posted patches which cannot be considered until GCC 14 has branched. https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642005.html
[Bug libstdc++/79193] libstdc++ configure incorrectly decides linking works for cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from sandra at gcc dot gnu.org --- I think I just forgot to close this issue at the time I committed the patch. Ooops!
[Bug c++/90463] Documentation: -Wunused not listed among the options enabled by -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90463 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from sandra at gcc dot gnu.org --- Marking this fixed now.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 90463, which changed state. Bug 90463 Summary: Documentation: -Wunused not listed among the options enabled by -Wall https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90463 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/90463] Documentation: -Wunused not listed among the options enabled by -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90463 --- Comment #2 from sandra at gcc dot gnu.org --- A quick look through the lists of -Wall and -Wextra options turned up some others that are missing, too. I'm trying to do a more thorough patch.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 90464, which changed state. Bug 90464 Summary: Documentation: incorrect description of -Wunused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90464 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/90464] Documentation: incorrect description of -Wunused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90464 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- Fixed.
[Bug c/109708] [c, doc] wdangling-pointer example broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109708 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from sandra at gcc dot gnu.org --- Fixed.
[Bug c/109708] [c, doc] wdangling-pointer example broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109708 --- Comment #2 from sandra at gcc dot gnu.org --- I was wondering if some subsequent patch might have caused the first example to regress rather than this being a documentation bug, but it did not give a diagnostic at the time the -Wdangling-pointer support was committed, either. I'll fiddle with the example a bit to make it better illustrate the difference between level 1 and level 2, as well as making it work.
[Bug c/102998] Wrong documentation for -Warray-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from sandra at gcc dot gnu.org --- Fixed.
[Bug c/102998] Wrong documentation for -Warray-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998 --- Comment #4 from sandra at gcc dot gnu.org --- Hmmm, I ran into PR113515 with this example.
[Bug c/113515] New: Wrong documentation for -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113515
Bug ID: 113515
Summary: Wrong documentation for -Wstringop-overflow
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
This is essentially the example for -Warray-parameter=1 in the manual (see
PR102998):
#include
void f (int[static 4]);
void f (int[]); // warning 1
void g (void)
{
int *p = (int *) malloc (1 * sizeof(int));
f (p); // warning 2
}
Warning 2 is:
example.c: In function 'g':
example.c:9:3: warning: 'f' accessing 16 bytes in a region of size 4
[-Wstringop-overflow=]
9 | f (p);
| ^
example.c:9:3: note: referencing argument 1 of type 'int[4]'
example.c:4:6: note: in a call to function 'f'
4 | void f (int[]);
| ^
It's correct to warn here, but the manual is not helpful in explaining what
-Wstringop-overflow has to do with it.
The documentation for -Wstringop-overflow says:
Warn for calls to string manipulation functions such as @code{memcpy} and
@code{strcpy} that are determined to overflow the destination buffer.
There are no string manipulation functions in this example. I presume
additional kinds of object-size checking, beyond calls to string/byte array
manipulation functions from the standard library, were overloaded onto this
option without updating its description. Can we get a better summary of what
it does now?
[Bug c/102998] Wrong documentation for -Warray-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #3 from sandra at gcc dot gnu.org --- The argument to malloc is 4, but it's given in bytes, not array elements. I can tweak this example to make it more clear that the array is too small. There are other problems here too; -Warray-parameter isn't listed in the Options Summary section, it doesn't say what N defaults to if you omit it, or that the negative form is equivalent to -Warray-parameter=0.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 104355, which changed state. Bug 104355 Summary: Misleading -Warray-bounds documentation says "always out of bounds" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/104355] Misleading -Warray-bounds documentation says "always out of bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED CC||sandra at gcc dot gnu.org --- Comment #6 from sandra at gcc dot gnu.org --- Looks like this was fixed by Martin's commit 2 years ago, closing now.
[Bug c++/102397] Documentation of attribute syntax does not discuss C++11 / C23 attribute syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #1 from sandra at gcc dot gnu.org --- I committed a patch a few months ago to say that the new C++/C standard attribute syntax is supported with a gnu:: prefix, so at least the originally-reported problem has already been fixed. However, all the examples still use the old syntax. Given that there is an awful lot of legacy code using the old syntax already out there, examples are useful in helping people grok what it means, but at some point we probably want to encourage people to use the new syntax in new code for all the usual reasons why it's better to do things in a standard way, and use it also as the primary form for documentation. OTOH, I don't think we're quite there yet. Presently the manual describes C23 support as "experimental and incomplete" and says the default C language dialect is -std=gnu17. My sense is that it's not appropriate to tell users to make the switch until GCC's default dialect is advanced to something based on C23. So I'm going to leave this issue open for now instead of closing it as fixed, as a reminder that there is still more work to be done here a little farther down the road.
[Bug c/110029] more precise documentation for cleanup attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110029 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from sandra at gcc dot gnu.org --- Fixed.
[Bug ipa/108470] Missing documentation for alternate uses of __attribute__((noinline))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from sandra at gcc dot gnu.org --- Fixed.
[Bug other/111287] doc: "strict ISO mode" definition is not up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I think the problem here goes beyond this one line of documentation. E.g, there's a reference to "strict ISO C90 mode" later in the same paragraph that probably ought to refer to any later C standard as well, and it's not clear whether "Outside strict ISO C mode" means that these builtins are always available in C++. (IOW, does strict ISO C mode disable things that are otherwise normally supported by C-family dialects, or do non-strict ISO C mode enable things that are normally are *not* supported?) Re __STRICT_ANSI__, invoke.texi only says that is defined when -ansi is used, so either defining it for all those later standards is wrong or the documentation is wrong (and it needs to be moved out of the description of the -ansi option). I think we at least need a formal definition in the manual of what "strict ISO mode" means, for both C and C++, and to implement/document additional #defines for different dialects. It's probably too late to fix __STRICT_ANSI__, though. In any case, I think the standards compliance section, the -std= options documentation, and the builtins section all need to be made consistent.
[Bug target/108521] gcc/doc/invoke.texi contains remnants of Cygwin options removed in 2010-10-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108521 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from sandra at gcc dot gnu.org --- I've pushed Brian's patch, so now fixed.
[Bug c/26154] [11/12/13/14 Regression] OpenMP extensions to the C language is not documented or doumented in the wrong spot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154 sandra at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||sandra at gcc dot gnu.org --- Comment #35 from sandra at gcc dot gnu.org --- This issue has been open for 18 years, and I hope the OpenMP documentation has improved at least a little since support was added in GCC 4.2. :-S Is there anything that needs to be done beyond adding a blurb in the pragmas section saying that GCC accepts standard OpenMP pragmas when compiling with -fopenmp, and pointing people at the libgomp manual for current implementation status of the various features?
[Bug c/107942] [11/12/13/14 Regression] Documentation of the volatile style for noreturn is gone and const style for const attribute is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107942 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from sandra at gcc dot gnu.org --- Fixed.
[Bug middle-end/110847] [13/14 Regression] Inaccurate GCC documentation about -Wtsan and -Wxor-used-as-pow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110847 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from sandra at gcc dot gnu.org --- Fixed.
[Bug middle-end/111659] document that -Wstrict-flex-arrays depends on -ftree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111659 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from sandra at gcc dot gnu.org --- Fixed.
[Bug c/111693] -Wuse-after-free is documented in the wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from sandra at gcc dot gnu.org --- Fixed.
[Bug target/112973] Documentation for __builtin_preserve_access_index is not wrapped in extend.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112973 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- Fixed, along with some other too-long lines and copy-editing problems in the same section.
[Bug tree-optimization/112468] [14 Regression] Missed phi-opt after recent change (phi-opt-24.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112468 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #12 from sandra at gcc dot gnu.org --- Add nios2 to the list of targets where this change triggered a bunch of test fails.
[Bug tree-optimization/110279] [14 Regression] Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #6 from sandra at gcc dot gnu.org --- Both testcases are failing on nios2-elf.
[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from sandra at gcc dot gnu.org --- Should be fixed now.
[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274 --- Comment #12 from sandra at gcc dot gnu.org --- Improved and tested patch posted here: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629616.html IIUC the temporaries introduced in non-full-expressions are bound in a block that encloses the entire full-expression. The restructuring that moves intervening code into the loop body operates on whole statements, not subexpressions, so I convinced myself there should be nothing to do here.
[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274 --- Comment #11 from sandra at gcc dot gnu.org --- OK, I've been digging around in the code. do_poplevel() only fills in BIND_EXPR_BLOCK if stmts_are_full_exprs_p() is true. I haven't figured out the control flow that affects the latter predicate or how the vars in a BIND_EXPR end up associated with some other block, but I understand what a full-expression is in C++, so I think I can go off and come up with some test cases to exercise that and figure out what the right thing to do with the tree coming in to this restructuring is.
[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274 --- Comment #9 from sandra at gcc dot gnu.org --- The problem is that it's tripping over a BIND_EXPR with a null BIND_EXPR_BLOCK. The attached patch stops the testcase from ICE'ing but hasn't been otherwise tested yet. I'm not sure what a null BIND_EXPR_BLOCK actually means, or if it might be a bug elsewhere that such a thing is being created? The comments on BIND_EXPR in tree.def seem to imply that there is always an associated block. If it's permissible, maybe the fix ought to pass through the superblock pointer in the recursive call instead of the null block pointer.
[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274 --- Comment #8 from sandra at gcc dot gnu.org --- Created attachment 55832 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55832=edit first attempt at fix
[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274 sandra at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-09-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||sandra at gcc dot gnu.org --- Comment #7 from sandra at gcc dot gnu.org --- I'll take a peek. Thanks for the reduced testcase!
[Bug fortran/109467] New: inconsistent formatting/case of keywords in error messages in Fortran front end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109467 Bug ID: 109467 Summary: inconsistent formatting/case of keywords in error messages in Fortran front end Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- I've noted that calls to gfc_error in the Fortran front end use a mix of conventions for language keywords. Some messages use "%", others "KEYWORD", and then there are things like "% REDUCTION clause" in the same message. :-( The GCC internals manual is clear that %< markup should be used on all keywords, but is upper or lower case preferred? Almost all places that currently use %< markup use lower case. The Fortran standard uses upper case for keywords and intrinsics, as does the GNU Fortran manual, while the OpenMP spec seems to use lower case for its own keywords and upper case for regular Fortran keywords. There are also a couple messages in trans-openmp.cc that use literal quotes around lower-case keywords. Anyway, rather than trying to patch these things piecemeal, it's probably best just to make a pass through the sources to implement whatever convention we decide on, and similarly patch up all testcases that scan for these error messages.
[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94920 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #10 from sandra at gcc dot gnu.org --- The ABS_EXPR test is also failing on nios2.
[Bug c++/108399] New: wrong locations generated for OMP_FOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108399 Bug ID: 108399 Summary: wrong locations generated for OMP_FOR Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- Created attachment 54268 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54268=edit WIP patch While working on some other changes to the "omp for" directive, I noticed that the locations for errors generated by the C++ front end are inconsistent with those from the C front end, and not uniform internally within the C++ front end either. Specifically, the C front end tags the OMP_FOR with the location of the directive while the C++ front end tags it with the location of its outermost nested "for" loop... but in some cases errors end up being diagnosed on the line of the directive anyway (see f5 in g++.dg/gomp/loop-8.C, for instance). I came up with the attached patch to address this, and fix an obvious think-o in pt.cc too. This caused a bunch of regressions in existing test cases: c-c++-common/gomp/loop-10.c c-c++-common/gomp/loop-6.c c-c++-common/gomp/order-4.c g++.dg/gomp/for-11.C g++.dg/gomp/for-16.C g++.dg/gomp/for-1.C g++.dg/gomp/linear-2.C g++.dg/gomp/loop-1.C g++.dg/gomp/loop-2.C g++.dg/gomp/loop-3.C g++.dg/gomp/loop-4.C g++.dg/gomp/loop-5.C g++.dg/gomp/loop-6.C g++.dg/gomp/loop-8.C g++.dg/gomp/pr25996.C g++.dg/gomp/pr27415.C g++.dg/gomp/pr35078.C g++.dg/gomp/pr37533.C g++.dg/gomp/pr39495-2.C g++.dg/gomp/pr58567.C g++.dg/gomp/pr67511.C g++.dg/gomp/pr67523.C g++.dg/gomp/pr84448.C g++.dg/gomp/simd-2.C The first 3 just need to have the C/C++ conditionalization removed, but in looking at g++.dg/gomp/for-11.C I realized there is a further bug with invalid subexpressions of the nested loops not being tagged with correct location information either by the C++ front end. It looks like the C parser seems to be taking more care about this: default: /* Can't be cond = error_mark_node, because we want to preserve the location until c_finish_omp_for. */ cond = build1 (NOP_EXPR, boolean_type_node, error_mark_node); while the C++ front end is just returning bare error_mark_node. I think it is a reasonable expectation that the C and C++ front ends behave identically in diagnosing errors for things that have the same semantics in both languages. Aside from fixing the bugs, probably most of the C error tests for "omp for" should be moved to c-c++-common so that we can enforce this. Anyway, this is looking like a can of worms and lower priority than the thing I was working on when I ran into this, so I'm dumping state in this issue for now. If anybody else wants to pick it up meanwhile, feel free.
[Bug libfortran/108056] [12/13 Regression] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 --- Comment #7 from sandra at gcc dot gnu.org --- I've swapped out just about all the details on this work after more than a year, but we shouldn't be trying to create a CFI descriptor with BT_ASSUMED at all, should we? If the compiler is generating a CFI descriptor for an assumed-type argument it's supposed to use the actual type of the argument passed, not BT_ASSUMED, right? If gcc 11 had a bug that caused it to do that incorrectly, is it necessary to retain ABI compatibility by continuing to reproduce the bug in newer versions of libgfortran? Maybe we should just remove the functions that are allegedly there for compatibility so that users will get a link error instead?
[Bug middle-end/106548] New: ICE in #pragma openmp parallel for simd linear with long long variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106548
Bug ID: 106548
Summary: ICE in #pragma openmp parallel for simd linear with
long long variables
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
Test case is reduced from libgomp.c/linear-1.c, with "simd" added to the loop:
int a[256];
__attribute__((noinline, noclone)) long long int
f3 (long long int i, long long int k)
{
#pragma omp parallel for simd linear (i: k)
for (short j = 16; j < 64; j++)
{
a[i] = j;
i += 4;
}
return i;
}
$ x86_64-linux-gnu-gcc -S -fopenmp linear-1.c
during RTL pass: expand
linear-1.c: In function 'f3._omp_fn.0':
linear-1.c:6:11: internal compiler error: in expand_expr_real_1, at
expr.cc:10721
6 | #pragma omp parallel for simd linear (i: k)
| ^~~
0x748517 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/path/to/gcc/expr.cc:10721
0xba694c expand_expr
/path/to/gcc/expr.h:310
0xba694c expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/path/to/gcc/expr.cc:8403
0xb9eedb expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/path/to/gcc/expr.cc:9631
0xa7a3c8 expand_gimple_stmt_1
/path/to/gcc/cfgexpand.cc:3983
0xa7a3c8 expand_gimple_stmt
/path/to/gcc/cfgexpand.cc:4044
0xa8013e expand_gimple_basic_block
/path/to/gcc/cfgexpand.cc:6096
0xa81c66 execute
/path/to/cfgexpand.cc:6822
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Declaring either i or k as plain "int" instead of "long long int" makes the
crash go away.
[Bug middle-end/106492] New: ICE in #pragma omp for simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106492
Bug ID: 106492
Summary: ICE in #pragma omp for simd
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
This is similar to PR106449; adding the simd keyword to an existing omp for
test case causes an ICE related to incompatible types.
Test case is derived from g++.dg/gomp/pr95063.C:
// PR c++/95063
template
struct S {
T a : 12;
S () : a(0)
{
#pragma omp for simd linear(a)
for (int k = 0; k < 64; ++k)
a++;
}
};
struct U {
int a : 12;
U () : a(0)
{
#pragma omp for simd linear(a)
for (int k = 0; k < 64; ++k)
a++;
}
};
S s;
U u;
$ x86_64-none-linux-gnu-g++ -fopenmp pr95063.C -S
pr95063.C: In constructor 'U::U()':
pr95063.C:19:8: error: type mismatch in binary expression
19 | a++;
| ~^~
int
a = a + D.2648;
during GIMPLE pass: omplower
pr95063.C:19:8: internal compiler error: 'verify_gimple' failed
0x1295c9d verify_gimple_in_seq(gimple*)
/path/to/gcc/tree-cfg.cc:5220
0x1167b60 execute_function_todo
/path/to/gcc/passes.cc:2093
0x1167fdb execute_todo
/path/to/gcc/passes.cc:2145
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug middle-end/106449] New: ICE in #pragma omp parallel for simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449
Bug ID: 106449
Summary: ICE in #pragma omp parallel for simd
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
Test case is derived from c-c++-common/gomp/loop-8.c, with "simd" added:
void
foo (void)
{
int a[1024];
int *p, *q;
#pragma omp parallel for simd collapse(2)
for (p = [0]; p < [512]; p++)
for (q = p + 64; q < p + 128; q++)
;
}
$ x86_64-none-linux-gnu-gcc -fopenmp loop-8.c
during GIMPLE pass: ompexp
loop-8.c: In function 'foo':
loop-8.c:6:11: internal compiler error: in build2, at tree.cc:5023
6 | #pragma omp parallel for simd collapse(2)
| ^~~
0x19e4116 build2(tree_code, tree_node*, tree_node*, tree_node*)
/path/to/gcc/tree.cc:5022
0xf81b3f build2_loc
/path/to/gcc/tree.h:4577
0xfc0d03 fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/path/to/gcc/fold-const.cc:13860
0xfb26f3 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/path/to/gcc/fold-const.cc:10894
0xfc0cdc fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/path/to/gcc/fold-const.cc:13858
0x380f1ca expand_omp_simd
/path/to/gcc/omp-expand.cc:6882
0x3815c41 expand_omp_for
/path/to/gcc/omp-expand.cc:8090
0x381e79d expand_omp
/path/to/gcc/omp-expand.cc:10357
0x381e717 expand_omp
/path/to/gcc/omp-expand.cc:10343
0x381e717 expand_omp
/path/to/gcc/omp-expand.cc:10343
0x381edbb execute_expand_omp
/path/to/gcc/omp-expand.cc:10592
0x381ee95 execute
/path/to/gcc/omp-expand.cc:10639
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 sandra at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from sandra at gcc dot gnu.org --- Marking this as fixed.
[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from sandra at gcc dot gnu.org --- Should be fixed now.
[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695 --- Comment #6 from sandra at gcc dot gnu.org --- *** Bug 102621 has been marked as a duplicate of this bug. ***
[Bug fortran/102621] ICE in convert_nonlocal_reference_op, at tree-nested.c:1166 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102621 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org --- Comment #3 from sandra at gcc dot gnu.org --- This is the same problem as PR103695, or at least it's fixed by the same patch. *** This bug has been marked as a duplicate of bug 103695 ***
[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695 sandra at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- Patch posted here: https://gcc.gnu.org/pipermail/fortran/2022-January/057425.html
[Bug fortran/104100] Passing an allocated array to a C bind function alters the bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104100 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- Most of the patches are on the devel/omp/gcc-11 development branch that also includes a bunch of other experimental features and preliminary patches that haven't made it to mainline yet, but I don't think either Tobias or I have a todo item to backport the bind(c) patches to the stable gcc 11 branch. There were a lot of patches and some of them were quite extensive rewrites, so my sense is that it's probably not appropriate for a stable branch.
[Bug middle-end/103163] [12 Regression] stack_limit_rtx is created too early causing nregs field on REG to be zero (gcc.target/nios2/nios2-stack-check-1.c and gcc.target/powerpc/stack-limit.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from sandra at gcc dot gnu.org --- Should be fixed now.
[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695 --- Comment #4 from sandra at gcc dot gnu.org --- Ooops, I meant AFFINITY clause in the message above, not ASSOCIATED.
[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695
--- Comment #3 from sandra at gcc dot gnu.org ---
It appears that the wrong-scope problem is introduced in gfc_finish_var_decl,
in this block of code:
/* Chain this decl to the pending declarations. Don't do pushdecl()
because this would add them to the current scope rather than the
function scope. */
if (current_function_decl != NULL_TREE)
{
if (sym->ns->proc_name
&& (sym->ns->proc_name->backend_decl == current_function_decl
|| sym->result == sym))
gfc_add_decl_to_function (decl);
else if (sym->ns->proc_name
&& sym->ns->proc_name->attr.flavor == FL_LABEL)
/* This is a BLOCK construct. */
add_decl_as_local (decl);
else
gfc_add_decl_to_parent_function (decl);
}
ns->proc_name contains something completely unexpected here so it's falling
through to gfc_add_decl_to_parent_function. I think it's an accident that it
works at all when it's not inside a nested function. Do we really want these
iterator variables to have local scope instead?
gfortran.h documents the proc_name field as
/* If this is a namespace of a procedure, this points to the procedure. */
struct gfc_symbol *proc_name;
but the ASSOCIATED clause seems to be using it for an entirely different
purpose, to chain the list of iterator variables (see handle_iterator in
trans-openmp.c). I think that's the real bug, rather than the code snippet
quoted above. It ought to be adding a new field to struct gfc_namespace if
there isn't a better place to store this information, instead of overloading
one that means something else.
I'm still trying to find my way around the code that manipulates these
namespaces and iterator variables. There's an annoying lack of comments here
to explain the data structures it is using or what parts are handled during
gimplification. :-(
[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I'm not at all familiar with any of this code (yet), but... Note that it is complaining about variable i declared in the outer procedure p, not about something in the nested function s that contains the OMP directives. Looking at the .original dump, I see that the declaration for the iterator variable j is appearing in the outer procedure p, not the inner function s where it is used in the OMP task directive. The .gimple dump shows both i *and* j declared in both procedures, and the .nested dump shows that a bunch of static chain stuff has been added for j. So my guess is that these variables being inserted into wrong scopes is confusing the ssa passes.
[Bug fortran/103898] [12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from sandra at gcc dot gnu.org --- Fixed.
[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from sandra at gcc dot gnu.org --- Should be fixed now.
[Bug fortran/103898] [12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898 --- Comment #8 from sandra at gcc dot gnu.org --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2022-January/057293.html
[Bug fortran/103898] [12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898 sandra at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #7 from sandra at gcc dot gnu.org --- Yeah, the implementation of the SIZE intrinsic is pretty borked. I'm working on it.
[Bug fortran/102708] Improve ''array temporary was created for argument" diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102708 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I fixed a lot of bugs with creating excessive temporaries for calls to bind(c) functions in my fix for PR 103390 (commit 6447f6f983ffeaecb8753ef685d702bf2594968b). I'm not sure if there is more to do there or not, but it seems unrelated to the original problem. If there's a bug, it ought to be in its own issue. IIUC what needs to be done for the original problem is fixing (all?) the calls to gfc_conv_subref_array_arg to pass the fsym and proc_name arguments.
[Bug fortran/103366] [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103366 --- Comment #7 from sandra at gcc dot gnu.org --- The proposed patch looks reasonable to me.
[Bug fortran/95879] [10/11/12 Regression] ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95879 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- The ICE from the z1.90 example is gone on mainline now. I don't know if the error on y1.f90 is correct or not without further research.
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from sandra at gcc dot gnu.org --- Should be fixed now.
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from sandra at gcc dot gnu.org --- Marking this as fixed since we have a new issue for the other bug.
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #5 from sandra at gcc dot gnu.org --- The previous hacky patch had some testsuite regressions. I've posted a less hacky one that doesn't trigger new failures here: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587632.html
[Bug fortran/103898] [12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898 --- Comment #4 from sandra at gcc dot gnu.org --- This is probably related to my rewrite of the size/shape/ubound/lbound intrinsics back in mid-November. I can add this one to my queue, but I've already got 3 or 4 other issues already waiting for me to do something, so if anybody else wants to take this one meanwhile go ahead.
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 --- Comment #9 from sandra at gcc dot gnu.org --- Without a test case, I can't tell if the error in comment 7 was due to this bug or a different one. It doesn't really look the same as the other failures I looked at in this issue, as the source code it's pointing at does not involve a call to a BIND(C) procedure. I've pushed the patch now; Antony, can you retry your build, and work up a test case for a new issue if it still fails in the same way?
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 --- Comment #6 from sandra at gcc dot gnu.org --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2022-January/057249.html
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 --- Comment #5 from sandra at gcc dot gnu.org --- Created attachment 52107 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52107=edit -fdump-tree-original output from second test case Well, this is nuts. Unmodified code is generating 3 copies of the loop to compute "a + b" in the previous example, as well as the invalid copy-out code. I've got a patch to fix this now, just doing a few more experiments with it.
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 --- Comment #4 from sandra at gcc dot gnu.org --- I thought I had a fix for this that involved making gfc_is_simply_contiguous smarter about intrinsics and other function calls, but after writing more test cases I found that this one still ICEs. program p integer, pointer :: z(:) integer :: a(3) = [1, 2, 3]; integer :: b(3) = [4, 5, 6]; call s(a + b); contains subroutine s(x) bind(c) integer, contiguous :: x(:) end end Tobias's other suggestion to me was gating the copy-out code with gfc_expr_is_variable() so I'll try that next.
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 --- Comment #3 from sandra at gcc dot gnu.org --- Created attachment 51994 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51994=edit -fdump-tree-original output from test case Here's the full output from -fdump-tree-original for the test case.
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 sandra at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- It looks to me like this is due to a collision between my patch to re-do the SHAPE intrinsic (commit 1af78e731feb9327a17c99ebaa19a4cca1125caf) and Tobias's big patch to completely reimplement CFI descriptor conversion (commit 64f9623765da3306b0ab6a47997dc5d62c2ea261) and the copy-in/copy-out for array parameters with the CONTIGUOUS attribute. I think the thing the gimplifier is crashing on is this assignment that appears in the copy-out loop after the call to s: (integer(kind=4)) (((unsigned int) z.dim[S.3].ubound - (unsigned int) z.dim[S.3].lbound) + 1) = (*(integer(kind=4)[1] * restrict) atmp.0.data)[S.3 + D.4263]; The left-hand side of the assignment is not an lvalue because of the nop_expr. Besides fixing the bug, it would be good if we could make it smart enough not to generate the copy-in/copy-out loops at all because it knows perfectly well that the temporary holding the result of the SHAPE intrinsic is already contiguous!
[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- The proposed fix in comment 2 looks OK to me, although I'd like to see a comment here like "This case corresponds to an assumed-rank actual passed to a function without an explicit interface, which is diagnosed in gfc_procedure_use." to explain what is going on.
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #4 from sandra at gcc dot gnu.org --- Created attachment 51980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51980=edit hacky patch Attached patch has not been regression tested, but it does seem to fix the original testcase, which now produces: $ gfortran -c pr103258.f90 pr103258.f90:3:13: 3 | character(n+m) :: c | 1 Error: Symbol 'm' at (1) has no IMPLICIT type pr103258.f90:1:14: 1 | subroutine s(n) | 1 Error: Symbol 'n' at (1) has no IMPLICIT type
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #3 from sandra at gcc dot gnu.org --- This looks like an existing bug in error checking that was exposed by my patch to do... more error checking. :-S The problem is that gfc_set_default_type in symbol.c is setting sym->attr.untyped even when errors are suppressed or buffered and discarded during parsing. Since it's marked as having already been diagnosed, we aren't giving an error in subsequent calls where errors are *not* being suppressed or discarded, and thus compilation continues as if nothing were wrong, until it falls over. Previously we were resolving only the second operand "m" in the "(n+m)" expression in a situation where errors are buffered in the parsing stage, leaving "n" without the attr.untyped flag set so that it was being diagnosed later during the actual resolve phase of processing. Now it is setting that flag on both "n" and "m" so neither ever gives a real error. I've got a hacky patch to avoid setting sym->attr.untyped when a real error might not be given, but I'm not sure if it's the right solution. Maybe a better solution would be to emit the diagnostic somewhere other than gfc_set_default_type, at a known point in the processing where it'll only happen once?
[Bug lto/91288] [9/10/11/12 Regression] ICE in add_symbol_to_partition_1, at lto/lto-partition.c:153 since r249224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91288 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #7 from sandra at gcc dot gnu.org --- This ICE doesn't reproduce on mainline (GCC 12) x86_64-linux-gnu for me.
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I'll take a look when I have time, but I'm deep in another bug right now so it may be a few days. Anybody else feel free to grab it meanwhile...
[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #3 from sandra at gcc dot gnu.org --- I'm seeing these failures in my nios2-elf test results today too. :-(
[Bug tree-optimization/92879] [10/11 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
--- Comment #11 from sandra at gcc dot gnu.org ---
The new testcase is failing on nios2-elf.
$ nios2-elf-g++ src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
-O2 -fdump-tree-optimized -S -Wall
In constructor 'S::S(int)',
inlined from 'void __static_initialization_and_destruction_0(int, int)' at
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:26:7,
inlined from '(static initializers for
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C)' at
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:26:8:
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:22:7: warning:
array subscript [0, 536870911] is outside array bounds of 'void [0]'
[-Warray-bounds]
22 | new (p + i) int ();
| ^~
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:19:51: note:
object of size 0 allocated by 'operator new []'
19 | p = (int*) new unsigned char [sizeof (int) * m];
| ^
This is what I see in the .optimized dump file:
;; Function _GLOBAL__sub_I_a (_GLOBAL__sub_I_a, funcdef_no=5, decl_uid=1975,
cgraph_uid=6, symbol_order=6) (executed once)
Removing basic block 5
void _GLOBAL__sub_I_a ()
{
int _2;
void * _5;
sizetype _12;
sizetype _20;
[local count: 1073741824]:
a ={v} {CLOBBER};
a.m = 0;
_5 = operator new [] (0);
a.p = _5;
_2 = a.m;
if (_2 > 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 955630224]:
_20 = (sizetype) _2;
_12 = _20 * 4;
__builtin_memset (_5, 0, _12); [tail call]
[local count: 1073741825]:
return;
}
[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #6 from sandra at gcc dot gnu.org --- Also fails for nios2 (line 20, same as powerpc64). Are we really just xfailing this everywhere instead of fixing the bug and/or testcase? That kind of seems like sweeping the whole mess under the rug, to me. :-S
[Bug other/103163] New: stack_limit_rtx is created too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163 Bug ID: 103163 Summary: stack_limit_rtx is created too early Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- stack_limit_rtx is initialized in init_emit_once() before init_reg_modes_target() is called to fill in the table for hard_regno_nregs. For -fstack-limit-register, this means the REG is created with a zero nregs field, and this ends up tripping over the assertion in df_ref_record while processing prologue instructions using stack_limit_rtx. I observed this in a nios2-elf build, where the testcase gcc.target/nios2/nios2-stack-check-1.c is ICE'ing: $ nios2-elf-gcc /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.target/nios2/nios2-stack-check-1.c -fdiagnostics-plain-output -fstack-limit-register=et -ffat-lto-objects -fno-ident -S -o nios2-stack-check-1.s during RTL pass: pro_and_epilogue /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.target/nios2/nios2-stack-check-1.c: In function 'test': /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.target/nios2/nios2-stack-check-1.c:10:1: internal compiler error: in df_ref_record, at df-scan.c:2610 0xecb4e2 df_ref_record /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:2610 0xecbd10 df_uses_record /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:2869 0xecc1af df_uses_record /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:3045 0xecca08 df_insn_refs_collect /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:3224 0xec774a df_insn_rescan(rtx_insn*) /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:1087 0xf69280 emit_insn_after_1 /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/emit-rtl.c:4598 0xf69439 emit_pattern_after_noloc /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/emit-rtl.c:4646 0xf694a0 emit_insn_after_noloc(rtx_def*, rtx_insn*, basic_block_def*) /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/emit-rtl.c:4670 0xe59262 commit_one_edge_insertion(edge_def*) /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/cfgrtl.c:2051 0xe593ea commit_edge_insertions() /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/cfgrtl.c:2103 0x105b646 thread_prologue_and_epilogue_insns() /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/function.c:6160 0x105c1cc rest_of_handle_thread_prologue_and_epilogue /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/function.c:6534 0x105c3ac execute /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/function.c:6610 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. I think I could hack around this by having the nios2 backend create a fresh REG instead of using stack_limit_rtx directly in the prologue, but that does seem like a hack instead of a proper fix Also, it looks like the bfin, m68k, and rs6000 backends use stack_pointer_rtx too and probably have similar issues. Looks like the assert was introduced in commit 7232f7c4c2d727431096a7ecfcf4ad4db71dcf2a but the underlying problem probably long predates that (it's just that nothing was tripping over it in such an obvious way).
[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from sandra at gcc dot gnu.org --- Fixed, at least the cases I wrote testcases for relating to TS29113 constraint violations.
[Bug fortran/89078] [meta-bug] Improve the gfortran manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078 --- Comment #2 from sandra at gcc dot gnu.org --- I did look over the entire list of still-open issues and did not see any further low-hanging fruit. It also seemed to me that some of the issues on the list are cases where it appears the implementation is broken or not useful, not just the documentation.
[Bug fortran/35930] -pedantic: Check for -std=f95/f2003/f2008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35930
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
--- Comment #2 from sandra at gcc dot gnu.org ---
The manual now documents -pedantic without tying it to Fortran 95, and it
includes a disclaimer
Some users try to use @option{-pedantic} to check programs for conformance.
They soon find that it does not do quite what they want---it finds some
nonstandard practices, but not all.
However, improvements to GNU Fortran in this area are welcome.
I think the docs are OK, but is there more to do for this issue in terms of
fixing what -pedantic does?
[Bug fortran/89078] [meta-bug] Improve the gfortran manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078 Bug 89078 depends on bug 35276, which changed state. Bug 35276 Summary: Doc should described how to compile mixed-language programs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/35276] Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from sandra at gcc dot gnu.org --- Should be fixed now. I added paragraphs about both C++ compatibility and how to link.
[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337 sandra at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #3 from sandra at gcc dot gnu.org --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-November/056906.html
[Bug fortran/35276] Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276 sandra at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #9 from sandra at gcc dot gnu.org --- Well, it looks to me like we currently do not document exactly how to link mixed-language programs, although chapter 7 does cover related concepts like what you have to do to initialize libgfortran if you are linking e.g. a fortran library with a main in some other language. I think this topic does belong in chapter 7 and not any other part of the manual, and that we should not close it. I'll add it to my queue.
[Bug fortran/99250] [F2018] coshape intrinsic is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99250 --- Comment #2 from sandra at gcc dot gnu.org --- Hmmm. I've been going through the list at https://gcc.gnu.org/wiki/Fortran2018Status and there really are a large number of unimplemented F2018 features, not just this one. :-( Anyway, I added a link to this PR from that table.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #23 from sandra at gcc dot gnu.org --- Created attachment 51686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51686=edit add dg-require-effective-target to testcase The new testcase is FAILing on x86 targets configured without REAL*16 support, like so: /path/to/gcc/testsuite/gfortran.dg/pr91497.f90:14:14: Error: Old-style type declaration REAL*16 not supported at (1) /path/to/gcc/testsuite/gfortran.dg/pr91497.f90:21:31: Error: Invalid real kind 16 at (1) compiler exited with status 1 I've got this patch to add some dg-require-effective-target tests, but maybe it would be better to fix the testcase so that it does not depend on target-specific floating-point types? Or add a second testcase that doesn't require all the target restrictions, for broader test coverage on more platforms?
[Bug testsuite/102910] cf-descriptor-5-c.c fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from sandra at gcc dot gnu.org --- Should be fixed now.
[Bug testsuite/102910] cf-descriptor-5-c.c fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910 --- Comment #11 from sandra at gcc dot gnu.org --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-October/056807.html
[Bug testsuite/102910] cf-descriptor-5-c.c fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910 --- Comment #9 from sandra at gcc dot gnu.org --- I will rewrite this testcase not to use alloca. This particular case was originally XFAIL'ed at runtime because the functionality it was supposed to test (assumed-length character interoperability) was broken before Tobias fixed the GFC/CFI descriptor conversion. I was not aware that it was also failing to compile on some targets; I don't have any way to test FreeBSD or AIX targets, in particular.
[Bug fortran/79330] gfortran 5.4.0/6.3.0/7.0.0 misinterpret type of character literal bind(C,name=...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79330 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- Still fails on master (12.0).
[Bug fortran/95375] ICE in add_use_op, Error: mismatching comparison operand types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95375 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- Current behavior on master is to warn, then ICE: $ x86_64-linux-gnu-gfortran -c z1.f90 z1.f90:1:0: 1 | function f() result(n) bind(c) | .. 6 | function f() result(n) bind(c) | 2 Warning: Type mismatch in function result (INTEGER(4)/CLASS(*)) between (1) and (2) z1.f90:4:9: 4 | program p | ^ Error: mismatching comparison operand types struct __class__STAR_a integer(kind=4) if (D.4230 != 0) goto ; else goto ; z1.f90:4:9: internal compiler error: 'verify_gimple' failed 0xfd471d verify_gimple_in_seq(gimple*) /scratch/sandra/x86-fsf/src/gcc-mainline/gcc/tree-cfg.c:5229 0xcee7b6 gimplify_body(tree_node*, bool) /scratch/sandra/x86-fsf/src/gcc-mainline/gcc/gimplify.c:15913 0xcee97d gimplify_function_tree(tree_node*) /scratch/sandra/x86-fsf/src/gcc-mainline/gcc/gimplify.c:15984 0xb1a3b7 cgraph_node::analyze() /scratch/sandra/x86-fsf/src/gcc-mainline/gcc/cgraphunit.c:670 0xb1cec7 analyze_functions /scratch/sandra/x86-fsf/src/gcc-mainline/gcc/cgraphunit.c:1234 0xb1db5d symbol_table::finalize_compilation_unit() /scratch/sandra/x86-fsf/src/gcc-mainline/gcc/cgraphunit.c:2508 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug fortran/49111] Unnecessary warning for private interfaces having the BIND(C) attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #8 from sandra at gcc dot gnu.org --- Still present on master, so no, this bug hasn't spontaneously fixed itself. :-(
[Bug fortran/92701] ICE assigning to assumed rank derived type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92701 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- The testcase no longer ICEs on mainline head. Just mark this issue fixed, or would it be useful to identify what fixed it?
[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- The problem noted in comment 1 looks related to PR 102641 -- automatically-inserted implicit initialization code can't cope with assumed-rank arrays. I tested the patch in comment 2 and saw a whole lot of regressions (ICEs). :-(
