https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #6 from Mikael Morin ---
Created attachment 49609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49609&action=edit
rough patch
OK, I understand better the problem.
It’s not a bug that the kind argument is not used to produce co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> rough patch
>
Well, it doesn’t fix comment #5. :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #8 from Mikael Morin ---
(In reply to Mikael Morin from comment #7)
> Well, it doesn’t fix comment #5. :-(
Pilot error, it does fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923
--- Comment #2 from Mikael Morin ---
(In reply to Mikael Morin from comment #1)
> Should be easy to fix anyway.
Not that easy after all.
The following (obvious) fix regresses heavily.
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
inde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923
--- Comment #3 from Mikael Morin ---
Here is a small reproducer by the way:
program p
implicit none
call s(0)
contains
subroutine s(i)
integer :: i
end subroutine s
end program p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957
--- Comment #2 from Mikael Morin ---
Interestingly, the three lines removed in the previous comment come from a fix
for PR41093, whose title is "memory leaks with gfc_namespace".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
--- Comment #3 from Mikael Morin ---
(In reply to anlauf from comment #2)
> The attachment in pr68800 may serve as a starting point:
>
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36964
Thanks, reduced:
MODULE m
TYPE :: a
END TYPE
END
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
--- Comment #5 from Mikael Morin ---
This does NOT improve things:
diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
index 601497e0998..2d6c7b8ef73 100644
--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.cc
@@ -5258,7 +5258,10 @@ r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
--- Comment #6 from Mikael Morin ---
Created attachment 54598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54598&action=edit
Tentative patch
Indeed the namespaces created during module loading are not stored anywhere, so
they are leaked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
--- Comment #4 from Mikael Morin ---
Created attachment 54642
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54642&action=edit
Dra
(In reply to Mikael Morin from comment #3)
> Created attachment 54641 [details]
> Draft patch
>
> I couldn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
Attachment #54641|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
Attachment #54643|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #35 from Mikael Morin ---
A little status update.
I have pushed the latest patch attached to this PR a little further, but not
far enough to reduce the number of testsuite regressions to 0.
I plan to submit it for gcc-13, but it wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662
--- Comment #13 from Mikael Morin ---
(In reply to Mikael Morin from comment #12)
> ... so I must be missing important.
I must be missing *something* important.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662
--- Comment #17 from Mikael Morin ---
(In reply to Jakub Jelinek from comment #15)
> Now, the question is what is the Fortran unlimited polymorphic semantics, if
> one can store through one type and read through a different type which just
> has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99308
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93256
Mikael Morin changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104845
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100813
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379
Mikael Morin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379
--- Comment #3 from Mikael Morin ---
Created attachment 52876
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52876&action=edit
Draft patch
This shows no testsuite regression.
But there is something that I want to check before submitting i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381
--- Comment #1 from Mikael Morin ---
Draft patch.
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e4b6270ccf8..e0070aa080d 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3698,7 +3698,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
--- Comment #24 from Mikael Morin ---
(In reply to anlauf from comment #22)
>
> The remaining problem from PR41453#c8 is the following code in trans-expr.cc:
>
> (gdb) l 9539,9548
> 9539 else if (add_clobber && expr->ref == NULL)
> 95
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
--- Comment #26 from Mikael Morin ---
(In reply to anlauf from comment #25)
> (In reply to Mikael Morin from comment #24)
> > (In reply to anlauf from comment #22)
> > >
> > > The remaining problem from PR41453#c8 is the following code in
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
--- Comment #28 from Mikael Morin ---
(In reply to anlauf from comment #23)
>
> No, they're not, when the procedures are in the same file.
> At least that's what gdb tells me...
gdb tells me the same. :-)
It is a side effect of calling gfc_che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #53 from Mikael Morin ---
(In reply to Mikael Morin from comment #52)
> I posted a mostly-finished patch at [1] to restore array indexing of
> descriptor arrays.
I forgot to add a link for [1]:
https://gcc.gnu.org/pipermail/fortran/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817
Bug ID: 106817
Summary: clobber ordering problem when an actual intent(in)
argument depends on the value of an intent(out)
argument
Product: gcc
Version: unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817
--- Comment #1 from Mikael Morin ---
PR92178 is vaguely related.
The tests are very similar, but that other PR is about allocatables whereas
this one isn’t, so I think they are different.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
--- Comment #31 from Mikael Morin ---
(In reply to Mikael Morin from comment #30)
> (In reply to anlauf from comment #29)
> >
> > but if your patch regtests fine then you should proceed.
>
> Ok, let’s see how good it is.
> Assigning.
It seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817
--- Comment #3 from Mikael Morin ---
(In reply to anlauf from comment #2)
>
> What am I missing?
The right testcase.
Try this one.
module m
implicit none
contains
subroutine copy(out, in)
integer, intent(in) :: in
integer, intent(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817
--- Comment #4 from Mikael Morin ---
(In reply to anlauf from comment #2)
> I see:
>
> D.4225 = a + 1;
> a = {CLOBBER};
> copy (&D.4225, &a);
>
> so I do not see any failure.
With the testcase from comment #3, it becomes:
a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817
Mikael Morin changed:
What|Removed |Added
Last reconfirmed||2022-09-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106750
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
--- Comment #18 from Mikael Morin ---
(In reply to anlauf from comment #14)
>
> We could walk through the elements of each array passed to reduce_binary
> and check the types of the elements there, or do this check in a somewhat
> more clever w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
--- Comment #19 from Mikael Morin ---
(In reply to anlauf from comment #17)
> (In reply to anlauf from comment #16)
> > Created attachment 53651 [details]
> > Revised patch
>
> Unfortunately this regresses on gfortran.dg/pr91552.f90, e.g.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #9 from Mikael Morin ---
(In reply to Jeff Hammond from comment #2)
>
> My MCVE:
>
> module f
> implicit none
>
> interface test
> module procedure test_f08
> module procedure test_f08ts
> end interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102275
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #17 from Mikael Morin ---
There is the possibility to bail out at the very point where things are about
to go wrong, and hope that at resolution time simplification will happen.
Like this for the first part of the test from the patch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #18 from Mikael Morin ---
(In reply to Mikael Morin from comment #17)
> And something similar for the rest of the test (the binary operators).
Like this:
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 5e96bb9658e..3f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #19 from Mikael Morin ---
(In reply to Mikael Morin from comment #18)
> (In reply to Mikael Morin from comment #17)
> > And something similar for the rest of the test (the binary operators).
>
> Like this:
>
It doesn't work unfortun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #20 from Mikael Morin ---
(In reply to Mikael Morin from comment #19)
> (In reply to Mikael Morin from comment #18)
> > (In reply to Mikael Morin from comment #17)
> > > And something similar for the rest of the test (the binary opera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #24 from Mikael Morin ---
(In reply to anlauf from comment #21)
>
> Yeah, I was getting just rather close to this one...
>
Sorry, I didn't want to take it out of your hands.
It seemed that no real solution was emerging.
(In reply t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #27 from Mikael Morin ---
(In reply to anlauf from comment #25)
> (In reply to Mikael Morin from comment #24)
> > First, the ARITH_INVALID_TYPE should be renamed as it has now a broader
> > usage (ARITH_OP_NOT_LITERAL_VALUE is a bit l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #12 from Mikael Morin ---
(In reply to Thomas Koenig from comment #11)
> (In reply to Richard Biener from comment #10)
>
> > Is there any case where the frontend would make 'data' point into the
> > middle of the array and iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #14 from Mikael Morin ---
Created attachment 51787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51787&action=edit
draft patch
This "fixes" the problem of negative index access, and adjusts vector subscript
handling, so that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Attachment #51787|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #19 from Mikael Morin ---
(In reply to Thomas Koenig from comment #15)
> One possibility would be to extend the patch Sandra posted at
> https://gcc.gnu.org/pipermail/fortran/2021-January/055563.html
> to scalarization.
Probably nic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Attachment #51791|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #23 from Mikael Morin ---
(In reply to Richard Biener from comment #21)
> (In reply to Bernhard Reutner-Fischer from comment #17)
> > Do we want to address arrays always at position 0 (maybe to help graphite ?)
>
> Helping graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Attachment #51839|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Attachment #51891|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #28 from Mikael Morin ---
I’m reading the previous comments again:
(In reply to Richard Biener from comment #10)
> So to clarify the ARRAY_REF constraints - there is currently no way to
> construct a valid ARRAY_REF where an index d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103472
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103671
Bug ID: 103671
Summary: arrays with negative strides are wrongly passed as
argument.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103671
Mikael Morin changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #30 from Mikael Morin ---
*** Bug 103671 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789
Bug ID: 103789
Summary: ICE when providing kind argument to mask{l,r}
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789
--- Comment #1 from Mikael Morin ---
maskr is the same.
Fix probably similar to PR87851.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #6 from Mikael Morin ---
(In reply to anlauf from comment #5)
> (In reply to Mikael Morin from comment #4)
> > But is it required to generate a temporary?
> > As I understand it, the code is invalid, and (correctly) diagnosed, so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #8 from Mikael Morin ---
(In reply to anlauf from comment #3)
> Could need help by some expert on this...
I guess I qualify as expert.
Reading the code again after years, it is not exactly crystal clear...
Here is a dump of what I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #9 from Mikael Morin ---
(In reply to anlauf from comment #7)
>
> In the meantime, do you have an idea where to force the generation of a
> temporary? I've been scrolling through gfc_conv_procedure_call to see
> if that might be th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #12 from Mikael Morin ---
(In reply to anlauf from comment #11)
> Update: Steve Lionel thinks that no temporary is necessary, and testcase
> z1.f90
> is non-conforming:
>
> https://community.intel.com/t5/Intel-Fortran-Compiler/ELEME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
Bug ID: 105547
Summary: No further "Unclassifiable statement" after the first
one if multiple syntax errors.
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
--- Comment #1 from Mikael Morin ---
In parse.cc, we avoid emitting an error if an other has been emitted.
But it uses the total error count, not the number of errors since we started
matching the current statement.
597 if (!gfc_error_check ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
--- Comment #6 from Mikael Morin ---
(In reply to kargl from comment #5)
> (In reply to Mikael Morin from comment #4)
>
> > (In reply to kargl from comment #3)
> > > Yep, agreed. I went back an re-read the section about ASSOCIATE.
> > > Not su
1 - 100 of 253 matches
Mail list logo
