https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352
Andrew Pinski changed:
What|Removed |Added
Component|debug |target
--- Comment #17 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
--- Comment #8 from Guillaume Melquiond
---
It is partly fixed. In callee position, GCC now knows that "this" is non-null.
But in caller position, GCC still cannot make use of that information to remove
non-null checks from dynamic casts. The fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #48 from Bernd Edlinger ---
somethin like that fixes it for me:
Index: pr66415-1.c
===
--- pr66415-1.c (revision 239624)
+++ pr66415-1.c (working copy)
@@ -1,6 +1,7 @@
ted passes3
/home/ed/gnu/gcc-build/gcc/xgcc version 7.0.0 20160819 (experimental) (GCC)
COLUMNS=80 make check-gcc-c RUNTESTFLAGS="cpp.exp=pr66415-1.c"
...
Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/cpp/cpp.exp ...
FAIL: gcc.dg/cpp/pr66415-1.c expected multiline pattern lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49348
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61839
--- Comment #3 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sat Aug 20 01:18:09 2016
New Revision: 239637
URL: https://gcc.gnu.org/viewcvs?rev=239637&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2016-08-20 Kugan Vivekanandarajah
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77306
--- Comment #1 from James Abbatiello ---
Created attachment 39478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39478&action=edit
Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77306
Bug ID: 77306
Summary: Unable to specify visibility for explicit template
instantiations
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77305
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01456.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77305
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77305
Bug ID: 77305
Summary: [7 Regression] -fdump-tree-all and -flto causes ICE
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Thread model: posix
gcc version 7.0.0 20160819 (experimental) [trunk revision 239608] (GCC)
$
$ g++-trunk -c small.cpp
small.cpp:5:14: error: ‘struct S’ is not a valid type for a template non-type
parameter
template < S > void f () {}
^
small.cpp: In static member function ‘
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71831
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77303
Bug ID: 77303
Summary: std::max_element not constexpr with -D_GLIBCXX_DEBUG
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
--- Comment #18 from vries at gcc dot gnu.org ---
dg-options line was removed on trunk at
https://gcc.gnu.org/viewcvs?rev=237745&root=gcc&view=rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
--- Comment #17 from ncahill_alt at yahoo dot com ---
This was the only test that failed for me, the others were debug info in LTO
mode. I'm very glad that GCC 6.1.0 works so well and built cleanly like it
did.
This test was a minor thing becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #6)
> Yes, that makes sense to me as an explanation of the limitation of the GCC
> implementation and a solution/workaround for it. I don't think it's
> somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71550
--- Comment #4 from Jeffrey A. Law ---
This has gone latent on the trunk, but I'm pretty sure the core issues remain.
Looking deeper into the problem, this may be another case of jump threading
invalidating the cached loop iteration information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77302
Bug ID: 77302
Summary: partial specialization marked as ambiguous
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59319
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77270
--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Aug 19 18:14:03 2016
New Revision: 239626
URL: https://gcc.gnu.org/viewcvs?rev=239626&root=gcc&view=rev
Log:
PR target/77270
* config/i386/i386.c (ix86_option_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77301
--- Comment #2 from Martin Sebor ---
Thanks. As surprising as that seems, it would explain the output of the test
case in comment #0, even though it's not at all obvious from the manual.
But if change the test case like below I get three diffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
--- Comment #16 from ncahill_alt at yahoo dot com ---
(In reply to Richard Biener from comment #15)
> (In reply to ncahill_alt from comment #14)
> > This test is failing for me in GCC 6.1.0 (i386). It complains about having
> > no vectype.
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
--- Comment #12 from joseph at codesourcery dot com ---
You can now use _Complex _Float128. Given that, it's not obvious that
_Complex __float128, with the legacy __float128 type name, should be
supported (although not supporting that means al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
--- Comment #7 from Jakub Jelinek ---
Different warnings are simply done at different compilation phases. This is
similar to how you get only a subset of FE warnings on uninstantiated
templates, only something can be warned reliably at that phas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
--- Comment #11 from Joseph S. Myers ---
Author: jsm28
Date: Fri Aug 19 17:43:26 2016
New Revision: 239625
URL: https://gcc.gnu.org/viewcvs?rev=239625&root=gcc&view=rev
Log:
Implement C _FloatN, _FloatNx types.
ISO/IEC TS 18661-3:2015 defines C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77301
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
--- Comment #6 from Martin Sebor ---
Yes, that makes sense to me as an explanation of the limitation of the GCC
implementation and a solution/workaround for it. I don't think it's something
users unfamiliar with GCC internals think of, though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77301
Bug ID: 77301
Summary: __builtin_object_size incorrect for an array in a
struct referenced by a pointer
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
--- Comment #5 from Jakub Jelinek ---
You can always use -fkeep-inline-functions to get the warning even for unused
inlines (by forcing them to be emitted). -Wnonnull-compare isn't the only
warning that isn't performed in the FEs early, think abo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73714
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup dot
org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #13 from Segher Boessenkool ---
(In reply to Manuel López-Ibáñez from comment #12)
> (In reply to Segher Boessenkool from comment #11)
> > Both of these suggestions are not so good. "!(a == b)" is better written
> > as "a != b", and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300
Bug ID: 77300
Summary: [MIPS] incorrectly moves instruction containing local
GOT16 relocation into a delay slot
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77270
Uroš Bizjak changed:
What|Removed |Added
Keywords|wrong-code |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64082
Joey Ye changed:
What|Removed |Added
CC||joey.ye at arm dot com
--- Comment #1 from Joe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
--- Comment #3 from Martin Sebor ---
I should add that Clang issues the warning for all three functions:
$ /build/llvm-trunk/bin/clang -S -Wall -Wextra -Wpedantic z.C
z.C:2:21: warning: 'this' pointer cannot be null in well-defined C++ code;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77297
--- Comment #2 from Manuel López-Ibáñez ---
*** Bug 77299 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77299
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77297
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Fri Aug 19 15:30:33 2016
New Revision: 239620
URL: https://gcc.gnu.org/viewcvs?rev=239620&root=gcc&view=rev
Log:
PR fortran/71014
* resolve.c (gfc_resolve): For ns->const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72744
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Fri Aug 19 15:28:59 2016
New Revision: 239619
URL: https://gcc.gnu.org/viewcvs?rev=239619&root=gcc&view=rev
Log:
PR fortran/72744
* gfortran.dg/gomp/pr72744.f90: New test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69281
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Fri Aug 19 15:27:40 2016
New Revision: 239618
URL: https://gcc.gnu.org/viewcvs?rev=239618&root=gcc&view=rev
Log:
PR fortran/69281
* trans-openmp.c (gfc_trans_omp_parallel,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77297
Bug ID: 77297
Summary: -Wnonnull-compare not emitted inside ternary operator
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
Bug ID: 77298
Summary: -Wnonnull-compare only emitted for code which is
invoked
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77299
Bug ID: 77299
Summary: No warning for unused "INT64_MAX" and similar
constants
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77296
--- Comment #1 from Thomas Koenig ---
Also fails with 5.4.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77281
--- Comment #2 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Fri Aug 19 13:59:18 2016
New Revision: 239610
URL: https://gcc.gnu.org/viewcvs?rev=239610&root=gcc&view=rev
Log:
[ARM] Fix an invalid check for vectors of the same floating-po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71065
--- Comment #2 from Jakub Jelinek ---
Note that according to the omp-lang discussions
#pragma omp target
{
#pragma omp teams
{
...
}
}
is fine, while even
#pragma omp target
{
{}
#pragma omp teams
{
...
}
}
(or ; etc., before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71065
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77296
Bug ID: 77296
Summary: Compiler Error with allocatable string and associate
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #12 from Manuel López-Ibáñez ---
(In reply to Segher Boessenkool from comment #11)
> Both of these suggestions are not so good. "!(a == b)" is better written
> as "a != b", and "!(a) == b" is just horrible.
Agreed for the former, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35170
Manuel López-Ibáñez changed:
What|Removed |Added
Target|x86_64-unknown-linux-gnu|
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #5)
> int
> foo (int a, int b)
> {
> return !a == (a < b);
> }
>
> t.c: In function ‘foo’:
> t.c:4:13: warning: logical not is only applied to the left hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to M Welinder from comment #3)
> I am not aware of a rule that requires the compiler to ignore context
> when considering warnings. It certainly does consider context when
> it issues "might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #8 from Marek Polacek ---
Neither does cc1plus because comparison result has a boolean type...
I'll see what I can do here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
Richard Biener changed:
What|Removed |Added
Status|SUSPENDED |NEW
Summary|value range prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #6 from Marek Polacek ---
(In reply to Manuel López-Ibáñez from comment #4)
> Note that Clang suggests two ways to silence the warning:
>
> prog.cc:9:10: note: add parentheses after the '!' to evaluate the comparison
> first
> retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70713
Joe Seymour changed:
What|Removed |Added
CC||joe.s+bugzilla@somniumtech.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #5 from Richard Biener ---
(In reply to M Welinder from comment #3)
> The actual code I got this warning from was...
>
> if (!lower_tail == (p > phalf)) {
>
> where lower_tail is an int and p and phalf are doubles.
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #3 from M Welinder ---
The actual code I got this warning from was...
if (!lower_tail == (p > phalf)) {
where lower_tail is an int and p and phalf are doubles.
That's simply a comparison of two booleans. Note, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69789
--- Comment #7 from Jonathan Wakely ---
(In reply to Thomas Markwalder from comment #5)
> A bit more digging reveals that in the logic expression which fails:
>
> {{{
> // Check if we need to run the operation again.
> if (ec == boost::a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69789
Tomek Mrugalski changed:
What|Removed |Added
CC||spam.gcc at klub dot com.pl
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
--- Comment #15 from Richard Biener ---
(In reply to ncahill_alt from comment #14)
> This test is failing for me in GCC 6.1.0 (i386). It complains about having
> no vectype.
>
> Why that is, I don't know. But it doesn't seem to be a problem ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77290
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
Summary|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77290
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77291
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic, wrong-code
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77295
--- Comment #3 from Avi Kivity ---
If x->which is known then of course just that branch should be followed, and
the others eliminated. I'm talking about the case where it isn't known (very
common in my code).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77293
Richard Biener changed:
What|Removed |Added
Depends on||64715
--- Comment #1 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77295
--- Comment #2 from Avi Kivity ---
Typically, the code is a template:
template
struct discriminated_union {
unsigned which;
union {
T v1;
U v2;
};
};
If either T or U have non-trivial copy/move constructors, then y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77295
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77286
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77286
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
83 matches
Mail list logo
