https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483
--- Comment #5 from anlauf at gcc dot gnu.org ---
Instead of adding the SAVE attribute to the declaration, one can get the
same wrong code with -fno-automatic.
The decl generated by gfc_sym_type() looks suspicious in the case when the
SAVE attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114022
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102599
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
--- Comment #12 from anlauf at gcc dot gnu.org ---
Created attachment 61529
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61529&action=edit
Fix for the breakage by r16-914-g787a8dec1acedf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #10)
> Seems like some last-minute cleanup before submission broke something.
> I'll have a look.
It was the last-minute cleanup. Duh!
This fixes it:
diff --gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #9)
> (In reply to anlauf from comment #8)
> > (In reply to Jerry DeLisle from comment #7)
> > > Ruuning tests right now to see if this has caused some bre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #7)
> Ruuning tests right now to see if this has caused some breakage.
Are you also hit by r16-916-g517c9487f8fdc4 which breaks texinfo again?
We had this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120431
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #5)
> (In reply to anlauf from comment #4)
> > (In reply to Jerry DeLisle from comment #3)
> > > My understanding is they are getting built generated in the build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120431
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #3)
> My understanding is they are getting built generated in the build directory
> which is a recent bug someone reported. I dont think it has been fixed y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Summary|[12/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
--- Comment #4 from anlauf at gcc dot gnu.org ---
Created attachment 61505
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61505&action=edit
WIP patch
This WIP patch improves the parsing of expressions with inquiry references
of substrings,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13/14/15/16 Regression] |[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120371
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102599
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2025-5-20
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47803
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120355
--- Comment #1 from anlauf at gcc dot gnu.org ---
Workaround: don't use the result clause in the external function, e.g.
integer function s(x)
implicit none
integer, intent(in) :: x
s = 1 - x
end function s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120355
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120355
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|Type mismatch for passed|[15/16 Regression] Type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #21 from anlauf at gcc dot gnu.org ---
Patch from comment#16 submitted:
https://gcc.gnu.org/pipermail/fortran/2025-May/062180.html
I hope I got the description of the issue right in the changelog.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #20 from anlauf at gcc dot gnu.org ---
Does anybody know why there is the following comment preceding the suspcious
block:
/* Possibly return complex numbers by reference for g77 compatibility.
We don't do this for calls to in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #18 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #17)
> (In reply to Andrew Pinski from comment #15)
> > (In reply to anlauf from comment #14)
> > > This fixes the reduced testcase for me, but gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #15)
> (In reply to anlauf from comment #14)
> > This fixes the reduced testcase for me, but gfortran.dg/specifics_1.f90
> > still fails here.
>
> Which m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #12)
> Good point. Tentative patch which excepts (d)conjg:
>
> diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
> index f8980754685..e1e4f16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #11)
> I wonder why gfc_return_by_reference is not returning true here because I
> think that would be idea here.
Good point. Tentative patch which excep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120302
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120298
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||j...@bolding-bruggeman.com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119928
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||abensonca at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119812
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC|anlauf at gmx dot de |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #8)
> (In reply to GCC Commits from comment #5)
> > commit r16-480-g6ce73ad4370c143a7d1e6a13b1d353db5884213f
>
> > * gfortran.dg/do_concurre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049
--- Comment #26 from anlauf at gcc dot gnu.org ---
Have you tried to move some of the checks *after* the resolution stage?
The checks in check.cc are invoked rather early. Maybe look into
trans-intrinsic.cc (conv_isocbinding_function)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120196
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Here's a testcase that fails under valgrind:
>
> program p
> implicit none
> character(:), allocatable :: a(:), s
> allocate (character(16) :: a(10),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120196
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.2
Assignee|unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179
--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 61373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61373&action=edit
Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120163
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891
--- Comment #4 from anlauf at gcc dot gnu.org ---
Created attachment 61330
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61330&action=edit
Patch for comment#2
This patch fixes the checking of the references, so that inquiry references
of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891
--- Comment #3 from anlauf at gcc dot gnu.org ---
The original issue (comment#0) is fixed with the fix for pr119986,
but the other issue in comment#2 still remains.
It looks like gfc_conv_intrinsic_transfer gets confused by the inquiry ref.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
> $ gfc -c test.f90
> f951: internal compiler error: gfc_typename(): Undefined type
> 0x694bce diagnostic_report_diagnostic(diagnostic_context*, diagn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
--- Comment #7 from anlauf at gcc dot gnu.org ---
Forgot to add: the main has
struct array01_complex(kind=4) parm.12;
so there needs to be a conversion to a real array (with the right stride etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
--- Comment #6 from anlauf at gcc dot gnu.org ---
Workaround: add
contiguous :: u, v
to force generation of a proper temporary.
The dump-tree looks really fishy for the subroutine:
{
integer(kind=8) D.4689;
struct array01_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #5)
> The thread on the J3 ML starts here:
>
> https://mailman.j3-fortran.org/pipermail/j3/2025-April/015230.html
While John Reid thinks the code is valid F2018,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
anlauf at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
--- Comment #5 from anlauf at gcc dot gnu.org ---
The thread on the J3 ML starts here:
https://mailman.j3-fortran.org/pipermail/j3/2025-April/015230.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79330
--- Comment #6 from anlauf at gcc dot gnu.org ---
Looking for examples of the apparent difference between subroutine and
module subroutine in the interface block, I found an example in
F2023:C.10.4 Modules with submodules
paragraph 5, "module c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79330
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #4)
> (In reply to Jerry DeLisle from comment #3)
> > Still fails on trunk (16)
>
> In looking at the code, I'm wondering if it conforms to the Fortran standard.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119928
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119928
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||11.5.0, 12.4.1, 13.3.1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119928
Bug ID: 119928
Summary: [15/16 Regression] Bogus "Interface mismatch" in
gfortran.dg/proc_ptr_52.f90 with -Wall
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900
--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 61187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61187&action=edit
Partial patch
This is a partial patch that addresses the reduced testcase.
However, it does not fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900
--- Comment #7 from anlauf at gcc dot gnu.org ---
Created attachment 61185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61185&action=edit
Reduced partial testcase
This testcase resulted from trying to reduce issues with proc_ptr_52.f90
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114020
--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #0)
> Found with the Fujitsu testsuite. Reduced testcase.
> Note, if the use of ENTRY is replace with an actual
> function, ie., 'function kmr_fixfun() result(zz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|[15/16 Regression] |[15 Regression] Elemental
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119889
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Version|unknown |16.0
--- Comment #6 from anl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119889
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #10)
> Hi Folks,
>
> Is it worth reverting or fixing this before the 15-branch release? After
> all, the bug made its way into the Fedora 42 release?
>
> C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
--- Comment #8 from anlauf at gcc dot gnu.org ---
The elemental intrinsic MVBITS also works fine. Sample testcase:
! { dg-do compile }
! { dg-additional-options "-O3 -fdump-tree-optimized" }
!
! PR fortran/119836 - elemental intrinsic within BL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119827
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106948
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
Bug ID: 119836
Summary: [15 Regression] Elemental intrinsic treated as IMPURE
within BLOCK within DO CONCURRENT
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106948
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106948
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106915
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Keith Refson from comment #3)
> I think it probably also needs to flag up if MOLD contains an allocatable or
> pointer component too. Modifying the example to TRANSFER to an integer,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119546
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119502
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #3)
> I am curious what other compilers do with this.
>
> program foo
> integer :: iun = -1
> open (iun)
> write(iun,*) "This is a test."
> close (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119502
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> Intel:
>
> This is a test.
Forgot to say: this goes to stdout, not to file.
There is no fort.-1 or the like.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119669
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119669
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 61022
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61022&action=edit
Testcase
It actually helps to attach it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |12.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
Bug ID: 119656
Summary: [12/13/14/15 Regression] Wrong code with impure
elemental subroutine and interface
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119460
--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #18)
> (In reply to anlauf from comment #17)
> Thanks for the corrections to generate_reduce_op_wrapper in comment 16 and
> the test of the maximum wrapper n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119460
--- Comment #17 from anlauf at gcc dot gnu.org ---
Created attachment 61014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61014&action=edit
Enhanced version of reduce_4.f90
This fixes also a copy&paste of a subtest and tests the maximum s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119460
--- Comment #16 from anlauf at gcc dot gnu.org ---
Created attachment 61013
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61013&action=edit
Minor fixes to the wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119460
--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #14)
> Created attachment 61006 [details]
> Fix for this PR
>
> I believe that this fixes most, if not all, of the problems with the reduce
> intrinsic. I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119460
--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #12)
With -m32, similarities with the real(16) example from comment#10 and the
struct version in comment#12 might suggest to look at whether we need to
understan
1 - 100 of 1788 matches
Mail list logo
