--- Comment #2 from ramana at gcc dot gnu dot org 2010-01-29 07:53 ---
Confirmed - I'm marking this as an enhancement.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from jakub at gcc dot gnu dot org 2010-01-29 07:52 ---
Clearly this works with icc, because library.so isn't linked against
libstdc++.so. I guess if you link the library with gcc instead of g++, it will
work too.
Any reason why you need to use RTLD_DEEPBIND? AFAIK it ha
--- Comment #24 from chrbr at gcc dot gnu dot org 2010-01-29 07:46 ---
Created an attachment (id=19747)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19747&action=view)
fixed removal of landing pad label rtx
The landing_pad label rtx was created and recorded in tree_inline
(duplic
--- Comment #3 from monaka at monami-software dot com 2010-01-29 07:34
---
(In reply to comment #2)
> Created an attachment (id=19746)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19746&action=view) [edit]
> preprocessed source.
>
(In reply to comment #1)
> Without preprocessed
--- Comment #2 from monaka at monami-software dot com 2010-01-29 07:32
---
Created an attachment (id=19746)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19746&action=view)
preprocessed source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42796
--- Comment #2 from monaka at monami-software dot com 2010-01-29 05:52
---
Here is a backtrace. This issue is caused by driver.
Program received signal EXC_SOFTWARE, Software generated exception.
0x9828e792 in __wait4 ()
(gdb) where
#0 0x9828e792 in __wait4 ()
#1 0x9828e785 in waitp
--- Comment #3 from monaka at monami-software dot com 2010-01-29 03:21
---
We can reproduce same ICE with Attachment #19745.
I got ICE in case like this.
$ cc1 -msx -g -O1 regex.i
but I didn't get any errors in case like this.
$ cc1 -msx -g -O0 regex.i -fipa-pure-const
So it's possib
--- Comment #2 from monaka at monami-software dot com 2010-01-29 03:17
---
Created an attachment (id=19745)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19745&action=view)
simplified code that causes same error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42790
--- Comment #23 from kkojima at gcc dot gnu dot org 2010-01-29 02:19
---
I agree with you that there is a latent problem. It seems
that sh_reorg inserts a CP with a new jump at the landing pad
for the exception in basic.cc and propagation_consistent.cc
cases. This confuses EH processi
--- Comment #13 from paolo dot carlini at oracle dot com 2010-01-29 00:46
---
This is the LD_DEBUG output for Icc 11.1, thus no crash.
17439: symbol=_ZSt4cerr; lookup in file=./a.out [0]
17439: binding file /usr/lib64/libstdc++.so.6 [0] to ./a.out [0]:
normal symbol
--- Comment #1 from carrot at google dot com 2010-01-29 00:14 ---
Created an attachment (id=19744)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19744&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42895
Compile the attached source code with options -march=armv7-a -mthumb -Os, gcc
generates:
ldr r3, [r0, #0]
push{r4, r5, lr}
ldrbr0, [r3, #0]@ zero_extendqisi2
cmp r0, #127
bgt .L2
ldrbip, [r3, #1]@ zero_extendqisi2
--- Comment #19 from steven at gcc dot gnu dot org 2010-01-28 23:48 ---
On ARM I have the following stats about the dependence graph for add_functions:
Number of insns: 6630
Average number of sd_lists_size: 2512
For comparison, on atholon:
Number of insns: 5640
Average number of sd_list
--- Comment #18 from steven at gcc dot gnu dot org 2010-01-28 23:22 ---
Function that seems to cost the most time is add_functions(), which is one big
basic block of ~7500 insns (~500 of them call insns).
List scheduling is quadratic in the number of insns per basic block. I don't
know
--- Comment #17 from steven at gcc dot gnu dot org 2010-01-28 23:03 ---
Introduced by http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00094.html.
Needs 1.3GB and 68s to compile on an 800MHz AMD64 x86_64 X
armv5tejl-unknown-linux-gnueabi compiler. The compiler spends 87% of its time
in the sche
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-28 22:59
---
Good. Now, if I can have a little bit more of your time, I have two main
curiosities: can you guess why the same 4.4.x *.so + headers don't lead to a
crash with ICC? Then, we should of course come to a possibl
--- Comment #46 from jason at gcc dot gnu dot org 2010-01-28 22:52 ---
Subject: Bug 42880
Author: jason
Date: Thu Jan 28 22:52:36 2010
New Revision: 156336
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156336
Log:
PR c++/42880
* semantics.c (begin_class_definiti
--- Comment #11 from jakub at gcc dot gnu dot org 2010-01-28 22:49 ---
LD_DEBUG=all ./main 2>&1 | grep _ZSt4cerr
12758: symbol=_ZSt4cerr; lookup in file=./main [0]
12758: binding file /usr/lib64/libstdc++.so.6 [0] to ./main [0]:
normal symbol `_ZSt4cerr' [GLIBCXX_3.4]
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-28 22:35
---
Jakub, Jason, thanks for the additional info, hopefully we can make progress on
this issue. By the way, I'm not sure if you noticed that we have an actual
reproducer in Comment #2, is it consistent with your
--- Comment #19 from steven at gcc dot gnu dot org 2010-01-28 22:23 ---
I don't think there's a need to solve all at once, but it's only good practice
to look ahead for more bears on the road :-P
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42889
--- Comment #18 from jakub at gcc dot gnu dot org 2010-01-28 22:09 ---
Those need to be analyzed, perhaps some will need a similar change, many others
don't need any change, as they can't be called for DEBUG_INSNs. E.g.
DEBUG_INSN isn't changing control flow, so any changes to it won't
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-28 22:07 ---
The theoretical example is libstdc++ defining some object where things
misbehave if it is not the only one (say foo) and some other library has that
object as well. When that other library isn't an direct or indirect
--- Comment #16 from steven at gcc dot gnu dot org 2010-01-28 21:55 ---
Re. comment #9 -- had anyone actually tried ARM code size with sched1 enabled
and the -fsched-pressure flag added?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41399
--- Comment #16 from pault at gcc dot gnu dot org 2010-01-28 20:35 ---
trunk and 4.4 have diverged too far from 4.3 to fix this one simply. The patch
applied cleanly but the problem was not fixed. Copying over the entirity of
gfc_conv_elemental_dependencies, with mods for other functio
--- Comment #8 from jason at gcc dot gnu dot org 2010-01-28 20:01 ---
The issue Jakub describes is indeed the motivation for STB_GNU_UNIQUE. But I
don't know why RTLD_DEEPBIND would cause trouble when the library is only
loaded once.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888
--- Comment #13 from burnus at gcc dot gnu dot org 2010-01-28 18:44 ---
(In reply to comment #11)
> I get a suspicious error:
>
> Error: The NULL in the derived type constructor at (1) is being applied to
> component 'ptr', which is neither a POINTER nor ALLOCATABLE
The problem is that
--- Comment #17 from steven at gcc dot gnu dot org 2010-01-28 18:05 ---
How does this address the 30ish calls to df_set_bb_dirty from the rest of the
compiler? See cfgcleanup, cfgrtl, emit-rtl, ifcvt, and modulo-sched. Each of
them could result in a DCE run if someone adds DF_LR_RUN_DCE.
--- Comment #5 from ubizjak at gmail dot com 2010-01-28 17:59 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from uros at gcc dot gnu dot org 2010-01-28 17:58 ---
Subject: Bug 42891
Author: uros
Date: Thu Jan 28 17:58:03 2010
New Revision: 156327
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156327
Log:
PR target/42891
* config/i386/i386.c (ix86_expand_i
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-28 17:51
---
I don't know the details frankly, but at minimum we should be *very* careful
and make sure we do the right thing also in the special cases, eg, on i386 when
the atomic builtins are not available.
--
http:/
--- Comment #6 from jwakely dot gcc at gmail dot com 2010-01-28 17:47
---
similarly, if cygwin and mingw32 implement __sync_fetch_and_add etc. then why
keep custom versions for those platforms? (but maybe the builtins aren't
implemented on those platforms - I have no idea)
--
http
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-01-28 17:46
---
and I thought everyone had forgotten about that patch ;)
granted, ICC uses libstdc++, but doesn't it already have to support the same
atomic builtins as used elsewhere in the library? And my patch changes
parall
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-28 17:28
---
Note: I don't think we should remove support for ICC, since lately it doesn't
come anymore with Dinkum, libstdc++-v3 is the default C++ runtime. Likewise, we
should probably keep support for mingw32 and cygwin.
--- Comment #16 from jakub at gcc dot gnu dot org 2010-01-28 17:23 ---
Created an attachment (id=19743)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19743&action=view)
gcc45-pr42889.patch
Patch that does that.
BTW, df_ref_create and df_ref_remove guard the df_set_bb_dirty calls w
--- Comment #23 from tony3 at GarlandConsulting dot us 2010-01-28 17:16
---
Jonathan,
Thanks for explaining that operation outside the norm is unspecified such
that the compiler can do anything and everything.
>I think a warning for this would be helpful, but asking for the compiler t
--- Comment #9 from paolo dot carlini at oracle dot com 2010-01-28 17:16
---
Roger told me in private that he doesn't mean to actively work on this issue
any time soon. Unassigning.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Add
--- Comment #15 from jakub at gcc dot gnu dot org 2010-01-28 17:08 ---
If only LR can make code changes, perhaps we should just avoid marking LR dirty
and make all other problems dirty. Add df_set_bb_dirty_nonlr and
df_mark_solutions_dirty_nonlr or something like that.
--
http://gc
--- Comment #38 from rguenth at gcc dot gnu dot org 2010-01-28 16:58
---
Nope, bootstrap is generally broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-01-28 16:50
---
But it miscompares. Honza?!
Index: gcc/ipa-inline.c
===
*** gcc/ipa-inline.c(revision 156321)
--- gcc/ipa-inline.c(working copy)
***
--- Comment #36 from rguenth at gcc dot gnu dot org 2010-01-28 16:42
---
With the patch:
inline heuristics : 0.77 ( 0%) usr 0.01 ( 0%) sys 1.37 ( 0%) wall
0 kB ( 0%) ggc
expand: 9.42 ( 2%) usr 0.70 (11%) sys 10.36 ( 2%) wall
138780 kB (29%) ggc
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-28 16:35 ---
Why, actually, was the solution here to disable byte level DCE for all targets,
when only CC0 targets are affected? Is there any reason why the pass cannot be
enabled for non-CC0 machines?
--
steven at gcc dot gnu
--- Comment #14 from steven at gcc dot gnu dot org 2010-01-28 16:28 ---
Re. comment #12: I think both: Do not call df_set_bb_dirty in df_insn_rescan
rescans a DEBUG_INSN, *and* mark dirty only certain problems. The last part is
probably the most tricky bit: which problems to mark. I thin
--- Comment #15 from paolo dot carlini at oracle dot com 2010-01-28 16:27
---
In the meanwhile I have been able to build and run make check-parallel on a
x86_64-apple-darwin10.2.0, and indeed the specific problem seems fixed.
Beyond that, I'm pretty sure a judicious use of DYLD_LIBRARY
--- Comment #35 from rguenth at gcc dot gnu dot org 2010-01-28 16:21
---
I have a fix for the inline-heuristic slowness.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #4 from christophe dot guillon at st dot com 2010-01-28 16:20
---
Thanks for the detailled reply, I fully agree with your points:
- first, indeed, it's a matter of choice in the ABI (or compiler), the
assumption would be that a function that call another function of the same
--- Comment #12 from dominiq at lps dot ens dot fr 2010-01-28 15:39 ---
Created an attachment (id=19742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19742&action=view)
Test that gives the error in comment #11 (wrongly attached to pr42889).
--
http://gcc.gnu.org/bugzilla/show
--- Comment #13 from dominiq at lps dot ens dot fr 2010-01-28 15:37 ---
Wrong pr!-(sorry for the noise).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42889
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-28 15:37 ---
x86 ABI doesn't have any such guarantees.
Consider a function foo exported from the library which just calls this static
or visibility ("internal") function bar (but doesn't call any function through
PLT nor uses any g
--- Comment #14 from paolo dot carlini at oracle dot com 2010-01-28 15:23
---
If I understand correctly at least part of this issue, now the situation should
be somewhat better, because a few days after the original conversation in the
audit trail, I enabled extern templates for paralle
--- Comment #12 from jakub at gcc dot gnu dot org 2010-01-28 15:11 ---
So not call df_set_bb_dirty in df_insn_rescan if DEBUG_INSN_P (insn), or not
mark dirty only certain problems?
I believe DEBUG_INSNs aren't meant to extend lifetime of pseudos, so perhaps
lr/live problems don't need t
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-28 15:02
---
Fixed for 4.5 sofar. Let's see if there is any fallout.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from dominiq at lps dot ens dot fr 2010-01-28 14:59 ---
Created an attachment (id=19741)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19741&action=view)
Code giving a suspicious error with the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42889
--- Comment #11 from dominiq at lps dot ens dot fr 2010-01-28 14:58 ---
> This patch does not induce any regressions in the testsuite. However, the
> question is if there are other problems, e.g. when resolve_structure_cons
> would
> throw an error message.
I did not regtest, but I get
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42893
--- Comment #2 from christophe dot guillon at st dot com 2010-01-28 14:55
---
This enhancement is still pending on gcc 4.4.3 on x86.
A function declared internal sets the GOT pointer while it could be avoided in
a callee-set-GOT model as on x86 ABI.
By defintion an internal function can
--- Comment #1 from christophe dot guillon at st dot com 2010-01-28 14:54
---
Created an attachment (id=19740)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19740&action=view)
Test case for the internal function enhancement
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23756
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-28 14:51 ---
(In reply to comment #9)
> Index: gcc/fortran/trans-stmt.c
> ===
> --- gcc/fortran/trans-stmt.c(revision 156258)
> +++ gcc/fortran/trans-stmt.c(w
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-28 14:45
---
Subject: Bug 42871
Author: rguenth
Date: Thu Jan 28 14:45:09 2010
New Revision: 156324
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156324
Log:
2010-01-28 Richard Guenther
PR tree-optimizatio
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-28 14:41 ---
Subject: Bug 42883
Author: rguenth
Date: Thu Jan 28 14:40:59 2010
New Revision: 156322
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156322
Log:
2010-01-28 Richard Guenther
PR middle-end/42883
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-28 14:41 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from matz at gcc dot gnu dot org 2010-01-28 14:40 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from matz at gcc dot gnu dot org 2010-01-28 14:12 ---
Subject: Bug 42881
Author: matz
Date: Thu Jan 28 14:11:34 2010
New Revision: 156320
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156320
Log:
PR target/42881
* config/i386/i386.c (ix86_expand_v
--- Comment #10 from steven at gcc dot gnu dot org 2010-01-28 13:53 ---
The patch of comment #9 is a hack that doesn't solve anything. There are loads
of other passes that may inadvertedly trigger a fast DCE if only a DEBUG_INSN
is modified and needs to be rescanned.
IMHO the only "prop
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-28 13:39 ---
Created an attachment (id=19739)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19739&action=view)
gcc45-pr42889.patch
Patch that cures this by not running DCE if only DEBUG_INSNs changed.
--
http://gcc.gnu.
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-28 13:32 ---
(In reply to comment #7)
> While for the old rev. 'type' and 'orig' are both
> INTEGER_TYPE, 'orig' is REAL_TYPE on current trunk. I'll try to find out how
> that comes about.
Got it. Previously the constructor was cr
--- Comment #8 from burnus at gcc dot gnu dot org 2010-01-28 13:27 ---
(In reply to comment #7)
> Btw: Isn't this whole thing of 'integer component with real initializer'
> invalid in some way? Shouldn't we at least throw a warning?
Well, according to the standard (F2008 because I have
--- Comment #22 from chrbr at gcc dot gnu dot org 2010-01-28 13:09 ---
humm, looks like a latent bug. Accidentally the CP is inserted before a
compact_jump, which enable further redirect jump optimisation. I don't think it
is directly related to the fix, but lets work it a little bit mor
--- Comment #7 from janus at gcc dot gnu dot org 2010-01-28 13:02 ---
(In reply to comment #6)
> #0 fold_convert_loc (loc=0, type=0x77e83498, arg=0x77f65060) at
> /home/jweil/gcc45/trunk/gcc/fold-const.c:2669
> #1 0x005a088a in gfc_trans_scalar_assign (lse=0x7fffd4d
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-28 12:47 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #1 from zsojka at seznam dot cz 2010-01-28 12:38 ---
I checked with 4.4 r149995 (just after release of 4.4.1), and it fails there
too. So probably not a regression, but the reason it doesn't appear in gentoo
builds is because it's compiled with --disable-checking.
--
htt
--- Comment #3 from ubizjak at gmail dot com 2010-01-28 12:33 ---
This regression was introduced by me in
2009-11-24 Uros Bizjak
...
(ix86_expand_int_movcc): Update calls to gen_x86_mov{si,di}cc_0_m1.
...
Following revert fixes this PR:
Index: i386.c
==
--- Comment #7 from dodji at gcc dot gnu dot org 2010-01-28 12:30 ---
Fixed in trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #4 from dodji at gcc dot gnu dot org 2010-01-28 12:30 ---
Subject: Bug 42820
Author: dodji
Date: Thu Jan 28 12:29:52 2010
New Revision: 156316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156316
Log:
Fix PR c++/42713
gcc/cp/ChangeLog:
PR c++/42713
--- Comment #6 from dodji at gcc dot gnu dot org 2010-01-28 12:30 ---
Subject: Bug 42713
Author: dodji
Date: Thu Jan 28 12:29:52 2010
New Revision: 156316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156316
Log:
Fix PR c++/42713
gcc/cp/ChangeLog:
PR c++/42713
--- Comment #8 from rguenther at suse dot de 2010-01-28 12:09 ---
Subject: Re: [4.5 Regression] "-fcompare-debug
failure (length)" with "-O1 -fgcse"
On Thu, 28 Jan 2010, steven at gcc dot gnu dot org wrote:
> --- Comment #7 from steven at gcc dot gnu dot org 2010-01-28 12:07
>
--- Comment #7 from steven at gcc dot gnu dot org 2010-01-28 12:07 ---
Well let's face it: All this happening because of DEBUG_INSN/DEBUG_STMT is deep
in "hate to say I told you so" teritory...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42889
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-28 11:05 ---
(In reply to comment #5)
> FWIW, DF rescanning runs with -g1 and not with -g0 because copy propagation
> updates a debug_insn:
>
> LOCAL COPY-PROP: Replacing reg 63 in insn 28 with reg 72
>
> (insn 27 26 28 4 PR428
--- Comment #2 from steven at gcc dot gnu dot org 2010-01-28 11:00 ---
The RTL .ce1 pass catches it in GCC 3.4.6. The codes goes from this:
;; Start of basic block 1, registers live: (nil)
(note 36 13 17 1 [bb 1] NOTE_INSN_BASIC_BLOCK)
(insn 17 36 18 1 (set (reg:SI 60 [ tui_refreshing_
--- Comment #6 from janus at gcc dot gnu dot org 2010-01-28 10:29 ---
(In reply to comment #5)
> I think the relevant part is:
> http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/trans-stmt.c?r1=152345&r2=152344&pathrev=152345
> -- especially around "Add default initializer for those derived
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-28 10:17 ---
FWIW, DF rescanning runs with -g1 and not with -g0 because copy propagation
updates a debug_insn:
LOCAL COPY-PROP: Replacing reg 63 in insn 28 with reg 72
(insn 27 26 28 4 PR42889.c:7 (set (reg/v:SI 63 [ x ])
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-28 10:14 ---
The fast DCE is not called because df_lr_finalize is never called with -g0 --
nothing has changed so there is nothing to finalize.
Unassigning. Aleksandre's problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #22 from jwakely dot gcc at gmail dot com 2010-01-28 10:13
---
(In reply to comment #14)
>
> So does the C++ standard say that it is acceptable for the compiler to drop
> support for an out-of-range enumeration value in a way that the programmer has
> no idea it happens--bu
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
Priority|P3 |P1
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-28 10:08 ---
Confirmed. Also fails with -O3.
424 if (type_like_member_ptr_p (TREE_TYPE (arg), NULL, NULL))
(gdb) p arg
$1 = (tree) 0x76197e70
(gdb) call debug_tree (arg)
def_stmt
version 3 in-free-list>
-
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-28 09:50
---
Many thanks Jakub. I have to give this issue much more thought. For the time
being I'm going to add Jason in CC in case he wants to suggest something in
particular, I see he was involved in the STB_GNU_UNIQUE i
--- Comment #1 from rguenther at suse dot de 2010-01-28 09:46 ---
Subject: Re: New: [4.3/4.4/4.5 Regression]
Missed conditionally dead store elimination
On Thu, 28 Jan 2010, steven at gcc dot gnu dot org wrote:
> Taken from
> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/sour
--- Comment #45 from paolo dot carlini at oracle dot com 2010-01-28 09:45
---
Thanks HJ and Dodji.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-28 09:40 ---
combine fails to combine the following insns.
Before combine (.init_regs dump):
(insn 20 19 21 4 PR42889.c:7 (parallel [
(set (reg:SI 70)
(and:SI (reg/v:SI 64 [ c ])
(
--- Comment #2 from steven at gcc dot gnu dot org 2010-01-28 09:07 ---
Caused by an RTL PRE transformation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42889
--- Comment #5 from burnus at gcc dot gnu dot org 2010-01-28 08:50 ---
Janus, can you have a look? It is related to your allocatable + class patch.
Fortran-dev commit:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00874.html
Branch merge:
http://gcc.gnu.org/viewcvs?view=revision&revision
--- Comment #6 from dodji at gcc dot gnu dot org 2010-01-28 08:37 ---
*** Bug 42880 has been marked as a duplicate of this bug. ***
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #44 from dodji at gcc dot gnu dot org 2010-01-28 08:37 ---
This actually looks like another instance of PR c++/42758.
*** This bug has been marked as a duplicate of 42758 ***
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from amodra at gmail dot com 2010-01-28 08:28 ---
bootstrap and regression testing a fix
--
amodra at gmail dot com changed:
What|Removed |Added
As
--- Comment #43 from dodji at gcc dot gnu dot org 2010-01-28 08:26 ---
Created an attachment (id=19738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19738&action=view)
A somewhat reduced test case.
This is a reduced test case, just in case.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-28 08:17 ---
Simplified testcase:
union B { int i; float f; };
extern void bar (void);
void
foo (union B x, union B y)
{
if (!(y.f > x.i))
bar ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42891
--- Comment #1 from ubizjak at gmail dot com 2010-01-28 08:11 ---
Confirmed, expand generates invalid RTX:
(insn 42 41 43 pr42891.c:79 (parallel [
(set (reg:QI 79)
(if_then_else:SI (unlt:SI (reg:CCFPU 17 flags)
(const_int 0 [0x0]))
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-28 08:03 ---
If libstdc++ relies on ODR, then RTLD_DEEPBIND can break its assumptions, as
then the same symbol which is defined in multiple shared libraries can resolve
to different addresses (RTLD_DEEPBIND means first the dlopened
100 matches
Mail list logo
