--- Comment #4 from monaka at monami-software dot com 2010-01-30 07:01
---
The insn that causes the issue is emitted at except.c:1163
At the first point, we really need to external setjmp?
There is reason why we shouldn't use __internal_setjmp in stormy16.h. But I
can't figure out what
--- Comment #7 from aanisimov at inbox dot ru 2010-01-30 05:24 ---
(In reply to comment #6)
> > in my opinion, it's necessary that the build scripts
> > specify all library directories explicitely.
>
> Then use configure options --with-ppl / --with-ppl-include / --with-ppl-lib,
> and --
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-01-30 05:20 ---
Subject: Bug 42843
Author: amylaar
Date: Sat Jan 30 05:20:40 2010
New Revision: 156380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156380
Log:
gcc:
PR testsuite/42843
* Makefile.in (HOST_P
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-01-30 05:08 ---
Subject: Bug 42798
Author: amylaar
Date: Sat Jan 30 05:08:11 2010
New Revision: 156379
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156379
Log:
include:
PR bootstrap/42798
* libiberty.h: Ch
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-01-30
03:13 ---
(In reply to comment #1)
Sorry, it should be pr42905.cc, not 1.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42905
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||d
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-30
03:08 ---
Created an attachment (id=19758)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19758&action=view)
Testcase
g++ -O -Wuninitialized -S 1.cc
Older g++s issue a warning:
pr42905.cc: In function âvoid
--
Summary: G++ 4.5.0 doesn't warn about an uninitialized class
member
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-30
02:21 ---
Created an attachment (id=19757)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19757&action=view)
Testcase
Produces "undefined reference to `_foo'" error.
--
http://gcc.gnu.org/bugzilla/show_bug.
--
Summary: Attribute dllexport should imply externally_visible
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #5 from jingyu at google dot com 2010-01-30 00:21 ---
>So the problem is really if (optimize_loop_for_size_p (loop)) . I think you
>need to figure out why that is returning true.
That's because after unswitch-loop, one copy of the loop becomes cold. Let's
look at loop.cpp.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-30 00:05 ---
(In reply to comment #3)
> You must set "--param max-unswitch-level=0" to trigger the bug in non-FDO use.
>
So the problem is really if (optimize_loop_for_size_p (loop)) . I think you
need to figure out why that i
--- Comment #18 from anlauf at gmx dot de 2010-01-30 00:01 ---
(In reply to comment #17)
> I tried this one and compared it to the semi-solution in comment #9.
> Both "work for me", but the patch from comment #16 appears to produce
> a significant performance regression for my code of t
--- Comment #3 from jingyu at google dot com 2010-01-29 23:59 ---
You must set "--param max-unswitch-level=0" to trigger the bug in non-FDO use.
I just tried gcc-4.2.4 on X86 platform. The problem exists.
$ gcc loop.cpp -O3 --param max-unswitch-level=0 -m32 -S
testl %eax, %e
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-01-29
23:50 ---
Compare-debug should probably strip .gnu.lto_* sections before compare.
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-29
23:48 ---
Created an attachment (id=19756)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19756&action=view)
Preprocessed source
$ gcc -flto c-lang.c -c -o stage3-c-lang.o
$ gcc -flto -gtoggle c-lang.c -c -o sta
--
Summary: Compare-debug fails on files compiled with -flto
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
Rep
--- Comment #6 from d dot g dot gorbachev at gmail dot com 2010-01-29
23:42 ---
> in my opinion, it's necessary that the build scripts
> specify all library directories explicitely.
Then use configure options --with-ppl / --with-ppl-include / --with-ppl-lib,
and --with-cloog / --with-c
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-01-29 23:38 ---
On x86, the empty loop is removed at -O3 on the tree level:
:
if (obj_7(D) != 0B)
goto ;
else
goto ;
:
# i_18 = PHI <0(3), i_20(4)>
# s_23 = PHI <0(3), s_2(4)>
obj.0_8 = (int) obj_7(D);
D.2053_25
--- Comment #1 from jingyu at google dot com 2010-01-29 23:33 ---
The problem also exists on non-FDO use. So I changed the title of the bug.
Since unswitch-loop is set at -O3, I give -O3 to the command line. Parameter
"max-unswitch-level" means we only do unswitch-loop at most once.
$a
--- Comment #17 from anlauf at gmx dot de 2010-01-29 23:32 ---
(In reply to comment #16)
> Created an attachment (id=19754)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19754&action=view) [edit]
> patch
>
> Here is an updated patch which fixes the test case in the last comment an
--- Comment #2 from ramana at gcc dot gnu dot org 2010-01-29 23:32 ---
(In reply to comment #1)
> Could be done in a peephole if there's a scratch available for the
> destination.
>
We already do this for Thumb1 don't we ? Turning on *tlobits_cbranch and the
appropriate bit in arm.c s
ded for prologue
pop {r4, pc}
.size test, .-test
.ident "GCC: (GNU) 4.5.0 20100129 (experimental) [trunk revision
156352]"
I have a really bad hack that makes loop-invariant look at addresses inside
MEMs (attached).
(Looking at Zdenek:) Would something li
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Known to fail||4.4.2 4.3.4
--- Comment #6 from carrot at google dot com 2010-01-29 22:47 ---
I tried to change the register order in REG_ALLOC_ORDER, moved ip and lr after
r4/r5/r6/r7, but I still got the same result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42895
--- Comment #22 from steven at gcc dot gnu dot org 2010-01-29 22:46 ---
FWIW: with the patch of comment #21 compile time goes down by a factor 10 and
memory tops out at 107MB with the same x86_64 X armv5tejl-unknown-linux-gnueabi
compiler as yesterday (but this time patched).
--
stev
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-29 22:42 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42898
--- Comment #16 from janus at gcc dot gnu dot org 2010-01-29 22:41 ---
Created an attachment (id=19754)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19754&action=view)
patch
Here is an updated patch which fixes the test case in the last comment and the
original problem.
--
h
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-29 22:41 ---
Yep:
f2 ()
{
volatile struct hardware * ptr;
struct hardware set;
ptr = 287454020B;
set = {};
set.parm1 = 42;
set.parm2 = -3;
set.parm3 = 11850;
set.parm4 = -1;
*ptr = set;
}
f1 ()
{
volatile s
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-29 22:37 ---
(In reply to comment #6)
> I think the issue here is more that we should look for a way to optimize this
> early on. I'm guessing it's one of the ce[123] passes that cleans this up for
> you on your RISCy machine? IM
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-29 22:35 ---
I'd say add a comment to the testcase and WONTFIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42900
--- Comment #19 from pinskia at gcc dot gnu dot org 2010-01-29 22:32
---
*** Bug 42902 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-29 22:32 ---
*** This bug has been marked as a duplicate of 39959 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
gcc.dg/pr34668-1.c FAILs on x86_64-unknown-linux-gnu
(e.g. gcc{11,13,16}.fsffrance.org).
--
Summary: gcc.dg/pr34668-1.c FAILs on x86_64-unknown-linux-gnu
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
S
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-01-29 22:27
---
I will have a look at this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from vmakarov at redhat dot com 2010-01-29 21:54 ---
Thanks everyone who works on the bug.
I am sorry that the bug was really introduced by my patch more accurately by
the part which should fix reload crashes when the 1st scheduling works for some
targets. The patch c
Reading a namelist that contains a variable that is an array of structures
fails. Whatever the index of the array element, the values that are read are
assigned to the first array element.
Below a more or less minimal example:
PROGRAM test_nml
! Start declarations
! Struct with one m
--- Comment #40 from hubicka at ucw dot cz 2010-01-29 20:54 ---
Subject: Re: [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function
> But it miscompares. Honza?!
Patch seems sane to me, so I guess it was other bootstrap issue.
I was actually working on similar fix yesterday ju
--- Comment #10 from vmakarov at redhat dot com 2010-01-29 20:33 ---
Jeff, I saw analogous problem when I worked on improving IRA performance. I
checked the approach you are proposing. But it works considerably worse on
SPEC2000. Finally, I found that the best conflicting cost techniq
--- Comment #20 from amylaar at gcc dot gnu dot org 2010-01-29 20:33
---
Subject: Bug 38785
Author: amylaar
Date: Fri Jan 29 20:33:19 2010
New Revision: 156365
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156365
Log:
PR tree-optimization/38785
2009-02-02 J"orn Rennecke
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-01-29 20:19 ---
(In reply to comment #6)
> I think the issue here is more that we should look for a way to optimize this
> early on. I'm guessing it's one of the ce[123] passes that cleans this up for
> you on your RISCy machine? IM
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-29 20:17 ---
I think the issue here is more that we should look for a way to optimize this
early on. I'm guessing it's one of the ce[123] passes that cleans this up for
you on your RISCy machine? IMHO it would be better even in yo
I've noticed that all the gfortran.dg/stat_[12].f90 fail for me on all
platforms
(i.e. sparc-sun-solaris2, alpha-dec-osf, mips-sgi-irix).
FAIL: gfortran.dg/stat_1.f90 -O0 execution test
at all optimization levels. Running it under gdb reveals that it aborts here:
#4 0x000110f0 in MAIN__ ()
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-01-29 20:07 ---
Yep:
tui_registers_changed_hook:
blr
Which means this is the same as PR 23488 which was caused by:
2005-07-30 Jan Hubicka
* expr.c (expand_expr_real_1): Do not load mem targets into register.
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-29 20:03 ---
Note, I think this works on targets where movs cannot have a mem with a
constant like most RISC targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42893
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-29 19:58 ---
*** This bug has been marked as a duplicate of 42893 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-29 19:58 ---
*** Bug 42899 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
John Regehr points out this size-regression WRT 3.4:
Sometimes a function modifies globals but even so has no net effect:
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/8A/8AB0B238.shtml
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/14/14157FE8.shtml
Somehow gcc3 sees
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-29 19:49 ---
This isn't confusing at all. ORDER_REGS_FOR_LOCAL_ALLOC is unused. All targets
that define it should be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42895
--- Comment #4 from carrot at google dot com 2010-01-29 19:42 ---
(In reply to comment #3)
> See arm.c:#define REG_ALLOC_ORDER. Comment before it says: " It is good to use
> ip since no saving is required (though calls clobber it) and it never contains
> function parameters. It is quite
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-29 19:38 ---
Confirmed, I think this was caused/exposed by:
2007-11-20 Jakub Jelinek
PR c/34146
* c-gimplify.c (optimize_compound_literals_in_ctor): New function.
(c_gimplify_expr): Use it.
--
pins
I've recently upgraded to GCC 4.3.2 from 4.2.2, and I noticed a strange
change in how volatile bitmask structures are optimized.
Consider the following code (compiled using just the -O3 option):
/* 32-bit MMIO */
struct hardware {
int parm1:8;
int :4;
int parm2:4;
int parm3:15;
int par
--- Comment #15 from janus at gcc dot gnu dot org 2010-01-29 19:18 ---
(In reply to comment #14)
> Note: There is another call to 'gfc_default_initializer' in
> 'gfc_trans_allocate', which should be moved to resolve.c too, I guess.
Here is a small test case (very similar to comment #0,
--- Comment #14 from janus at gcc dot gnu dot org 2010-01-29 19:01 ---
Ok, I think the best solution is to move the code setting up the initializer
back to resolve.c. Here is a patch which does so (without any testsuite
regressions):
Index: gcc/fortran/trans-stmt.c
--- Comment #7 from mrestelli at gmail dot com 2010-01-29 18:24 ---
(In reply to comment #5)
> Further reduced test case:
>
>
> type t
> integer, allocatable :: d(:)
> end type
> type(t), allocatable :: a(:)
>
> allocate(a(2))
> call sub( (/ a /) )
>
> contains
>
> s
--- Comment #3 from meissner at gcc dot gnu dot org 2010-01-29 17:54
---
Subject: Bug 41701
Author: meissner
Date: Fri Jan 29 17:54:14 2010
New Revision: 156360
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156360
Log:
PR 41701, prevent pow in compiler pathname from a false er
--- Comment #2 from meissner at gcc dot gnu dot org 2010-01-29 17:53
---
Subject: Bug 41701
Author: meissner
Date: Fri Jan 29 17:53:46 2010
New Revision: 156359
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156359
Log:
PR 41701, prevent pow in compiler pathname from a false er
--- Comment #4 from eric dot weddington at atmel dot com 2010-01-29 17:50
---
Closing as WONTFIX.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #10 from eric dot weddington at atmel dot com 2010-01-29 17:47
---
I have in my list this bug as fixed in 4.4.0. Closing.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-29 17:45 ---
I have now asked at comp.lang.fortran:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c00efc5679b6a879
(In reply to comment #2)
> The way usually recommended is to use a struct for interoperab
--- Comment #20 from eric dot weddington at atmel dot com 2010-01-29 17:45
---
I have in my list that this bug as fixed in 4.4.0. Closing.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
---
--- Comment #9 from ro at gcc dot gnu dot org 2010-01-29 17:37 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01508.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
--- Comment #8 from ro at gcc dot gnu dot org 2010-01-29 17:34 ---
Mine.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc do
--- Comment #21 from jakub at gcc dot gnu dot org 2010-01-29 17:26 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #10 from rguenther at suse dot de 2010-01-29 17:17 ---
Subject: Re: [4.5 Regression] Random debug generation
differences, bootstrap fails
On Fri, 29 Jan 2010, jakub at gcc dot gnu dot org wrote:
> --- Comment #9 from jakub at gcc dot gnu dot org 2010-01-29 16:43
--- Comment #10 from eric dot weddington at atmel dot com 2010-01-29 17:12
---
Setting Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
-
--- Comment #14 from jason at gcc dot gnu dot org 2010-01-29 17:11 ---
And closing.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITIN
--- Comment #13 from jason at gcc dot gnu dot org 2010-01-29 17:10 ---
Created an attachment (id=19753)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19753&action=view)
work snapshot
Here's a final snapshot of the work I did on this if anyone ever feels like
picking it up again.
--- Comment #7 from eric dot weddington at atmel dot com 2010-01-29 17:08
---
Setting Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
--- Comment #11 from eric dot weddington at atmel dot com 2010-01-29 17:07
---
Setting Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
-
--- Comment #16 from mjtruog at fastmail dot ca 2010-01-29 17:04 ---
I am using "-fpic/-fPIC" and in fact am using:
// g++ -g -O0 main.cpp -ldl
// g++ -g -O0 -rdynamic -c -fPIC -o library.o library1.cpp
// g++ -shared -Wl,-export-dynamic -o library.so library.o
I do want to use RTLD_DEE
--- Comment #9 from eric dot weddington at atmel dot com 2010-01-29 17:01
---
Closing as WONTFIX.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #4 from eric dot weddington at atmel dot com 2010-01-29 16:46
---
Setting Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-29 16:43 ---
In theory we could reuse the next_containing_mem field for a counter, as it
isn't used for anything once cselib_preserve_only_values is called (and I
believe canon_value_cmp is only ever used after vt_initialize phase
--- Comment #4 from eric dot weddington at atmel dot com 2010-01-29 16:43
---
Changed Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
--- Comment #12 from eric dot weddington at atmel dot com 2010-01-29 16:33
---
Setting target milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
-
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-29 16:26 ---
Created an attachment (id=19752)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19752&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42896
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-29 16:22 ---
It is caused by revision 154402:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00623.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42897
--- Comment #5 from dodji at gcc dot gnu dot org 2010-01-29 16:09 ---
Fixed in 4.5 (trunk).
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--
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 #8 from dodji at gcc dot gnu dot org 2010-01-29 16:08 ---
Fixed in 4.5 (trunk)
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #16 from dodji at gcc dot gnu dot org 2010-01-29 16:07 ---
Hopefully fixed in 4.5 (trunk) now.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from dodji at seketeli dot org 2010-01-29 15:48 ---
Subject: Re: [4.5 Regression] ICE with
pointer-to-member-function argument in template function with -fipa-sra
So this commit r156351 won't fix the root cause this issue, but I
believe it prevents the compiler from cr
--
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 #7 from jakub at gcc dot gnu dot org 2010-01-29 15:21 ---
:(, there apparently are VALUEs without locs so we can't always compare this
way.
Both the problematic VALUEs are created through
e = new_cselib_val (hashval, mode, x);
(the only place which doesn't assign VALUE values
--- Comment #15 from mark at codesourcery dot com 2010-01-29 15:12 ---
Subject: Re: warnings about 'mangling of 'va_list' has changed
in GCC 4.4' not suppressed in sytem headers
manu at gcc dot gnu dot org wrote:
> Why is this a note and not simply a warning?
Because, as noted earli
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-29 15:04 ---
After fixing the typo it ICEs with the testcase:
../../trunk/gcc/dse.c: In function 'check_mem_read_rtx':
../../trunk/gcc/dse.c:2300:1: internal compiler error: in tie_break_values, at
var-tracking.c:1179
Please sub
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-29 15:00 ---
Created an attachment (id=19751)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19751&action=view)
gcc45-pr42896.patch
Try this. If we ever hit the assertion, some more patching will be needed to
break the ties.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-01-29 14:33 ---
Yes, the clone_of and similar datastructures are cleared because function is no
longer a virtual clone. Probably best way to get to original function is via
DECL_ABSTRACT_ORIGIN same way as debug info does. Is that
--- Comment #7 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42758
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR c++/
--- Comment #23 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42336
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR c++
--- Comment #47 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42880
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR c++
--- Comment #15 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42634
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR c++
--- Comment #4 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42797
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR c++/
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-29 14:04 ---
Needs randomized va-space to trigger. My guess:
/* Determine a total order between two distinct pointers. Compare the
pointers as integral types if size_t is wide enough, otherwise
resort to bitwise memory c
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-29 14:00 ---
Created an attachment (id=19750)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19750&action=view)
testcase
inside stage3/gcc:
obj/gcc> /abuild/rguenther/obj/./prev-gcc/cc1 -fpreprocessed dse.i -quiet
-dumpbas
1 - 100 of 122 matches
Mail list logo
