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=103258
--- Comment #4 from sandra at gcc dot gnu.org ---
Created attachment 51980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51980&action=edit
hacky patch
Attached patch has not been regression tested, but it does seem to fix the
o
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=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=103390
--- Comment #3 from sandra at gcc dot gnu.org ---
Created attachment 51994
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51994&action=edit
-fdump-tree-original output from test case
Here's the full output from -fdump-tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914
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=100917
--- Comment #8 from sandra at gcc dot gnu.org ---
There is a workaround for this included in commit
93b6b2f614eb692d1d8126ec6cb946984a9d01d7
that doesn't fully solve the problem: when "long double" and "float128" are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102282
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
CC: wschmidt at linux dot ibm.com
Target Milestone: ---
Host: powerpc64le-linux-gnu
Target: powerpc64le-linux-gnu
Build: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
--- Comment #1 from sandra at gcc dot gnu.org ---
Ooops, I meant x86_64-linux-gnu build, not host. :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
--- Comment #4 from sandra at gcc dot gnu.org ---
I think rs6000-gen-builtins is supposed to be a build binary, not a host
binary? I'm seeing this at the end of my build log with that patch.
./rs6000-gen-builtins /path/to/gcc/config/r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77652
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
A trivial subroutine with a intent(out) dummy that is a polymorphic
assumed-rank array...
module m
contains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753
--- Comment #5 from sandra at gcc dot gnu.org ---
Patch to add the diagnostic posted here:
https://gcc.gnu.org/pipermail/fortran/2021-October/056656.html
There's still a problem with the bogus diagnostic arising from
deallocation/initializ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102641
--- Comment #2 from sandra at gcc dot gnu.org ---
I was thinking that for assumed-rank the front end should probably just emit a
call to a library support function in the callee, instead of whatever it is
doing now to try to deallocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
--- Comment #11 from sandra at gcc dot gnu.org ---
There are still some bugs present with class arrays. E.g., this test case
ICEs:
module m
type :: t
integer :: id
real :: xyz(3)
end type
contains
subroutine testit2p(a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022
Bug 94022 depends on bug 94070, which changed state.
Bug 94070 Summary: Assumed-rank arrays – bounds mishandled,
SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #21 from sandra at gcc dot gnu.org ---
Tobias, did your big patch fully fix this issue so that we can close it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101304
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101319
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101320
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101333
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101334
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337
--- Comment #1 from sandra at gcc dot gnu.org ---
This is likely a "won't fix" bug, but I'll leave it open for now. The test
cases (now committed) are still XFAILed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907
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=100916
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=100914
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100911
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100915
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99922
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=92482
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||everythingfunctional@proton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342
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=95196
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84007
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=71703
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=65819
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
Bug 36854 depends on bug 65819, which changed state.
Bug 65819 Summary: overzealous checking in gfc_check_dependency for
identical=true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
Bug 37131 depends on bug 65819, which changed state.
Bug 65819 Summary: overzealous checking in gfc_check_dependency for
identical=true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102729
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=100194
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=102641
Bug 102641 depends on bug 102729, which changed state.
Bug 102729 Summary: Assumed rank: ICE when passing noncontiguous to CONTIGUOUS
assume rank (assumed-rank loop handling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102729
What
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
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
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
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
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
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 char
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
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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=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. :-( Anyw
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308
--- Comment #8 from sandra at gcc dot gnu.org ---
I tested the second version of the patch; it does fix the bug I observed with
an assumed-rank array argument in a Fortran subroutine with C binding called
from C having lower bound 0 instead of 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
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=94070
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=92621
--- Comment #18 from sandra at gcc dot gnu.org ---
The short answer re the TS 29113 thing is that it's what the customer who's
funding the work asked us to do. :-)
: 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: ---
Section 18.3.6 of the Fortran 2018 standard says:
"Wh
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jrfsousa at gcc dot gnu.org
Target Milestone: ---
ISO_Fortran_binding.h
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
gfortran is completely failing to create C descriptors for scalar arguments to
bind(c) functions that have
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
The description of CFI_cdesc_t in section 18.5.3 of the 2018 Fortran standard
includes this constraint:
There shall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101309
--- Comment #1 from sandra at gcc dot gnu.org ---
BTW, I did not test any other intrinsics that rearrange the elements of their
input array arguments. TRANPOSE seemed like the most obvious one to try first.
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
Many of the unit tests for CFI_section included in the WIP TS 29113 testsuite
are failing.
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html
At
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
ISO_Fortran_binding.h defines macros to indicate error conditions in functions
such as CFI_establish
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
In section 15.5.2.4 Ordinary dummy variables, the Fortran 2018 standard says:
If the actual argument is of a derived
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
In the WIP TS29113 testsuite posted here
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html
the
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
C711 in the 2018 Fortran standard (originally C407c in TS 29113) says: "An
assumed-type actual argument that corresponds
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
C838 in the 2018 Fortran standard (originally C535b in TS29113) says:
An assumed-rank variable name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
ormal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
In a statement like
a = x + y
if both x and y violate constraints in the Fortran standard, gfortran only
issues a diagn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305
--- Comment #1 from sandra at gcc dot gnu.org ---
There's also some overlap with PR 100917, relating to long double. Getting rid
of the hard-coded kind/size assumptions will take care of at least the C side
of that issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305
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=100917
--- Comment #6 from sandra at gcc dot gnu.org ---
I've been thinking some more about this issue. It seems to me that a "proper"
solution is either (1) Add a kind field to the GFC descriptor or (2) Do away
with GFC descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305
--- Comment #3 from sandra at gcc dot gnu.org ---
Patches posted:
https://gcc.gnu.org/pipermail/fortran/2021-July/056236.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101317
--- Comment #1 from sandra at gcc dot gnu.org ---
Patch posted:
https://gcc.gnu.org/pipermail/fortran/2021-July/056249.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101310
--- Comment #1 from sandra at gcc dot gnu.org ---
Looks like 3 bugs for the price of 1!
First off the loop to fill in the result dimensions in CFI_section seemed to be
applying the base adjustment twice in different ways, or something like that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101310
--- Comment #2 from sandra at gcc dot gnu.org ---
Patch posted here:
https://gcc.gnu.org/pipermail/fortran/2021-July/056251.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482
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=101305
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101310
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101317
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
Per discussion here
https://gcc.gnu.org/pipermail/fortran/2021-August/056334.html
there seems to be some confusion in the Fortran front end re
gfc_real16_is_float128 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
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=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=111274
sandra at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-09-02
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
--- 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 #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 #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
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
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.
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=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
301 - 400 of 546 matches
Mail list logo
