https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
Bug ID: 70018
Summary: Possible issue around IPO and C++ inline functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
--- Comment #4 from Jakub Jelinek ---
The problem I see e.g. in aarch64 or rs6000 is that it in some cases uses
NULL_TREE for old_tree or new_tree, and in that case doesn't change anything.
But in reality, not changing anything if old_tree != new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
--- Comment #5 from Jakub Jelinek ---
See e.g. PR61925.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
--- Comment #2 from Andrew Pinski ---
Also one more point, in this example both inline functions have the same
definition. Both answers are valid answers for this case. That is doing the
division (causing the trap on x86_64) don't have to happe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #5 from Jeffrey A. Law ---
It's widely known that that node splitting can turn an irreducible loop into a
reducible loop. And that's precisely what's happening here. Sigh.
Something tells me that long term we may want some degree o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
--- Comment #3 from Sanjoy Das ---
(In reply to Andrew Pinski from comment #1)
> In C++ code, the one definition rule says that all TU that contains an
> inline function, they need to have the same definition. If they have
> different definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
--- Comment #4 from Sanjoy Das ---
(In reply to Andrew Pinski from comment #2)
> So in summary what you are seeing is two effects going into effect here:
> undefined behavior of division by 0 and ODR.
There is no division by zero (or any other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
--- Comment #5 from marc at kdab dot com ---
You have a very narrow test of NRVO.
You're using a completely transparent type, though I give you that defining the
copy and move ctors in a separate TU does not change the outcome. At some point
I'l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
--- Comment #6 from Sanjoy Das ---
(In reply to Andrew Pinski from comment #5)
> Oh I see pure/const behavior.
>
> The problem is more complex, in that in one TU, the comdat function is
> figured out to be pure/const so we remove the store befor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #9 from Edmar Wienskoski ---
Ok. Thanks for the clarification.
The comparison is made with an unsigned variable, but gcc
is certain that this variable cannot have (legally) a value that
cannot be represented in an int.
That is why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69988
--- Comment #6 from John Paul Adrian Glaubitz ---
(In reply to Andreas Schwab from comment #5)
> The gccgo commandline uses -static-libgcc. Make sure that -lgcc is linked
> after libgo.
Shouldn't it be -lc since the symbols in question are now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69989
--- Comment #11 from Jeffrey A. Law ---
The last proposal (clear LOOPS_NEED_FIXUP) is a possibility. I can poke at
that a bit, but I really wonder if it'd be better for gcc-7 and for gcc-6 if we
should just use localized fixups rather than tryin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69988
--- Comment #7 from joseph at codesourcery dot com ---
libgo.so should have been linked with -lc (probably an implicit -lc from
some spec used when linking shared libraries).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69988
--- Comment #8 from John Paul Adrian Glaubitz ---
(In reply to jos...@codesourcery.com from comment #7)
> libgo.so should have been linked with -lc (probably an implicit -lc from
> some spec used when linking shared libraries).
Can you suggest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46459
--- Comment #7 from Harald Anlauf ---
The patch of comment #1 (adjusted to current trunk) regtests cleanly
for me.
(In reply to Mikael Morin from comment #5)
> The initial test doesn't lead to a segfault any more.
>
> It is now rejected with:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #6 from Jeffrey A. Law ---
Author: law
Date: Mon Feb 29 22:45:41 2016
New Revision: 233824
URL: https://gcc.gnu.org/viewcvs?rev=233824&root=gcc&view=rev
Log:
PR tree-optimization/6
* gimple-ssa-split-paths.c (spli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70005
--- Comment #2 from Jeffrey A. Law ---
Thanks. Something unexpected slipped through the IL confusing uncprop. So
there's really two issues here. Why did an always-true/always-false test
manage to survive until uncprop, a missed optimization, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70005
--- Comment #3 from Jeffrey A. Law ---
Author: law
Date: Tue Mar 1 00:04:48 2016
New Revision: 233829
URL: https://gcc.gnu.org/viewcvs?rev=233829&root=gcc&view=rev
Log:
PR tree-optimization/70005
* tree-ssa-uncprop.c (associate_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706
--- Comment #11 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Mar 1 00:22:26 2016
New Revision: 233833
URL: https://gcc.gnu.org/viewcvs?rev=233833&root=gcc&view=rev
Log:
PR target/69706
* config/sparc/sparc.c (NWORDS_UP): R
: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160229 (experimental) [trunk revision 233802] (GCC)
$:
$: gcc-trunk -O2 -fgraphite-identity small.c
small.c: In function ‘main’:
small.c:3:5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #21 from David Malcolm ---
Author: dmalcolm
Date: Tue Mar 1 01:02:49 2016
New Revision: 233836
URL: https://gcc.gnu.org/viewcvs?rev=233836&root=gcc&view=rev
Log:
PR preprocessor/69985: fix ICE with long lines in -Wformat
gcc/testsu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69961
--- Comment #3 from Patrick Palka ---
Author: ppalka
Date: Tue Mar 1 01:24:44 2016
New Revision: 233838
URL: https://gcc.gnu.org/viewcvs?rev=233838&root=gcc&view=rev
Log:
Fix PR c++/69961 (invalid ctor call with dependent args)
gcc/cp/ChangeLo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948
--- Comment #16 from Patrick Palka ---
Author: ppalka
Date: Tue Mar 1 01:24:44 2016
New Revision: 233838
URL: https://gcc.gnu.org/viewcvs?rev=233838&root=gcc&view=rev
Log:
Fix PR c++/69961 (invalid ctor call with dependent args)
gcc/cp/ChangeL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69961
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70019
Bug ID: 70019
Summary: VLA size overflow not detected
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70019
Martin Sebor changed:
What|Removed |Added
Keywords||wrong-code
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
Bill Seurer changed:
What|Removed |Added
CC||seurer at linux dot
vnet.ibm.com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67813
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
--- Comment #14 from Martin Sebor ---
(In reply to Andrew Pinski from comment #12)
Thank your for catching it. I did actually read all the comments. The trouble
is that there are several test cases here and I missed the one in the second
half
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Tue Mar 1 04:14:15 2016
New Revision: 233840
URL: https://gcc.gnu.org/viewcvs?rev=233840&root=gcc&view=rev
Log:
2016-02-29 Bill Schmidt
PR target/70011
* gcc.dg/vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009
--- Comment #3 from cesar at gcc dot gnu.org ---
Thanks for the info. I'm travelling this week, so I won't have a chance to look
at this until next Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70020
Bug ID: 70020
Summary: Forward propagation leaves compile-time computable
conditional in IL
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70005
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
trunk/mpfr-3.1.3/bin
--with-mpc=/gcc-trunk/mpc-1.0.3/bin --prefix=/gcc-trunk/bin
Thread model: posix
gcc version 6.0.0 20160229 (experimental) (Revision=233809)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70022
Bug ID: 70022
Summary: [4.9/5/6 Regression] ICE: in tree_to_shwi, at
tree.c:7328 with out-of-bounds vector index
Product: gcc
Version: 6.0
Status: UNCONFIRMED
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
Dominik Vogt changed:
What|Removed |Added
Summary|Ada: c52103x test failure |c52103x and c52104x test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69824
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70023
Bug ID: 70023
Summary: [4.9/5/6 Regression] ICE: in assign_by_spills, at
lra-assigns.c:1417 with
-fno-sched-critical-path-heuristic -fschedule-insns
-m8bit-idiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #12 from john.frankish at outlook dot com ---
Is there any hope of a patch to fix this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
101 - 148 of 148 matches
Mail list logo
