https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77884
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107143
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-10-04
Ever confirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107074
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=107000
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
--- Comment #23 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #22)
> In looking at the patch, there is a
>
>gcc_assert (op1->ts.type != BT_UNKNOWN);
>
> in reduce_binary_ac() near line 1334 and
>
>gcc_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
--- Comment #5 from anlauf at gcc dot gnu.org ---
There is a check in expr.cc:2623 that is reached if one changes the
testcase to a subroutine, but not if it is a program:
4615 if (!attr.save && rvalue->expr_type == EXPR_VARIABLE
4616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
--- Comment #6 from anlauf at gcc dot gnu.org ---
I tried the following patch, which however regresses on a couple testcases:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index d9d101775f6..cfc6fc055bd 100644
--- a/gcc/fortran/re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100971
--- Comment #3 from anlauf at gcc dot gnu.org ---
Just from a purely technical point, the following would allow to trigger the
proper check, as it allows to look into arrays, and regtests OK:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #5)
> Both match type "integer", kind "4", rank "0".
>
> AFAIK, there is no other consideration than TKR to discern which function
> to call.
Yes, assuming t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #7)
> I think it's in 15.4.3.4.5 Restrictions on generic declarations.
> But it's too late for me to decipher what's written there.
Tomorrow you'll discover
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040
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=102275
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||10.4.0, 11.2.0, 11.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100971
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=105371
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=107215
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=107215
--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 53692
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53692&action=edit
Patch
Check type of source expr before conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107215
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107219
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=107217
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107217
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=107215
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107237
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107217
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107216
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=107216
--- Comment #3 from anlauf at gcc dot gnu.org ---
Potential patch:
diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..9bec299f160 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -1205,6 +1205,10 @@ walk_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
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=93483
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> Harald, I looked at your patch and agree that simplification should be done.
> I don't know why I did not do it when I wrote walk_array_constructor().
Because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #8)
> If regtesting complete ok,
This is the case.
> and Mikael doesn't find any additional problems. Please commit.
The only thing I was fearing^Wexpectin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #11)
> Here is an example, where the array simplifies using the host-associated
> parameter value instead of calling the contained function with the same nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #14 from anlauf at gcc dot gnu.org ---
Is it conceivable that a somewhat weaker form of simplification, which
addresses the parentheses as well as the basic unary and binary operators
could still be used for the time being?
There is s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #14)
> Is it conceivable that a somewhat weaker form of simplification, which
> addresses the parentheses as well as the basic unary and binary operators
> could s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #21 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #17)
> Like this for the first part of the test from the patch:
>
> diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
> index 9e079e42995..5e96bb9658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #22 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #11)
> Here is an example, where the array simplifies using the host-associated
> parameter value instead of calling the contained function with the same nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100971
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #23 from anlauf at gcc dot gnu.org ---
Created attachment 53706
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53706&action=edit
Updated patch
Here's a patch that incorporates comment#17 and comment#20 and adds a testcase
for co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #25 from anlauf at gcc dot gnu.org ---
(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 long, ARITH_OP_NOT_CONSTANT is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Attachment #53706|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141
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=107141
--- Comment #3 from anlauf at gcc dot gnu.org ---
Placing the subroutine into a module also avoids the error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #28 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #27)
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107272
Bug ID: 107272
Summary: ICE in gfc_compare_string and others (related to
pr107217)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107272
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=107272
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107219
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107216
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||10.2.1, 11.3.0, 7.5.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104330
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=100132
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||damian at archaeologic dot
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659
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=104330
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81978
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100098
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=104848
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> The following example shows that bad overflow handling is a regression that
> was likely introduced in 6.x:
>
> program p
> integer, parameter :: b(0) = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105633
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=105633
--- Comment #3 from anlauf at gcc dot gnu.org ---
Here it goes: https://gcc.gnu.org/pipermail/fortran/2022-October/058369.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692
--- Comment #5 from anlauf at gcc dot gnu.org ---
Just an observation: adding to subroutine shape_cray either
save :: ptrzz
or
volatile :: ptrzz
creates sufficient confusion in the middle-end that the code seems to work.
(The code sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317
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=105633
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103474
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=102241
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104352
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=107362
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107380
--- Comment #1 from anlauf at gcc dot gnu.org ---
Very likely a duplicate.
There is a known issue when an attribute of a class variable is given after
the declaration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397
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=103474
--- Comment #4 from anlauf at gcc dot gnu.org ---
Another part which is needed to avoid an ice-on-valid code:
(Note F2018:5.4.7(5): A subobject of a coarray is a coarray if ...)
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 69d0b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
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=103413
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #10)
> Well, a boz is typeless, so it cannot be compatible with any other type.
> So, I would assume, you could do
>
> if (ts1->type == BT_BOZ || ts2->type == BT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #12)
> > pr103413-boz.f90:4:6:
> >
> > 4 | r = z'1234'
> > | 1
> > Error: BOZ literal constant at (1) is neither a DATA statement value nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
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=107426
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=103474
--- Comment #5 from anlauf at gcc dot gnu.org ---
I am now stuck with the following code, which I believe is valid.
(It is accepted by Crayftn and rejected by Intel, but I thought it is
covered by F2018:5.4.7(5)):
program p
type t
integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> so the hidden charlen is tacked on last whereas I think the hidden presence
> argument is also expected to be last. Likely a counting error in generating
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> We now need the corresponding part on the procedure side.
That might be create_function_arglist (trans-decl.cc).
There's currently a single hidden_arglist,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> Is there a public documentation what the ordering should be?
It is actually documented for gfortran:
https://gcc.gnu.org/onlinedocs/gfortran/Argument-passi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
--- Comment #6 from anlauf at gcc dot gnu.org ---
Created attachment 53782
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53782&action=edit
Patch
Regtesting the attached patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> Created attachment 53782 [details]
> Patch
>
> Regtesting the attached patch.
Looks good for the reported issue.
However, while working on variations of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107444
Bug ID: 107444
Summary: ICE on character, value, optional dummy argument
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> However, while working on variations of the testcase, I hit an ICE for:
>
> subroutine test3 (w)
> character, intent(in), value, optional :: w
> print*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
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=107397
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> This patch fixes the ICE and issues an error. It has passed
> regression testing.
Great!
Do you plan to submit your patch? (Hint: git gcc-commit-mklog).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #5)
> No. I have no idea how to add a testcase to git.
> Every time I've tried, I end up deleting my git
> repository and grabbing a new clone. Not a pleas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397
--- Comment #7 from anlauf at gcc dot gnu.org ---
Created attachment 53789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53789&action=edit
Formatted patch
Here's the commands to generate the attached formatted patch,
assuming that decl.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100103
Bug 100103 depends on bug 100097, which changed state.
Bug 100097 Summary: Unlimited polymorphic pointers and allocatables have
incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100097
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100097
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100098
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100103
Bug 100103 depends on bug 100098, which changed state.
Bug 100098 Summary: Polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100098
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107331
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=107444
--- Comment #1 from anlauf at gcc dot gnu.org ---
It appears that there is also confusion about the procedure decl.
This is demonstrated by:
program p
call s()
call s('') ! Actual argument is too short, reject?
call s('a')
call s('ab')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107444
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107444
--- Comment #3 from anlauf at gcc dot gnu.org ---
Regarding ABI questions, I've inquired on the ML:
https://gcc.gnu.org/pipermail/fortran/2022-November/058410.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107559
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107559
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
701 - 800 of 1554 matches
Mail list logo
