https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85793
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85788
--- Comment #2 from Martin Liška ---
Created attachment 44137
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44137&action=edit
original test-case
On trunk disappeared in r259672. I'm attaching original test-case which
reproduces on trunk a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85794
--- Comment #2 from Richard Biener ---
Invalid GIMPLE. We have
vect_patt_18.16_33 = VEC_COND_EXPR <_24 != vect_cst__23, vect_cst__31,
vect_cst__32>;
with
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85759
Martin Liška changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #14 from Martin Lišk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85770
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
Bug ID: 85801
Summary: LTO linking fails to reconcile symbol from common an
data sections (-fPIE -Wl,--as-needed -flto):
unresolvable R_ARM_REL32 relocation against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85802
Bug ID: 85802
Summary: false-positive -Wmemset-elt-size when compiling C++
code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
--- Comment #2 from Juneyoung Lee ---
If address is not adjacent - you can reorder the definition of A and B and try
again.
```
int A[4], B[4];
```
If changing
if (c1 == c2)
// Always true if p and q have same integer representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85770
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
CC|
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
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=61502
Richard Biener changed:
What|Removed |Added
Blocks||85800
--- Comment #30 from Richard Bien
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=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=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 #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=84546
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=85783
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
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=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=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=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=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=85802
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |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=83898
Paul Thomas changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
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=35878
Ville Voutilainen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=85800
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
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=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 #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=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 #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=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=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
Actions
尊敬的企业家，
是否聴過：不宣傳等死，宣传這么貴找死！
低於一位销售員月薪費用的大數据新媒体是您的選擇！
不管是本港，国内或者外国市场，我们都有办法为你精凖找出客户！
我们使用的是今天現代人的电子媒体和最先进的IT技术。
衆多的成功範例来自零售、飱飲、地產、貿易、服装、厂家、律师事务所.
我们在香港已经上市十六年，错过這个信息是你最大的遗憾！
来电36102885/36102887
Best Regards
KK Luk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85803
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC|
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=85363
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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:
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=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
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=85807
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
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=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=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=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=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
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
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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=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 #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=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 #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=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 #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
--- Comment #35 from Jason Merrill ---
Is there a reason you can't use [[nodiscard]]?
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=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=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=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=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=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=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
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=85363
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
--- 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=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 #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 #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 #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=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=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=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=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=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=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=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=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
1 - 100 of 112 matches
Mail list logo
