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=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=58196=e
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 refer
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
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
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
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 cas
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
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
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
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
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
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
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
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. Some
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=edit
WIP patch
While working on some other changes to the "omp for" directi
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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
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
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
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
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 generatin
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
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 t
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
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
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 testc
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
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
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
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
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
1 - 100 of 434 matches
Mail list logo
