https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120518
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120518
--- Comment #2 from sandra at gcc dot gnu.org ---
OK, found it. The problem is the newly-added code that wraps the
condition/device_num expr in a cleanup_point. This screws up the code in
omp_device_num_check (in omp-general.cc) that detects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120518
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=120180
--- Comment #4 from sandra at gcc dot gnu.org ---
I have a patch that fixes the ICE (not fully tested on an offload target yet,
though).
The issue of whether a metadirective is supposed to be accepted in a loop nest
is completely separate from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
--- Comment #7 from sandra at gcc dot gnu.org ---
Hmmm, that is helpful. Which pass is it that depends on the strict nesting of
"omp teams" within "omp target" for code generation? Is that also in omp-low
(where the nestin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
--- Comment #5 from sandra at gcc dot gnu.org ---
Created attachment 61485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61485&action=edit
test case metadirective-1a.c with dynamic selector
Hmmm, interesting. I temporarily #ifdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
--- Comment #4 from sandra at gcc dot gnu.org ---
The nesting error is diagnosed in omp-low.cc. By this time the gimplifier has
already replaced the metadirective with a conditional. Since it's a static
selector, it'll be res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91917
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=88382
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90465
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71094
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71094
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
Keywords: documentation
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
At optimization levels below -O1 or -Og, the pass manager completely skips most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203
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=78876
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=42683
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71268
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
Keywords: documentation
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
The "Known Causes of Trouble with GCC" manual chapter is so bit-rotten t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97585
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108134
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106618
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105548
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=82265
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87909
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61744
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=85562
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
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=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=90468
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110983
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
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=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=81831
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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=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=38376
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=60972
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=61727
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101440
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: ---
I noticed this while working on PR58973.
In common.opt, we have
Werror
Common Var(warnings_are_errors)
Turn all warnings into errors.
Werror=
Common Joined
Turn the specified warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58973
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78008
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114957
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=118965
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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=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=117689
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |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=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=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=42270
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118965
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=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=42270
--- Comment #7 from sandra at gcc dot gnu.org ---
I've checked in patches doing most of the re-ordering, but I'm leaving this
issue open for now because I'd still like to do something to group the
attributes and built-ins sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42270
--- Comment #2 from sandra at gcc dot gnu.org ---
I've picked up this issue again (after almost 10 years!) because it continues
to annoy me how hard it is to find information in this chapter unless you
already know what to search for.
A pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118579
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118579
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=118457
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67301
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66953
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=56682
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116708
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 113515, which changed state.
Bug 113515 Summary: Wrong documentation for -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113515
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113515
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112960
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=117029
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078
Bug 89078 depends on bug 47928, which changed state.
Bug 47928 Summary: Gfortran intrinsics documentation paragraph ordering
illogical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106316
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=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=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=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 #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=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=107067
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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=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=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=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=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
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=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=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=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=114596
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=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=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=88860
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
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=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=51820
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
1 - 100 of 554 matches
Mail list logo
