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
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=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=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=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
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
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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=115532
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=117150
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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=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=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=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=109467
--- Comment #2 from sandra at gcc dot gnu.org ---
I guess the best thing to do is follow the respective standards, e.g.
% for Fortran keywords
% for OpenMP keywords
I guess Gnu extension keywords could be either upper or lower case, provided
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=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
--- Comment #2 from sandra at gcc dot gnu.org ---
I'll take care of this.
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=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
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=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
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=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=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=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 #1 from sandra at gcc dot gnu.org ---
Created attachment 57883
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57883&action=edit
patch to add instrumentation as diagnostic aid
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&action=edit
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
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=90463
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
--- 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 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=90464
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=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=102998
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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.
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
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=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=110029
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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=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=108521
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=107942
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=111659
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |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=112973
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=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=111274
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
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
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
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&action=edit
first attempt at fix
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
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.
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
++
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&action=edit
WIP patch
While working on some other changes to the "omp for" dir
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 c
: 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__
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
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)
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102621
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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
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
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
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.
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
1 - 100 of 466 matches
Mail list logo
