--- Comment #20 from irar at il dot ibm dot com 2009-11-30 08:52 ---
Actually, PAREN_EXPRs are vectorizable (the support was added by you, Richard,
in your original PAREN_EXPR patch
http://gcc.gnu.org/viewcvs?limit_changes=0&view=revision&revision=132515 )).
The problem here is that vec
--- Comment #6 from paolo dot carlini at oracle dot com 2009-11-30 08:53
---
Jason, can we close this one as duplicate of PR38712 ?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #21 from irar at il dot ibm dot com 2009-11-30 08:54 ---
Created an attachment (id=19183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19183&action=view)
Multiple types support patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
Compile the attached test case with options -Os -mthumb, gcc generates:
add r1, r1, #40
mov r3, r0
ldrbr2, [r1]
add r3, r3, #40
strbr2, [r3]
@ sp needed for prologue
bx lr
When change the options to -O2 -mthumb, gcc
--- Comment #1 from carrot at google dot com 2009-11-30 08:56 ---
Created an attachment (id=19184)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19184&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42226
--- Comment #2 from jagjeet dot nain at gmail dot com 2009-11-30 09:57
---
Will -fcx-limited-range or -fcx-fortran-rules change the results compared to
compiled with 4.0.2 without these flags ?
Or in otherwords, A complex division program compiled with and without
-fcx-limited-range fl
--- Comment #2 from rguenther at suse dot de 2009-11-30 09:58 ---
Subject: Re: [4.5 Regression] 464.h265ref peak
regressed 20%
On Sun, 29 Nov 2009, rth at gcc dot gnu dot org wrote:
> --- Comment #1 from rth at gcc dot gnu dot org 2009-11-29 17:58 ---
> The vec_interleave_*_
s->__sglue._niobs = 3;
s->__sglue._iobs = &s->__sf[0];
# 209 "../../../.././newlib/libc/stdio/findfp.c"
std (s->_stdin, 0x0004, 0, s);
# 220 "../../../.././newlib/libc/stdio/findfp.c"
std (s->_stdout, 0x0008 | 0x0001, 1, s);
this C language (newlib/stdio/findfp.c) code generate following the
--- Comment #5 from dodji at gcc dot gnu dot org 2009-11-30 09:58 ---
Subject: Bug 42069
Author: dodji
Date: Mon Nov 30 09:58:20 2009
New Revision: 154768
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154768
Log:
Fix PR c++/42069
gcc/cp/ChangeLog:
PR c++/42069
--- Comment #6 from hubicka at ucw dot cz 2009-11-30 09:59 ---
Subject: Re: missed optimization leads to several times slower code
> Digression: this suggests an attribute such as "inline_if_reduces" which
> inlines if the inlined (callee) code is simplified, but otherwise keeps it out
--- Comment #1 from t_yokota at monami-software dot com 2009-11-30 10:00
---
Created an attachment (id=19185)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19185&action=view)
i, S and rtl output files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42227
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-30 10:02 ---
Err - well. I can certainly paper over the problem by ignoring
error_mark_node,
but ... why does the bogus type survive until gimplification?
Thus,
>
QI
size constant 8>
unit size constant 1>
al
I just tried to compile package libcrypto++ with the GNU C++ compiler
version 4.5 snapshot 20091126 and the compiler said
validat2.cpp: At global scope:
validat2.cpp:764:1: error: node has wrong clone_of
validat2.cpp:764:1: error: double linked list of clones corrupted
CryptoPP::DL_FixedBasePrecom
--- Comment #1 from dcb314 at hotmail dot com 2009-11-30 10:06 ---
Created an attachment (id=19186)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19186&action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42228
--- Comment #21 from rguenther at suse dot de 2009-11-30 10:10 ---
Subject: Re: Weird translation of DO loops
On Mon, 30 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
> --- Comment #20 from tkoenig at gcc dot gnu dot org 2009-11-30 07:31
> ---
> Created an attachment (id=1
--- Comment #22 from rguenther at suse dot de 2009-11-30 10:13 ---
Subject: Re: [4.4/4.5 Regression] Vectorizer
cannot deal with PAREN_EXPR gracefully, 50% performance regression
On Mon, 30 Nov 2009, irar at il dot ibm dot com wrote:
> --- Comment #20 from irar at il dot ibm dot
--- Comment #6 from dodji at gcc dot gnu dot org 2009-11-30 10:15 ---
Fixed in 4.5.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
I just tried to compile package libgeos_c1-3.1.1 with the GNU C++ compiler
version 4.5 snapshot 20091126 and the compiler said
AbstractSTRtree.cpp: In member function 'geos::index::strtree::ItemsList*
geos::index::strtree::AbstractSTRtree::itemsTree(geos::index::strtree::AbstractNode*)':
AbstractS
--- Comment #1 from dcb314 at hotmail dot com 2009-11-30 10:23 ---
Created an attachment (id=19187)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19187&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42229
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-30 10:26 ---
Uli, this is your code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-30 10:26 ---
THus fixed in 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-30 10:27
---
Today (r154772), I can't reproduce the issue anymore. Volker, can you double
check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42057
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-30 10:32 ---
With checking enabled I get
> g++-4.5 -S -o /dev/null product_small.ii -B /abuild/rguenther/trunk-g/gcc
In file included from /home/bjacob/eigen/test/product_small.cpp:26:0:
/home/bjacob/eigen/test/product.h: In fun
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-30 10:33 ---
I suspect it's rtx costs messed up if asked for speed vs. size metrics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42226
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-11-30 10:36 ---
What a stupid oversight, I'll prepare a patch straight away.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-30 10:38 ---
(In reply to comment #2)
> The issue is pretty simple, actually: std::unique_future (which, by the way,
> will be renamed just std::future), is missing move assignment operator. Note,
> in N2914 it does *not* exist, has
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-30 10:39 ---
Subject: Bug 42119
Author: rguenth
Date: Mon Nov 30 10:39:36 2009
New Revision: 154778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154778
Log:
2009-11-30 Richard Guenther
PR middle-end/42119
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-30 10:39 ---
Subject: Bug 38530
Author: rguenth
Date: Mon Nov 30 10:39:36 2009
New Revision: 154778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154778
Log:
2009-11-30 Richard Guenther
PR middle-end/42119
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-30 10:40 ---
Fixed for 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-30 10:41 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from hjl dot tools at gmail dot com 2009-11-30 10:54 ---
This may be related to revision 154688, which has caused PR 42202.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #21 from dcb314 at hotmail dot com 2009-11-30 11:30 ---
(In reply to comment #18)
> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01392.html
I tried out your patch on a recent Linux kernel and got
some possibly false positives
Code like
static inline pud_t __pud(pudval_t va
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-30 11:32 ---
Confirmed. remove_path doesn't honor the fact that cancel_loop_tree removes
all sub-loops, so the work list may contain already removed loops.
--
rguenth at gcc dot gnu dot org changed:
What|Remo
--- Comment #23 from irar at il dot ibm dot com 2009-11-30 12:20 ---
Applied:
http://gcc.gnu.org/viewcvs?limit_changes=0&view=revision&revision=154794
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-11-30 12:36
---
Fixed by Honza.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-30 13:11 ---
I believe this was fixed with
2009-07-22 Michael Matz
PR tree-optimization/35229
PR tree-optimization/39300
* tree-ssa-pre.c (includes): Include tree-scalar-evolution.h.
(inhibit
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-11-30 13:14
---
ppc folks, can you re-confirm this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #22 from jakub at gcc dot gnu dot org 2009-11-30 13:56 ---
In that case you weren't using the latest version of the patch.
Please try http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01582.html
instead, it should fix several important bugs and initializers of compound
literals ar
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-30 14:02
---
The ICE part is fixed by my patch for PR34272.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42062
When calling abi::__cxa_demangle("e", 0, &length, &cc) length is not updated
but the documentation indicates that it should be set to the length of the
demangled name.
It seems that this change was introduced after 3.4.6
--
Summary: abi::__cxa_demangle fails to return the length of t
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-30 14:07
---
The second part seems to me essentially a duplicate of PR28300.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42062
Bug reproduced with GCC 4.4.2 and GCC 4.4.1, on x86_64.
The following simple test program should succeed (EXIT_SUCCESS return code from
main()), but fails with GCC 4.4.2 when compiling with -O3.
The program succeed with "-O2", _AND_ "-O2 -finline-functions -funswitch-loops
-fpredictive-commoning
--- Comment #1 from roche+gccbugs at exalead dot com 2009-11-30 14:29
---
Created an attachment (id=19188)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19188&action=view)
The test program (exit code is meaningful)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42231
--- Comment #2 from roche+gccbugs at exalead dot com 2009-11-30 14:38
---
Created an attachment (id=19189)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19189&action=view)
The preprocessor version
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42231
--- Comment #3 from roche+gccbugs at exalead dot com 2009-11-30 14:38
---
Created an attachment (id=19190)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19190&action=view)
The assembly source version
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42231
--- Comment #4 from olga at gcc dot gnu dot org 2009-11-30 14:43 ---
Subject: Bug 39806
Author: olga
Date: Mon Nov 30 14:42:54 2009
New Revision: 154811
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154811
Log:
2009-11-30 Olga Golovanevsky
PR middle-end/39806
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-30 14:46 ---
Confirmed. Works with 4.5 and with -fno-ipa-cp.
IPA lattices after propagation:
Lattice:
Node: main:
Node: callback:
param [0]: type is CONST 0
which is obviously wrong. On trunk the same propagation res
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.4.3 |4.4.0 4.4.3
Priority|P3 |P2
http
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-11-30 15:05
---
The issue with the boolean_type_node is that the middle-end does not have
a type for a comparison result but implicitly assumes boolean_type_node.
So for
D._16 = (boolean) D._6;
if (D._16 != 0)
w
--- Comment #5 from roche+gccbugs at exalead dot com 2009-11-30 15:06
---
Just a small note: also work with "just" -fno-ipa-cp-clone in O3 mode,
actually. Therefore the issue is probably related to the "Perform function
cloning to make interprocedural constant propagation stronger" feat
--- Comment #3 from uweigand at gcc dot gnu dot org 2009-11-30 15:17
---
OK, I've reproduced the problem. It seems int_or_pointer_precision
is fundamentally wrong for pointers using a non-standard size
(i.e. pointer variables defined using a mode attribute).
The history of this is tha
--- Comment #10 from vlad at demoninsight dot com 2009-11-30 15:19 ---
So, using 4.5 trunk works around this issue... But ouch: 4.5 is almost 2x
slower than 4.4...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-11-30 15:27
---
Slower in runtime or in compile-time?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-30 15:29
---
Ian, can you have a look to this issue? Thanks in advance.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-11-30 15:46 ---
Subject: Bug 42206
Author: jamborm
Date: Mon Nov 30 15:46:00 2009
New Revision: 154820
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154820
Log:
2009-11-30 Martin Jambor
PR middle-end/42206
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-11-30 15:58 ---
The variable is initialized now. Thanks for pointing it out.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from vlad at demoninsight dot com 2009-11-30 16:07 ---
(In reply to comment #11)
> Slower in runtime or in compile-time?
>
Compile-time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
> g++-4.4 -S -m32 bug-559091_solver_main_pre_omp.3.cpp -fopenmp
bug-559091_solver_main_pre_omp.3.cpp: In member function void
LbmFsgrSolver::mainLoop(int):
bug-559091_solver_main_pre_omp.3.cpp:121: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed sour
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-30 16:26 ---
Created an attachment (id=19191)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19191&action=view)
reduced testcase
Reduced testcase from https://bugzilla.novell.com/show_bug.cgi?id=559091.
(gdb) bt
#0 0x
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.3
Known to work||4.3.4 4.5.0
The following c/++ code generates assembly that favors the unlikely case with
gcc 4.3 and 4.4:
extern void likely();
extern void unlikely();
void test_expect(char * a, char *b, char *c, char *d) {
if (__builtin_expect(!!(a == b && c == d), 1)) {
likely();
}
else {
unlike
--- Comment #13 from redi at gcc dot gnu dot org 2009-11-30 16:46 ---
(In reply to comment #12)
> Compile-time.
configure with --enable-checking=release to turn off checks that are enabled by
default in pre-release builds, that will give a better comparison between the
4.4.2 release and
--- Comment #5 from spop at gcc dot gnu dot org 2009-11-30 16:59 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from spop at gcc dot gnu dot org 2009-11-30 17:00 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from gmorin1 at bloomberg dot net 2009-11-30 17:00 ---
I can see this problem with 4.3.2 (Debian 4.3.2-1.1), 4.2.4 (Debian 4.2.4-6),
4.4.0 20090514 (Red Hat 4.4.0-6). I do not see it with 4.1.2 20080704 (Red Hat
4.1.2-46) and 4.1.3 20080704 (prerelease) (Debian 4.1.2-25).
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-11-30 17:29 ---
With 4.5 we seem to be all fine here:
j...@gcc17:~/trunk/build/gcc$ ./g++ -B ./ -O2 tt.c -fdump-tree-all-details -S
-fdump-rtl-all-details-blocks
j...@gcc17:~/trunk/build/gcc$ more tt.s
.file "tt.c"
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-11-30 18:00 ---
Subject: Bug 42196
Author: jamborm
Date: Mon Nov 30 17:59:57 2009
New Revision: 154834
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154834
Log:
2009-11-30 Martin Jambor
PR middle-end/42196
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-11-30 18:16 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-30 18:41
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01729.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40371
--- Comment #2 from janis at gcc dot gnu dot org 2009-11-30 19:15 ---
Subject: Bug 42212
Author: janis
Date: Mon Nov 30 19:14:58 2009
New Revision: 154837
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154837
Log:
PR testsuite/42212
* gcc.target/powerpc/regnames-
--- Comment #22 from tkoenig at gcc dot gnu dot org 2009-11-30 19:15
---
(In reply to comment #21)
> the "sign" for unsigned steps is always 1, you don't seem to account
> for unsignedness?
(Un)fortunately, there are no unsigned varaibles in Fortran.
> Note that I believe generating
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2009-11-30 20:19
---
Thomas, Ido not have email access at the moment.
I reviewed your patch and it is approved for trunk.
Thanks for the work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
--- Comment #24 from tkoenig at gcc dot gnu dot org 2009-11-30 20:35
---
Subject: Bug 42131
Author: tkoenig
Date: Mon Nov 30 20:35:41 2009
New Revision: 154839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154839
Log:
2009-11-30 Thomas Koenig
PR fortran/42131
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-30 20:43 ---
Subject: Bug 42053
Author: janus
Date: Mon Nov 30 20:43:06 2009
New Revision: 154840
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154840
Log:
merge from fortran-dev branch:
gcc/fortran/
2009-11-30 Janus
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-30 20:43 ---
Subject: Bug 41631
Author: janus
Date: Mon Nov 30 20:43:06 2009
New Revision: 154840
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154840
Log:
merge from fortran-dev branch:
gcc/fortran/
2009-11-30 Janus
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-30 20:46 ---
Or vice versa, I like this testcase better :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
--- Comment #25 from tkoenig at gcc dot gnu dot org 2009-11-30 21:01
---
Fixed on trunk. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-30 21:24 ---
Fixed on trunk with r154840.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42053
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-30 21:25 ---
Fixed on trunk with r154840.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from pthaugen at gcc dot gnu dot org 2009-11-30 21:29
---
I am still seeing the 2-block loop using revision 154838, both 32 and 64 bit,
compile options -O3 -mcpu=power6 -funroll-loops.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #3 from gmorin1 at bloomberg dot net 2009-11-30 22:06 ---
The trunk g++ output looks good. As I said, there is a simple workaround. But
since this is a regression from 4.1, a fix in 4.4 would be nice.
Additionally, it would be great if you could document the full scope of t
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2009-11-30 22:08
---
> The issue with the boolean_type_node is that the middle-end does not have
> a type for a comparison result but implicitly assumes boolean_type_node.
>
> So for
>
> D._16 = (boolean) D._6;
> if (D.
--- Comment #6 from grosser at gcc dot gnu dot org 2009-11-30 22:08 ---
Subject: Bug 42130
Author: grosser
Date: Mon Nov 30 22:07:59 2009
New Revision: 154849
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154849
Log:
Protect loops that might be executed zero times.
2009-11-23
--- Comment #3 from sje at cup dot hp dot com 2009-11-30 22:10 ---
Fixed in r154843, test case added in gcc.dg/pr41551.c.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2009-11-30 22:21 ---
Fixed
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-11-30 22:22 ---
The lattices are OK per se. Lattices really only represent arguments
of calls that are represented in the call graph. When there might be
other calls that are not represented in the graph, the function body
is clon
--- Comment #2 from dodji at gcc dot gnu dot org 2009-11-30 22:39 ---
Submitted a patch to http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01767.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42217
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-30 22:41
---
*** This bug has been marked as a duplicate of 38600 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #8 from paolo dot carlini at oracle dot com 2009-11-30 22:41
---
*** Bug 38712 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from sje at cup dot hp dot com 2009-11-30 22:41 ---
Fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC|jason at gcc dot gnu dot org|
AssignedTo|unassigned at gcc dot gnu |jason at gcc do
--- Comment #3 from paolo at gcc dot gnu dot org 2009-11-30 22:45 ---
Subject: Bug 40371
Author: paolo
Date: Mon Nov 30 22:45:06 2009
New Revision: 154852
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154852
Log:
cp/
2009-11-30 Paolo Carlini
PR c++/40371
* c
--- Comment #4 from paolo dot carlini at oracle dot com 2009-11-30 22:46
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
CC|dodji at gcc dot gnu dot org|
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu d
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-30 23:03 ---
(In reply to comment #0)
> This gives
>
> undefined reference to `create_interface_'
>
> when linking. 'create_interface' is the abstract interface of the deferred
> TBP.
> Instead of calling this, one should do the
--- Comment #5 from dje at gcc dot gnu dot org 2009-11-30 23:34 ---
Subject: Bug 35484
Author: dje
Date: Mon Nov 30 23:34:33 2009
New Revision: 154855
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154855
Log:
2009-11-30 David Edelsohn
PR target/35484
* src/p
--- Comment #3 from dodji at gcc dot gnu dot org 2009-12-01 00:26 ---
A reduced test case seems to be:
~=~
template
struct A
{
typedef T I;
};
template
struct B
{
typedef T TT;
typedef typename TT::I TT_I;
typedef A TA;
};
template
void
foo()
{
typedef T TT
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-01 00:27 ---
It is caused by revision 145440:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
1 - 100 of 113 matches
Mail list logo
