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 correspon
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'
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
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 para
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #8 from sandra at gcc dot gnu.org ---
This bug is addressed in the metadirective/dynamic selector patch set I posted
here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650725.html
ty: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
Target Milestone: ---
Created attachment 58196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=5819
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115076
--- Comment #1 from sandra at gcc dot gnu.org ---
Created attachment 58197
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58197&action=edit
second test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #7 from sandra at gcc dot gnu.org ---
My most recent metadirectives/dynamic selector patch set does include partial
support for dynamic selectors. For C/C++ it handles expressions that reference
variables/functions that are globally
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112973
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111659
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110847
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107942
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108521
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110029
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
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 |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109708
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90464
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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
---
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.
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 |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90463
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115587
--- Comment #2 from sandra at gcc dot gnu.org ---
I'll take care of this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=951
--- Comment #16 from sandra at gcc dot gnu.org ---
Given that this issue was filed >20 years ago and both the passlist and
documentation have changed drastically since then, I think the
originally-reported bugs are probably irrelevant and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115587
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905
--- Comment #2 from sandra at gcc dot gnu.org ---
Isn't this explicitly prohibited by the spec? Second bullet point at the top
of page 295 in TR13 says:
"If a procedure is determined to be a function variant through more than o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905
--- Comment #4 from sandra at gcc dot gnu.org ---
Hmmm. Look also at item 2 at the bottom of page 283, that says that construct
selectors for a variant function are added to its enclosing OpenMP context. I
thought this was the reason for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107067
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88860
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116750
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88284
--- Comment #7 from sandra at gcc dot gnu.org ---
While Intel has revived the "Altera" name, the Nios II processor is still
listed as discontinued. I see they are offering ARM-based FPGA products again
instead.
For many years Altera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928
--- Comment #4 from sandra at gcc dot gnu.org ---
The other GCC manuals I'm familiar with don't format things like man pages;
they use things like @deftypefn instead (e.g., see libgcc.texi). I'm
definitely not volunteering to re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112779
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #13 from sandra at gcc dot gnu.org ---
Leaving this open as we don't have another issue tracking the remaining issues
noted in Comment 9: parsing non-constant expressions in the right scope in the
Fortran front end, and all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118530
--- Comment #6 from sandra at gcc dot gnu.org ---
Created attachment 60421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60421&action=edit
test case quuux.C
Another test case from waffl3x which I think is probably a variant of t
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
waffl3x at protonmail dot com
Target Milestone: ---
Created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118530
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118790
--- Comment #20 from sandra at gcc dot gnu.org ---
Looks like other people are already investigating this? I know nothing about
GC and this might not even have anything to do with the commit that caused the
regression to appear (like PR118714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
--- Comment #15 from sandra at gcc dot gnu.org ---
See also PR115076. I think the low-level implementation of "declare variant"
is all wrong, it needs to be tracked in the lexical scope by each front end
instead of attached as a globa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118714
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||parras at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107067
--- Comment #3 from sandra at gcc dot gnu.org ---
Patch posted for review:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674898.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117150
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117150
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115532
sandra at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
--- Comment #39 from sandra at gcc dot gnu.org ---
So, the gfortran manual already has substantial sections under "Extensions"
about OpenMP and OpenACC. So I guess I will do the same for the GCC manual,
and make that the place where w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111659
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115532
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109214
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111659
--- Comment #7 from sandra at gcc dot gnu.org ---
You're right, I did garble the description of the option in my previous patch.
Will fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116989
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078
Bug 89078 depends on bug 51820, which changed state.
Bug 51820 Summary: [doc] underscoring documentation incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51820
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51820
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115271
--- Comment #3 from sandra at gcc dot gnu.org ---
Is this related to PR115076, the issue about attaching "declare variant" info
to the declaration that is in local scope instead of globally?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115076
--- Comment #2 from sandra at gcc dot gnu.org ---
Thinking about this some more, probably a new tree node type like
OMP_VARIANT_CALL needs to be introduced, that captures the variants in scope at
the call site and the arguments. The problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118457
--- Comment #2 from sandra at gcc dot gnu.org ---
I think this issue ought to be tackled in conjunction with PR115076, the fix
for which will probably take variant resolution out of gimplify_call_expr()
entirely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
--- Comment #1 from sandra at gcc dot gnu.org ---
I see the spec does, in fact, prohibit metadirectives that expand into dynamic
selector code here -- it's at the bottom of page 324 of the OpenMP 6.0
document. So the problem is just the
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
Target Milestone: ---
As noted by Tobias here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
Some recent commits have added large blocks of code to gimplify_call_expr() in
gimplify.cc to handle the OpenM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #9 from sandra at gcc dot gnu.org ---
The just-committed patches implemented most of the support for dynamic
selectors including user/condition. Remaining bugs are as noted in Comment 7:
allowing references to parameter variables of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397
--- Comment #2 from sandra at gcc dot gnu.org ---
C23 is now the default C version, so this issue is unblocked. I'm anticipating
some substantial rewrites/reorganization of all the attribute documentation to
address this and other i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118457
--- Comment #1 from sandra at gcc dot gnu.org ---
Also note that the new testcase c-c++-common/gomp/adjust-args-6.c is xfail'ed
because of this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397
--- Comment #4 from sandra at gcc dot gnu.org ---
PR108796 seems to be more of a "GCC is broken because it doesn't do what I
want" issue, than specifically a documentation issue.
The two issues I'm thinking are most relev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107067
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
--- Comment #3 from sandra at gcc dot gnu.org ---
Curiously, on the OG14 development branch the rvalue calls work but the lvalue
ones are broken instead:
$ install/bin/x86_64-none-linux-gnu-g++ -fopenmp -S quux.C
quux.C: In instantiation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
--- Comment #4 from sandra at gcc dot gnu.org ---
Ooops, I meant "specific to OG14 branch" in my last comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101759
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78874
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112589
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102250
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81831
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117642
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117689
--- Comment #2 from sandra at gcc dot gnu.org ---
More specifically, gcc accepts
enum e;
static enum e thing;
enum e { e1, e2, e3};
but rejects
enum e;
int foo (void)
{
static enum e thing;
return -1;
}
enum e { e1, e2, e3};
and also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42270
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117689
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117689
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118118
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118982
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117689
--- Comment #3 from sandra at gcc dot gnu.org ---
Hmmm, the code in finish_decl() in c-decl.cc seems to be deliberately deferring
the error diagnostic for an incomplete types on certain static decls. From a
user's perspective, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90468
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90468
--- Comment #5 from sandra at gcc dot gnu.org ---
Hmmm, I was using "control" as a noun, e.g. warnings about control and warnings
about data-flow problems, not half of a compound adjective. If that seems
incorrect, of course I can ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81649
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110983
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
401 - 500 of 554 matches
Mail list logo
