https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85757
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85757
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Thu May 17 06:57:45 2018
New Revision: 260306
URL: https://gcc.gnu.org/viewcvs?rev=260306&root=gcc&view=rev
Log:
2018-05-17 Richard Biener
PR tree-optimization/85757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #23 from janus at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #21)
> If we make guarantees that the standard does not, we will be
> creating our own language
I certainly don't want to create my own language. I'm trying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #22 from Andrew Pinski ---
I don't think the middle end can even change. the semantics of TRUTH_ANDIF_EXPR
is always to short circuit. If you want a non short circuit you need to use
TRUTH_AND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #21 from Thomas Koenig ---
> Well, that was absolutely not my intention when I opened this PR, and it
> still isn't. Quite the opposite: I don't think gfortran should apply more
> optimizations, but less. I'm changing the title and k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85760
--- Comment #6 from Eric Botcazou ---
> I only filed the report here once (at least purposely).
Didn't you file exactly the same bug report with AdaCore?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords|diagnostic, |wrong-code
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #19 from janus at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #17)
> Then you are only interest in the special case of .and.
>
> binop above is the entire collection of all binary
> operators (e.g., +,-,*,/ etc as well a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71181
François Dumont changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85814
Bug ID: 85814
Summary: ICE Segmentation fault during GIMPLE pass: strlen -O3
and above
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813
Bug ID: 85813
Summary: make_exception_ptr should support
__cxa_init_primary_exception path even with
-fno-exceptions
Product: gcc
Version: 9.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85812
Bug ID: 85812
Summary: make_exception_ptr can leak the allocated exception if
construction throws
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #10 from H.J. Lu ---
For LDPR_PREVAILING_DEF_IRONLY_EXP, if the IR definition is common,
compiler can't assume that the IR definition will prevail during the
final link. This is another COMMON symbol issue like
https://sourceware.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85760
--- Comment #5 from Jere ---
Created attachment 44140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44140&action=edit
combined ada files in (hopefully) gnatchop friendly format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85760
--- Comment #4 from Jere ---
I only filed the report here once (at least purposely). The website was laggy
when I submitted so perhaps it got submitted twice accidentally? My side of
the interface only shows 2 bugs from me that are completely d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85810
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 16 May 2018, cookevillain at yahoo dot com wrote:
> The Standard is supposed to be a formal specification of the language, so if
No, it isn't. It's for humans, who need to interpre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69905
andreas.molzer at gmx dot de changed:
What|Removed |Added
CC||andreas.molzer at gmx dot d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
--- Comment #6 from Marc Glisse ---
What does tree_expr_nonnegative_p call non-negative? A natural definition would
exclude NaN, but for REAL_CST we just return ! REAL_VALUE_NEGATIVE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85810
--- Comment #2 from cookevillain at yahoo dot com ---
There is nothing obvious about the intent of the Standard here (see the
definition of type name scope introduced into the standard to handle a similar
formal issue). Grammatically, parameter de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #18 from Dominique d'Humieres ---
This PR is now about a missed optimization in the middle-end.
Would it possible to move further discussions to pr57160? TIA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> case MAX_EXPR:
> return RECURSE (op0) || RECURSE (op1);
>
> This is not true if one is a NAN.
And the reason why it is not true for NAN is simple:
If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
--- Comment #4 from Andrew Pinski ---
case MAX_EXPR:
return RECURSE (op0) || RECURSE (op1);
This is not true if one is a NAN.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Applying pattern match.pd:832, gimple-match.c:11245
> Match-and-simplified ABS_EXPR to val_5
Which is:
(simplify
(abs tree_expr_nonnegative_p@0)
@0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
--- Comment #2 from Andrew Pinski ---
Applying pattern match.pd:832, gimple-match.c:11245
Match-and-simplified ABS_EXPR to val_5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
--- Comment #1 from Marc Glisse ---
tree_binary_nonnegative_warnv_p for RDIV_EXPR does RECURSE (op0) && RECURSE
(op1), but that doesn't work so well when the denominator can be 0. I guess it
is still ok when finite-math-only (or no-nans and no-si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #17 from Steve Kargl ---
On Wed, May 16, 2018 at 08:41:42AM +, janus at gcc dot gnu.org wrote:
>
> > and implement it to transform
> > result = op1 binop op2
> >
> > into
> >
> > tmp1 = op1
> > tmp2 = op2
> > result = tmp1 BINO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
Bug ID: 85811
Summary: Invalid optimization with fmax, fabs and nan
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85363
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85363
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Wed May 16 20:37:45 2018
New Revision: 260300
URL: https://gcc.gnu.org/viewcvs?rev=260300&root=gcc&view=rev
Log:
PR c++/85363
* call.c (set_flags_from_callee): Handle A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85810
--- Comment #1 from joseph at codesourcery dot com ---
This is an obviously perverse interpretation of the standard that is
inconsistent with the intent expressed explicitly if non-normatively in
6.7.6.3#18 ("The identifiers x and y are declare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85682
--- Comment #4 from Luis Machado ---
(In reply to James Greenhalgh from comment #3)
> The bisect robot doesn't bootstrap, only build a stage 1 compiler.
>
> I've checked your most recent patch against these testcases, and they
> execute and comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714
--- Comment #4 from TC ---
[dcl.enum]p4:
The underlying type can be explicitly specified using an enum-base. For a
scoped enumeration type, the underlying type is int if it is not explicitly
specified. In both of these cases, the underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714
--- Comment #3 from Thomas Otto ---
I thought forcing out-of-range enum values is no longer unspecified but now
undefined behavior in C++17:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766
http://obiwahn.org/c++draft/expr.stati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85810
Bug ID: 85810
Summary: gcc incorrectly handles declarations inside parameter
lists of function declarators.
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85662
--- Comment #6 from roland at gnu dot org ---
Thanks for the fix. What's the status on backporting this to 8 and/or 7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85682
--- Comment #3 from James Greenhalgh ---
The bisect robot doesn't bootstrap, only build a stage 1 compiler.
I've checked your most recent patch against these testcases, and they execute
and complete fine.
(In reply to Luis Machado from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #36 from Jason Merrill ---
(In reply to Jason Merrill from comment #35)
> Is there a reason you can't use [[nodiscard]]?
...ah, because this is a bug report against the C compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #35 from Jason Merrill ---
Is there a reason you can't use [[nodiscard]]?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #9 from Richard Earnshaw ---
(In reply to rguent...@suse.de from comment #8)
>
> Sure. So I'd say common symbols that are exported may not be in an anchor
> group?
In the shared library this isn't a common symbol: it has an initia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Ed Catmur changed:
What|Removed |Added
CC||ed at catmur dot uk
--- Comment #34 from Ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #8 from rguenther at suse dot de ---
On May 16, 2018 6:27:37 PM GMT+02:00, "rearnsha at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
>
>--- Comment #7 from Richard Earnshaw ---
>(In reply to rguent...@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #7 from Richard Earnshaw ---
(In reply to rguent...@suse.de from comment #6)
> Can't we decide that per symbol? Or somehow force the dynamic linker to use
> the program symbol?
At what point? We've no idea during compilation which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #6 from rguenther at suse dot de ---
On May 16, 2018 5:07:57 PM GMT+02:00, "rearnsha at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
>
>--- Comment #5 from Richard Earnshaw ---
>> ld: relocation R_AARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85670
--- Comment #3 from Jonathan Wakely ---
Oh I see, that line isn't compiled except on Windows, and does need a
declaration of operator!=.
I've fixed it locally now anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #5 from Richard Earnshaw ---
> ld: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `progname' which may
> bind externally can not be used when making a shared object; recompile with
> -fPIC
So this is the start of the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83306
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85809
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
On 16/05/18 13:58 +, Jason Vas Dias wrote:
Great thanks for your informative response, Jim! :
RE:
On 23/04/2018, Jim Wilson wrote:
On 04/23/2018 07:11 AM, Jason Vas Dias wrote:
I really do not think a '-Wpedantic -Wconversion' warning should
be generated for the following code, but it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85809
Bug ID: 85809
Summary: SFINAE code compiles that shouldn't be able to
compile.
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588
--- Comment #12 from Paolo Carlini ---
What I'm finishing testing:
Index: cp/parser.c
===
--- cp/parser.c (revision 260280)
+++ cp/parser.c (working copy)
@@ -21308,7 +21308,7 @@ cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805
--- Comment #3 from Sandor Zsuga ---
I don't have reasonably easy access to a newer version as it doesn't seem like
there were precompiled binaries available for Linux which I could try without
much hassle.
If someone had one laying around, I wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805
--- Comment #2 from Sandor Zsuga ---
Tested on a different machine:
avr-gcc (GCC) 4.9.2
This is what comes with Debian Jessie. The behavior is present (function
compiles to a single "ret").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85807
--- Comment #2 from Marek Polacek ---
Started with r253599.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85807
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85807
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85808
Bug ID: 85808
Summary: [concepts] unqualified name lookup breaks after
qualified lookup in nested requirement
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Se
Great thanks for your informative response, Jim! :
RE:
On 23/04/2018, Jim Wilson wrote:
> On 04/23/2018 07:11 AM, Jason Vas Dias wrote:
>>
>> I really do not think a '-Wpedantic -Wconversion' warning should
>> be generated for the following code, but it is
>> (with GCC 6.4.1 and 7.3.1 on RHEL-7.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85807
Bug ID: 85807
Summary: ICEs related to noexcept
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85363
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85806
Bug ID: 85806
Summary: [concepts] Hard error for "invalid use of non-static
data member" in a requires expression
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85803
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC|
Actions
尊敬的企业家，
是否聴過：不宣傳等死，宣传這么貴找死！
低於一位销售員月薪費用的大數据新媒体是您的選擇！
不管是本港，国内或者外国市场，我们都有办法为你精凖找出客户！
我们使用的是今天現代人的电子媒体和最先进的IT技术。
衆多的成功範例来自零售、飱飲、地產、貿易、服装、厂家、律师事务所.
我们在香港已经上市十六年，错过這个信息是你最大的遗憾！
来电36102885/36102887
Best Regards
KK Luk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588
--- Comment #11 from Paolo Carlini ---
I think I figured out why my first try didn't really work. It's a latent
issue/weirdness in cp_parser_parameter_declaration_list: it is setting
*is_error = true, returning error_mark_node - and maybe calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870
Jonathan Wakely changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85670
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #4 from H.J. Lu ---
(In reply to rguent...@suse.de from comment #3)
>
> I see. But why's the resolution dependent on --as-needed?
Since with --as-needed, in the first pass, linker doesn't include
libxfs.so, pogram is set to COMMON.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85759
--- Comment #15 from Martin Liška ---
A simple solution how to prevent the pathological situation is for now not to
use directory in -fprofile-{generate,use}.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #3 from rguenther at suse dot de ---
On Wed, 16 May 2018, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
>
> --- Comment #2 from H.J. Lu ---
> (In reply to Richard Biener from comment #1)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85802
--- Comment #2 from Milian Wolff ---
Oh, awesome - it actually detected a bug :) It should have been "char buf", not
"char* buf".
Thanks for opening my eyes here, I stared at this for a while and couldn't spot
the issue. The fact that it wasn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #2 from H.J. Lu ---
(In reply to Richard Biener from comment #1)
> I think this is valid from an ELF perspective. But ca you really expect
> char *progname to resolve to the library copy? In fact the linker resolution
> here is
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85757
--- Comment #4 from Richard Biener ---
Ontop of recent patches:
diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index 32a25b9eb1e..1b672ad204a 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -577,6 +577,7 @@ dse_classify_store (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
Paul Thomas changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
Ville Voutilainen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #15 from Paul Thomas ---
Author: pault
Date: Wed May 16 11:42:47 2018
New Revision: 260286
URL: https://gcc.gnu.org/viewcvs?rev=260286&root=gcc&view=rev
Log:
2018-05-16 Paul Thomas
PR fortran/83149
Backport from t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #14 from Paul Thomas ---
Author: pault
Date: Wed May 16 11:17:10 2018
New Revision: 260285
URL: https://gcc.gnu.org/viewcvs?rev=260285&root=gcc&view=rev
Log:
2018-05-16 Paul Thomas
PR fortran/83149
Backport from t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805
Bug ID: 85805
Summary: Improper code generation for 64 bit comparisons on
avr-gcc
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83898
Paul Thomas changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83898
--- Comment #7 from Paul Thomas ---
Author: pault
Date: Wed May 16 10:41:48 2018
New Revision: 260284
URL: https://gcc.gnu.org/viewcvs?rev=260284&root=gcc&view=rev
Log:
2018-16-05 Paul Thomas
PR fortran/83898
Backport from tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85802
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83898
--- Comment #6 from Paul Thomas ---
Author: pault
Date: Wed May 16 10:18:20 2018
New Revision: 260282
URL: https://gcc.gnu.org/viewcvs?rev=260282&root=gcc&view=rev
Log:
2018-16-05 Paul Thomas
PR fortran/83898
Backport from tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804
sudi at gcc dot gnu.org changed:
What|Removed |Added
Target||aarch64-none-linux-gnu
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804
Bug ID: 85804
Summary: [8/9 Regression][AArch64] Mis-compilation of loop with
strided array access and xor reduction
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85803
Bug ID: 85803
Summary: [6/7/8/9 Regression] DSE removes live global store
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84219
Paul Thomas changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799
--- Comment #4 from Jan Hubicka ---
> I believe inlining is happening too late for it to have an effect - we are
> early inlining a body which has the __builtin_expect replaced by nothing.
>
> Iff the expected outcome is "constant" a new functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85373
--- Comment #1 from fiesh at zefix dot tv ---
The problem is that d_count_templates_scopes calls itself infinitely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84546
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84546
--- Comment #9 from Paul Thomas ---
Author: pault
Date: Wed May 16 09:35:19 2018
New Revision: 260281
URL: https://gcc.gnu.org/viewcvs?rev=260281&root=gcc&view=rev
Log:
2018-05-16 Paul Thomas
PR fortran/84546
Backport from tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
Richard Biener changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84546
--- Comment #8 from Paul Thomas ---
*** Bug 83118 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
Richard Biener changed:
What|Removed |Added
Blocks||85800
--- Comment #30 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
--- Comment #3 from rguenther at suse dot de ---
On Wed, 16 May 2018, juneyoung.lee at sf dot snu.ac.kr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
>
> --- Comment #2 from Juneyoung Lee ---
> If address is not adjacent - you ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #15)
> To be clear.
First of all, I'd have preferred to have a Fortran standard which gives clear
and precise instructions on how a compiler should handle cas
1 - 100 of 112 matches
Mail list logo
