al_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/rtl-error.c:108
0x3177cc9d1e7 rtl_verify_bb_insns
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193
Bug ID: 79193
Summary: libstdc++ configure incorrectly decides linking works
for cross-compiler
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79192
Bug ID: 79192
Summary: Angle bracket following typename is treated as
template argument delimiter even if the name is not a
template name
Product: gcc
Version: 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #24 from Peter Bergner ---
(In reply to Jeffrey A. Law from comment #23)
> Fixed by patches on the trunk.
We only have a fix for the ICE in the first comment. We still do not have a
proper fix for the ICE in Comment 6. Since you've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #12 from Jeffrey A. Law ---
With the v.size() > 0 guard enabled and my VRP tweaks I get no warnings. Plan
is to either polish up the VRP tweaks or turn them into a match.pd pattern.
Not sure which is going to be better yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191
Bug ID: 79191
Summary: potentially truncating unsigned conversion defeats
range propagation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #11 from Martin Sebor ---
I agree that calling v.resize(v.size() - 0) when v.size() is zero is a bug in
the program and diagnosing it should be a good thing (I think that corresponds
to the test case I pasted in comment #2 and what I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #10 from Jeffrey A. Law ---
So with a prototype patch to simplify the overflow checks to zero/not zero, we
still get the one warning. The more I look at the code, the more I think the
warning is justified.
Ponder the case where v.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70800
--- Comment #1 from David Binderman ---
Given the following source code
extern void g(int n);
void f( int n)
{
if ((n & 0x30) == 1)
g( n);
}
Current trunk gcc can't find much wrong:
$ ~/gcc/results/bin/gcc -c -g -O2 -W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #12 from Ville Voutilainen ---
..which is http://cplusplus.github.io/LWG/lwg-active.html#2491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79186
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79187
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #11 from Ville Voutilainen ---
Ah, the plot thickens. Jens Maurer wrote:
"Regarding the std::less issue, it seems a bug in the standard
to require that it be constexpr and deliver a total order. After
all, the addresses of global ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190
--- Comment #4 from Jonathan Wakely ---
(In reply to John David Anglin from comment #2)
> Looks as if the problem is here:
>
> #else
> // The C library doesn't provide any aligned allocation functions, declare
> // aligned_alloc and get a link f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190
--- Comment #3 from John David Anglin ---
(In reply to Jonathan Wakely from comment #1)
> Looks like we do need to create a fall-back implementation after all, as
> Marc suggested in https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00422.html
A wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190
--- Comment #2 from John David Anglin ---
Looks as if the problem is here:
#else
// The C library doesn't provide any aligned allocation functions, declare
// aligned_alloc and get a link failure if aligned new is used.
extern "C" void *aligned_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79182
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190
Bug ID: 79190
Summary: [7 Regression] ld: (Warning) Unsatisfied symbol
"aligned_alloc"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79189
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79184
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79188
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79154
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version|5.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
--- Comment #10 from Arnd Bergmann ---
(In reply to Arnd Bergmann from comment #9)
> "-fsched-pressure" on mips64 helps a lot
> ...
> On arm and aarch64, "-fsched-pressure" has no effect
I realized later that on arm and aarch64, -fsched-pressur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79189
Bug ID: 79189
Summary: Poor code generation when using stateless lambda
instead of normal function
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #9 from Jeffrey A. Law ---
Sigh. I was looking at the wrong dump. We don't need to deal with
ADD_OVERFLOW.
Looking at the real test for this BZ, the guarding block has the right form:
[100.00%]:
_7 = MEM[(unsigned int * *)&v];
_8
-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170122 (experimental) [trunk revision 244756] (GCC)
$
$ gcc-trunk -O2 small.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79154
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Sun Jan 22 19:36:57 2017
New Revision: 244763
URL: https://gcc.gnu.org/viewcvs?rev=244763&root=gcc&view=rev
Log:
PR fortran/79154
* parse.c (matchs, matcho, matchds, match
/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170122 (experimental) [trunk revision
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170122 (experimental
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
--- Comment #4 from Zaak ---
Fabulous, I'll verify soon (for my own satisfaction)
On Sun, Jan 22, 2017 at 12:31 PM vehre at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
>
> vehre at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77622
Yuri Gribov changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #8 from Martin Sebor ---
(In reply to Jeffrey A. Law from comment #4)
> So the simplified tests are interesting, but ultimately too simplified.
You're right, the test case in comment #2 is oversimplified. The one in the
thread on gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66836
--- Comment #2 from Jonathan Wakely ---
To clarify what I mean, consider:
struct X {
void f();
void g() {
void f();
f();
}
};
The declaration of void f() inside X::g doesn't refer to X::f, because it
declares a (non-member) functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66836
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185
Bug ID: 79185
Summary: Possible regression in gcc 4.9 and later with the
addition of two 128 bit ints
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
--- Comment #1 from Frederic Marchal ---
Yet another hard coded plural in the same file at line 2286:
inform (callloc,
(nbytes + exact == 1
? G_("format output %wu byte into a destination of size %wu")
: G_("format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79184
Bug ID: 79184
Summary: -Wint-in-bool-context triggered erroneously in
template parameter
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
Bug ID: 79183
Summary: Hard coded plurals in gimple-ssa-sprintf.c:2050
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
Ville Voutilainen changed:
What|Removed |Added
Known to work||4.5.4
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79178
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61580
Jonathan Wakely changed:
What|Removed |Added
CC||keith.marshall at mailinator
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79182
--- Comment #1 from hwliu11 at hotmail dot com ---
My platform Unbuntu 16.06 LTS 64Bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79182
Bug ID: 79182
Summary: when use openmp and link static libgfortran,open
function cause SIGSEGV
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #7 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> VRP already handles that,
Nice :-) Thanks and sorry for not checking myself.
> IFN_*_OVERFLOW can appear already during gimplification if
> __builtin_*_overflow{,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #6 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #5)
> I thought ADD_OVERFLOW would appear in the widening_mul pass, i.e. after all
> the VRP passes are done? On the other hand, teaching VRP about *_OVERFLOW
> sounds li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #5 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #4)
> So the simplified tests are interesting, but ultimately too simplified. The
> VRP prototype which works on the simplified testcases doesn't work on the
> real tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79177
Alexander Kjäll changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79176
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||lto
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79181
Bug ID: 79181
Summary: Not deleting /tmp/cc*
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: una
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79180
--- Comment #1 from Markus Dreseler ---
P.S.: Also experienced on Wandbox's GCC 7.0.1 HEAD.
Not passing the parameter pack into bar by universal reference causes an
internal compiler error in gcc 7.0.1 HEAD:
prog.cc: In function 'void b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #4 from Jeffrey A. Law ---
So the simplified tests are interesting, but ultimately too simplified. The
VRP prototype which works on the simplified testcases doesn't work on the real
testcase for this BZ.
The key sequences look like:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79180
Bug ID: 79180
Summary: Nested lambda-capture causes segfault for parameter
pack
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
62 matches
Mail list logo
