https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104
Bug ID: 96104
Summary: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:681
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92427
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92427
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935
--- Comment #2 from Marek Polacek ---
Doesn't have to be scoped enum:
template struct X { };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96103
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96105
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96105
Bug ID: 96105
Summary: GCC not consistent on whether no_unique_address array
is an empty data member
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #14 from Ian McInerney ---
Is it possible to backport this to the GCC 10 branch? The printing of these
notes makes this warning almost impossible to use on any large project that
uses the standard library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92427
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:36e8db7c2af254a38fba5a874a3104a2cc1b1aac
commit r11-1907-g36e8db7c2af254a38fba5a874a3104a2cc1b1aac
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #14)
> Even the standards changed, too.
> F2018 has the audacity to demand chapter 4.2, item 2.
"(2) it contains the capability to detect and report the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96102
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104
Marek Polacek changed:
What|Removed |Added
Summary|internal compiler error: in |[10/11 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789
Marek Polacek changed:
What|Removed |Added
CC||60rntogo at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789
--- Comment #5 from Marek Polacek ---
Another test:
// PR c++/96104
template void fn(T &);
class E {};
struct F {
template void mfn(T t) { t, fn(E()); } // { dg-error "cannot
bind non-const lvalue reference" }
};
int
main()
{
E e;
F f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104
--- Comment #2 from Marek Polacek ---
Reduced:
// PR c++/96104
template void fn(T &);
class E {};
struct F {
template void mfn(T t) { t, fn(E()); } // { dg-error "cannot
bind non-const lvalue reference" }
};
int
main()
{
E e;
F f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|error-recovery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #16 from G. Steinmetz ---
Yeah, and other parts are sort of amazing too.
Let me allow to cite the complete 4.2, item 2, points (1)-(10) :
2 A processor conforms to this document if:
(1) it executes any standard-conforming program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96087
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #13 from Dominique d'Humieres ---
Tests finished, the patch fixes both pr86551 and pr95980, but not more AFAICT.
> That was on Darwin, right?
Yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
--- Comment #5 from Richard Biener ---
Creating dr for arr_26[_5]
analyze_innermost: success.
base_address: _26
offset from base address: (ssizetype) ((sizetype) (char) _3 * 2)
constant offset from base address: -482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #9)
> This has been true since I started working on gfortran some
> 15+ years ago. Much of the code is written assuming a correctly
> written Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96082
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
Summary|GCC rejects the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
--- Comment #6 from Richard Biener ---
One odd thing is that for unsigned char _3 we get via
wide_int var_min, var_max;
value_range_kind vr_type = get_range_info (tmp_var, _min,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96087
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96082
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859
Tobias Schlüter changed:
What|Removed |Added
Summary|Statically true asserts not |[10/11 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859
--- Comment #6 from Tobias Schlüter ---
Added the regression tag to the title.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96090
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #34 from Eric Botcazou ---
> Eric, thoughts?
Another possibility would be to remove the problematic barriers during the
barriers pass that is run just before reorg:
/* Some old code expects exactly one BARRIER as the NEXT_INSN of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96059
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-07-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081
--- Comment #2 from jbeulich at suse dot com ---
I wasn't even aware of -fno-toplevel-reorder, this suffices as a workaround
here. Thanks.
If nevertheless you're still interested in a testcase, please let me know; for
the moment I'll assume this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #10 from Jonathan Wakely ---
What's wrong with checking the return value of warning_at as in the patch in
comment 8?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96091
--- Comment #3 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #2)
> Why should we not have a VECTOR_CST of POLY_INT_CST elements? If
> POLY_INT_CST
> is not "constant" then it shouldn't be tcc_constant? Looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96049
--- Comment #3 from Martin Liška ---
> Martin - do we have aarch64 spec testing set up somewhere?
Not anymore. I turned if off as it's a SLE-12 machine where we don't a have a
recent enough GCC to build current master. Moreover, the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96078
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #10)
> > Confirmed on preliminary tests (pr86551), full tests in progress: results
> > tomorrow).
>
> Regtested without regression.
Thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96091
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> One odd thing is that for unsigned char _3 we get via
>
> wide_int var_min, var_max;
> value_range_kind vr_type =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96092
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #39 from Martin Liška ---
(In reply to Arseny Solokha from comment #38)
> JFTR I can easily reproduce it e.g. in the following setup:
>
> % powerpc-e300c3-linux-gnu-gcc-11.0.0 -mcpu=power9 -c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96085
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041
--- Comment #7 from Dominique d'Humieres ---
Reduced test (provided t.mod exists)
submodule (t) ts
contains
module procedure bp(s)
! end procedure bp
end submodule ts
end
pr93423_red.f90:5:19:
5 | module procedure bp(s)
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96093
Bug ID: 96093
Summary: __MATHCALLX Error with ';' missing in header file
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #222 from Martin Liška ---
(In reply to Martin Liška from comment #221)
> For the chromium with GCC 10, inliner starts after ~5 minutes, so it's very
> likely inliner that takes so long.
45.07% libc-2.31.so [.]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96030
--- Comment #3 from Bu Le ---
(In reply to Jakub Jelinek from comment #1)
> The directive should be doing what
> #pragma omp declare simd
> does on the target and it is an ABI decision what exactly it does.
Hi,I am still confused about your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96058
--- Comment #5 from Martin Liška ---
So the corrupted STRING_CST is created in LTRANS here:
gcc/expr.c:
│11714 if (TREE_CODE (init) == CONSTRUCTOR && initializer_zerop
(init))
│11715 {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96059
--- Comment #2 from Martin Liška ---
Created attachment 48841
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48841=edit
Reduced test-case
$ g++ -O2 -flto=auto -fdevirtualize-at-ltrans -fvisibility=hidden
-fvisibility-inlines-hidden -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96075
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:7d535ca86a548b76384f3687e1d46677cb652bdb
commit r10-8433-g7d535ca86a548b76384f3687e1d46677cb652bdb
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #221 from Martin Liška ---
For the chromium with GCC 10, inliner starts after ~5 minutes, so it's very
likely inliner that takes so long.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081
--- Comment #3 from rguenther at suse dot de ---
On Tue, 7 Jul 2020, jbeulich at suse dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081
>
> --- Comment #2 from jbeulich at suse dot com ---
> I wasn't even aware of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96094
Bug ID: 96094
Summary: Failure to optimize bool division
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #5 from Tom de Vries ---
This seems to be var-track related.
Before var-track we have:
...
(debug_insn 23 41 24 5 (debug_marker) "test2.c":12:5 -1
(nil))
(call_insn 24 23 25 5 (call (mem:QI (symbol_ref:DI ("abort") [flags 0x41]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95675
Patrick Palka changed:
What|Removed |Added
Keywords||ice-checking
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95675
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94260
Patrick Palka changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||markeggleston at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #6 from Tom de Vries ---
A simple way of fixing this is:
...
diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 899a5c0290d..4b143f6702b 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -6635,7 +6635,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #7 from Tom de Vries ---
A bit more subtle:
...
diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 899a5c0290d..f94eb38f797 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -8880,6 +8880,10 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96095
Bug ID: 96095
Summary: decltype((r)) inside of lambda with copy capture gives
wrong type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93423
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96094
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> Created attachment 48702 [details]
> _absvsi2_s.c
>
> To reproduce:
> ...
> $ gcc -O2 -g -fpic -mlong-double-80 -fcf-protection -mshstk
> -fbuilding-libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95947
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-07-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081
--- Comment #4 from jbeulich at suse dot com ---
Turns out I was wrong here, and the re-ordering was done even by older than gcc
9. The move from 9.2 to 9.3 also included a move to a newer gas, which made the
issue noticable.
Feel free to close
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96095
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789
Marek Polacek changed:
What|Removed |Added
CC||agadethrowaway at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96097
--- Comment #1 from Michael Bruck ---
trunk:
internal compiler error: in dependent_type_p, at cp/pt.c:26326
10.1:
internal compiler error: in dependent_type_p, at cp/pt.c:26343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96096
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96098
Bug ID: 96098
Summary: [11 regression] gcc.dg/vect/bb-slp-pr68892.c fails
since r11-205
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96096
Bug ID: 96096
Summary: g++-10.1 silently ignores function violating const
instead of refusing to compile
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #11 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
Arjen Markus changed:
What|Removed |Added
CC||arjen.markus895 at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96049
Maxim Kuvyrkov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96097
Bug ID: 96097
Summary: ICE in dependent_type_p, at cp/pt.c:26326
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96100
Bug ID: 96100
Summary: [9/10/11 Regression] ICE in gimplify_expr, at
gimplify.c:14638
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #12 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:6f9c9ea40a1e937ea1b549625cf7762d4a8a2078
commit r11-1899-g6f9c9ea40a1e937ea1b549625cf7762d4a8a2078
Author: Martin Sebor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96102
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96102
Bug ID: 96102
Summary: ICE in check_host_association, at
fortran/resolve.c:5994
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #14 from G. Steinmetz ---
> ... and real programmers wrote fine Fortran programs.
Yeah, optimal world. That's probably the reason why some
"real" programs don't need test cases - or at most three,
because they cover everything ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96099
--- Comment #1 from Dominique d'Humieres ---
Confirmed before r11-1337, but r11-1810 (instrumented) and r11-1864 (+patches)
do not give the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96099
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-07-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96058
--- Comment #6 from Martin Sebor ---
The stack trace in comment #0:
during GIMPLE pass: strlen
../../chrome/browser/ui/views/sharing/sharing_icon_view.cc: In member function
‘GetVectorIconBadge’:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96101
Bug ID: 96101
Summary: [9/10/11 Regression] ICE in fold_convert_loc, at
fold-const.c:2398
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96087
--- Comment #3 from G. Steinmetz ---
Thanks for nailing down the commit for addon comment 1.
But when started the regression/issue from comment 0 ?
gfortran 9.3 does not have the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #13 from Martin Sebor ---
Jon, is there anything else to do here or can we resolve this as fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96103
Bug ID: 96103
Summary: Unclear diagnostic for a function return with
"decltype(auto)"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96099
--- Comment #2 from G. Steinmetz ---
Oh yes, of course ... a silly cut and paste thing.
It has to be :
$ cat z1.f90
program p
implicit class(t) (1)
type t
end type
end
$ cat z2.f90
program p
integer n1
parameter (n1 = 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96099
Bug ID: 96099
Summary: ICE in gfc_validate_kind, at fortran/trans-types.c:773
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96100
Dominique d'Humieres changed:
What|Removed |Added
Target Milestone|--- |9.4
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96103
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96085
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=95303
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:9845b7b45621e3833aee47276cb111e43be0e48b
commit r11-1903-g9845b7b45621e3833aee47276cb111e43be0e48b
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95303
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96085
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
That one produces a strange regression with pr50392.f.
Patch that regtests fine:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index
1 - 100 of 105 matches
Mail list logo
