Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28767
--- Comment #6 from drow at gcc dot gnu dot org 2006-08-22 20:03 ---
The use in main should still set TREE_USED, though; should TREE_USED on a
member ought to cause the class to be emitted?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14167
--- Comment #6 from drow at gcc dot gnu dot org 2006-08-25 14:35 ---
We're pruning excessively; I'll track down why.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |drow at gcc dot gnu dot org
|dot org
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu
--- Comment #7 from drow at gcc dot gnu dot org 2006-08-25 17:27 ---
Testing a fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017
--- Comment #15 from drow at gcc dot gnu dot org 2006-08-25 18:57 ---
I don't think I can sort this one out. I think the easiest solution will be to
check when marking a function as reachable whether it has an abstract origin,
and if so set a flag in the abstract origin preventing its
--- Comment #11 from drow at gcc dot gnu dot org 2006-08-25 19:57 ---
I am looking at this.
The difference between those two compilers in t16.ssa is:
- # blist_1 = PHI blist_6(2), blist_7(1);
+ # blist_1 = PHI blist_7(1), blist_6(2);
The difference in t17.alias1 is that, plus
--- Comment #12 from drow at gcc dot gnu dot org 2006-08-25 20:50 ---
Created an attachment (id=12141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12141action=view)
Aliasing fix.
Thank you Janis for the reghunt! Not too hard to track down given that.
I haven't tested
--- Comment #13 from drow at gcc dot gnu dot org 2006-08-25 20:57 ---
Unfortunately Diego's gone and rewritten a bunch of aliasing code since that
revision. And there's no code corresponding to where the fix went 21 months
ago. So, congratulations: we've broken this testcase twice!
I
--- Comment #14 from drow at gcc dot gnu dot org 2006-08-25 22:11 ---
Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
--- Comment #8 from drow at gcc dot gnu dot org 2006-08-26 03:48 ---
My fix was completely wrong. I'll try again.
The problem is that we have
function f
class s
static function g
We never walk into f. So we never find out that it contains g, and g needs a
DIE. Normally
--- Comment #15 from drow at gcc dot gnu dot org 2006-08-26 15:14 ---
I don't understand aliasing well enough to fix this correctly. See for more:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00965.html
--
drow at gcc dot gnu dot org changed:
What|Removed
--- Comment #18 from drow at gcc dot gnu dot org 2006-08-26 23:25 ---
Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
On Sat, Aug 26, 2006 at 08:42:50PM -, rguenth at gcc dot gnu dot org wrote:
So, making pointer arguments effectively using alias-set
--- Comment #24 from drow at gcc dot gnu dot org 2006-08-27 17:56 ---
Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
On Sun, Aug 27, 2006 at 04:00:19PM -, dberlin at dberlin dot org wrote:
1. You believe this is a good idea for 4.2, even though
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28872
.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
--- Comment #1 from drow at gcc dot gnu dot org 2006-09-12 21:43 ---
Unless this turns out to be a mangling problem, I assume it's a
libiberty/demangler problem.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from drow at gcc dot gnu dot org 2006-09-13 12:31 ---
Subject: Re: Libiberty demangler can not handle new Java mangling.
I don't understand why this bug has been reported.
The bug was reported because the combination of the mangling change and
the demangler postfix
--- Comment #8 from drow at gcc dot gnu dot org 2006-09-13 12:31 ---
Not a bug then.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #10 from drow at gcc dot gnu dot org 2006-09-28 01:31 ---
Andrew, stop closing this bug.
If necessary I will ask the SC for a statement preventing you from closing bugs
as invalid when the submitter disagrees, since you haven't shown a willingness
to listen to what
--- Comment #5 from drow at gcc dot gnu dot org 2006-09-28 01:32 ---
While I firmly agree with Wolfgang, my same comment about the meaning of
RESOLVED/INVALID applies here also.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from drow at gcc dot gnu dot org 2006-09-30 15:37 ---
Subject: Re: want way to #include but still able to finish compiling
On Thu, Sep 28, 2006 at 06:09:12AM -, bangerth at dealii dot org wrote:
Daniel, would you prefer if we marked this as WONTFIX? I think
--- Comment #10 from drow at gcc dot gnu dot org 2006-10-05 20:49 ---
FYI, the testcase does not build with my system g++ 4.1.2; remove the static
from 'extern C static'. The result does not choke my system's binutils, i.e.
it links successfully.
If I use the provided .s file instead
--- Comment #9 from drow at gcc dot gnu dot org 2006-10-23 14:15 ---
I haven't had another chance to work on this; update assigned to reflect
reality. Hopefully the analysis will be useful to someone.
--
drow at gcc dot gnu dot org changed:
What|Removed
--- Comment #47 from drow at gcc dot gnu dot org 2006-11-05 22:25 ---
Subject: Re: [4.0/4.1 Regression] alias bug with cast and call clobbered
On Sun, Nov 05, 2006 at 10:17:16PM -, chuck at vertica dot com wrote:
Folks, can anyone please tell me if this is the same problem as I
--- Comment #6 from drow at gcc dot gnu dot org 2006-11-06 19:33 ---
Created an attachment (id=12553)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12553action=view)
Potential patch.
This hasn't been tested yet; when it has I can add a changelog and post it.
That's in progress
--- Comment #8 from drow at gcc dot gnu dot org 2006-11-06 21:47 ---
I'm not sure, but I think that our hppa port hasn't switched over yet.
As for ARM, I'm not sure what to do to fix the issue. ARM old ABI is stuck
with SJLJ. And the EABI can't implement _Unwind_Backtrace either. I
--- Additional Comments From drow at gcc dot gnu dot org 2005-03-08 17:31
---
Fixed on 3.4 and 4.0 branches.
--
What|Removed |Added
Status|NEW
--- Additional Comments From drow at gcc dot gnu dot org 2005-03-21 16:26
---
I do consider it a bug that there is no way to request GCC emit full debug
information in this case. But can you give an example in which it doesn't work?
In general, it relies on the C++ One Definition Rule
--- Additional Comments From drow at gcc dot gnu dot org 2005-03-21 16:31
---
Nice patch! GDB should be fine with this; it either treats inlined subroutines
the same as lexical blocks at the moment, or ignores them entirely. It does
not really support DW_AT_ranges
--- Additional Comments From drow at gcc dot gnu dot org 2005-03-24 16:49
---
Joern, why are you committing patches to 4.0 without testing? The release isn't
_that_ imminent. Also, did you see Zack's suggestion? And Mark did ask that
no one add 4.0.0 milestones without talking to him
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-07 12:31
---
I have a GDB patch that will avoid the internal error. I'll dig it up.
I suppose there's room to argue that GCC's output is correct. Am I right in
thinking that the function-local extern could, in some
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-07 14:28
---
As for whether the debug information is correct:
- It would be preferable if the full declaration was the one outside the
function rather than inside, but I don't think there's anything
--
What|Removed |Added
CC||drow at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20955
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-12 12:53
---
Subject: Re: Top-level gcc configure/makefile does not handle --with-sysroot
On Tue, Apr 12, 2005 at 12:50:29PM -, prothonotar at tarnation dot dyndns
dot org wrote:
--- Additional Comments From
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-12 13:14
---
No version information. Is this HEAD, with Jim's earlier DW_AT_ranges patch?
I don't think your understanding is correct, but you didn't show enough of the
DIE tree to be sure. Ignore inlined functions
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-12 14:08
---
Subject: Re: g++ generates same DW_AT_ranges info for two different functions
It's a question of what associated machine code means. I think that
the machine code is in fact associated with more than one
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-14 03:10
---
Actually, we can and should fix this. What I gave was only a workaround.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |drow at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-14 03:11
---
I'll look at it when I can find the time.
--
What|Removed |Added
Severity|normal
at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mips64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-14 13:32
---
Created an attachment (id=8630)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8630action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
CC: gcc-bugs at gcc dot
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-25 21:07
---
The reload was created because the earlyclobber operand conflicts with
a_oldval2, which is placed in r3 by local-alloc. I think I see why...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21223
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-25 21:12
---
The problem is in reg_is_set or its caller.
Because the output is an earlyclobber operand, it needs to be marked as born
before the insn, to conflict with its inputs. I do not see an obvious way to
get from
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org,pinskia at gcc dot gnu dot org,stevenb at suse
dot de
GCC target triplet: arm-none
--- Additional Comments From drow at gcc dot gnu dot org 2005-05-12 15:31
---
Created an attachment (id=8873)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8873action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
--- Additional Comments From drow at gcc dot gnu dot org 2005-05-27 19:28
---
You haven't said how you configured GCC. I'm guessing you configured for
arm-linux, but with an AAPCS-compatible ABI; you can't do that. The error isn't
the greatest, but it's hard to guard against all
--- Additional Comments From drow at gcc dot gnu dot org 2005-05-27 21:02
---
Subject: Re: [csl-arm-branch and HEAD] fails to bootstrap with EABI
On Fri, May 27, 2005 at 08:57:59PM -, bero at arklinux dot org wrote:
Yes, configuration was
../confiugre --prefix=/usr
: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26475
--- Comment #1 from drow at gcc dot gnu dot org 2006-02-27 20:44 ---
Dan Berlin, Diego, and I bounced this around on IRC a little. A couple of
things that came up:
- Diego suggested putting locuses on unshared INTEGER_CSTs as another
possible approach.
- I suggested that if we
--- Comment #2 from drow at gcc dot gnu dot org 2006-03-18 19:20 ---
See Joseph's comments:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01155.html
I don't think there's a GCC bug here either. If anything, it sounds like a GDB
bug (and I remember Mark Kettenis fixing a similar GDB
: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27160
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27672
--- Comment #7 from drow at gcc dot gnu dot org 2006-06-06 04:01 ---
I'm pretty sure it's older than that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
--- Comment #5 from drow at gcc dot gnu dot org 2006-06-06 04:04 ---
The debug information is completely wrong. The only DIEs are: compilation
unit, int, f(), f's argument1, and main(). Nothing for the type f()::s.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28063
optimizing
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla
are incompatible (at
least with NPTL)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot
--- Comment #3 from drow at gcc dot gnu dot org 2006-06-24 02:52 ---
No, that was not the consensus, and I reported this bug specifically because
the coding practices used in libstdc++ cause problems with cancellation...
progress was being made, the last time I read c++-pthreads
--- Comment #4 from drow at gcc dot gnu dot org 2006-07-12 16:08 ---
(In reply to comment #3)
Is it OK to add (set_attr can_delay no) for tls_get_tp_mode
definition?
I think so, with suitable comment. Some future MIPS architecture may provide a
register for this, in which case
--- Comment #10 from drow at gcc dot gnu dot org 2006-07-21 16:57 ---
(In reply to comment #9)
Case 1:
There is no location info for the parameter x because it has been optimized
away. Change the variable x in main to y to avoid ambiguity, compile with
-fdump-tree-all, and look
with a
particular random seed.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC
--- Comment #2 from drow at gcc dot gnu dot org 2006-07-22 17:45 ---
Testing a patch for this.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |drow at gcc dot gnu dot org
|dot org
--- Comment #1 from drow at gcc dot gnu dot org 2006-07-22 17:46 ---
Testing a patch for this.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from drow at gcc dot gnu dot org 2006-07-22 18:06 ---
Hmm. What's happening here is that we set TREE_USED on the enumerator, but not
on the type. The enumerator never gets output, because the type is not output.
It would probably be a strict improvement to add the type
--- Comment #9 from drow at gcc dot gnu dot org 2006-07-22 18:34 ---
Meanwhile, I'm testing a patch to treat them just as well as we treat casts.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from drow at gcc dot gnu dot org 2006-07-22 19:39 ---
Ian, could you say why you think that patch is responsible? I wonder if your
testcase would behave any differently on either side of the patch; it might be
something different taking up all the space.
I think
--- Comment #5 from drow at gcc dot gnu dot org 2006-07-22 20:05 ---
I am not going to track down what did it, but something has fixed this on the
4.2 branch. I can reproduce it on Debian's 4.1 branch snapshot. If someone
wants to fix it on 4.1, it should probably be easy to use
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
--- Comment #1 from drow at gcc dot gnu dot org 2006-07-23 00:12 ---
Mark, did the old C++ parser have TYPE_CONTEXT == NULL for the global scope and
the new one have it pointing to the global namespace, or something like that?
If so, I guess we'll have to strip that out in dwarf2out
--- Comment #3 from drow at gcc dot gnu dot org 2006-07-23 16:44 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
On Sun, Jul 23, 2006 at 03:59:58PM -, mark at codesourcery dot com wrote:
If we're setting TYPE_CONTEXT to global_namespace, I think that's a C
--- Comment #6 from drow at gcc dot gnu dot org 2006-07-23 18:48 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
On Sun, Jul 23, 2006 at 06:03:46PM -, gdr at integrable-solutions dot net
wrote:
I believe the situation has been that clear for DECLs
--- Comment #7 from drow at gcc dot gnu dot org 2006-07-23 19:55 ---
grokvardecl uses a NULL scope to indicate the current scope, and current_scope
never returns NULL. It used to, before revision 89627, but then grokvardecl
explicitly tried current_namespace.
This patch instituted
--- Comment #12 from drow at gcc dot gnu dot org 2006-07-24 00:11 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
On Sun, Jul 23, 2006 at 11:47:32PM -, gdr at integrable-solutions dot net
wrote:
I agree that is the correct representation. Can we agree
--- Comment #14 from drow at gcc dot gnu dot org 2006-07-24 02:58 ---
Subject: Bug 28460
Author: drow
Date: Mon Jul 24 02:58:08 2006
New Revision: 115703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115703
Log:
PR c++/28460
* decl.c (grokvardecl): Use
--- Comment #3 from drow at gcc dot gnu dot org 2006-07-24 03:00 ---
Subject: Bug 27473
Author: drow
Date: Mon Jul 24 02:59:36 2006
New Revision: 115704
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115704
Log:
PR debug/27473
* dbxout.c (output_used_types_helper
--- Comment #2 from drow at gcc dot gnu dot org 2006-07-26 13:11 ---
Subject: Re: ext/pb_ds/regression/tree_data_map_rand.cc fails with a
particular random seed.
On Wed, Jul 26, 2006 at 11:26:01AM -, pcarlini at suse dot de wrote:
Out of curiosity, can you try whether changing
--- Comment #12 from drow at gcc dot gnu dot org 2006-07-26 13:59 ---
It is a cgraph change. There were several patches affecting cgraph_remove_node
during this time period; it was probably one of those. The problem is that we
throw away the body of the abstract copy
--- Comment #10 from drow at gcc dot gnu dot org 2006-08-01 02:47 ---
Subject: Re: C++ (throw() and catch(...) {/* fall through */ } ) and pthread
cancellation are incompatible (at least with NPTL)
On Tue, Aug 01, 2006 at 02:13:08AM -, jason at gcc dot gnu dot org wrote:
Finally
--- Comment #12 from drow at gcc dot gnu dot org 2006-08-01 13:02 ---
Subject: Re: C++ (throw() and catch(...) {/* fall through */ } ) and pthread
cancellation are incompatible (at least with NPTL)
On Tue, Aug 01, 2006 at 07:10:53AM -, jason at redhat dot com wrote:
[What does
--- Comment #10 from drow at gcc dot gnu dot org 2006-08-01 14:24 ---
Subject: Bug 23336
Author: drow
Date: Tue Aug 1 14:23:58 2006
New Revision: 115853
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115853
Log:
gcc/
PR debug/23336
* c-typeck.c
--- Comment #2 from drow at gcc dot gnu dot org 2006-08-02 13:32 ---
Subject: Bug 28063
Author: drow
Date: Wed Aug 2 13:31:56 2006
New Revision: 115874
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115874
Log:
gcc/
PR debug/28063
* dwarf2out.c
--- Comment #11 from drow at gcc dot gnu dot org 2006-08-02 13:35 ---
Fixed for 4.2.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.0
--- Comment #3 from drow at gcc dot gnu dot org 2006-08-02 13:37 ---
Now fixed in 4.2; nothing else affected.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from drow at gcc dot gnu dot org 2005-11-30 16:02 ---
However, I think this is a convincing reason for the patch to merged to at
least 4.1.0.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from drow at gcc dot gnu dot org 2005-12-16 20:38 ---
Since he did:
http://gcc.gnu.org/ml/gcc/2005-12/msg00357.html
I'm just going to close this.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from drow at gcc dot gnu dot org 2006-01-21 16:18 ---
I tested this with both HEAD (to become 4.2.0) and the 4.0 branch (4.0.3). It
worked in both cases. My guess would be that either your arm-thumb-elf-gcc was
built with multilibs disabled, or else the thumb libgcc
--- Comment #3 from drow at gcc dot gnu dot org 2006-01-21 16:27 ---
I don't have G++ 3.4 handy at the moment. 3.3 emits about three and a half
times as large of a .debug_info section as 4.0, however, so I believe this is
fixed.
There's still lots of unneeded debug information output
--- Comment #4 from drow at gcc dot gnu dot org 2006-01-21 16:37 ---
Oops, not so clear after all.
Debug information for Class1 is no longer emitted, but debug information for
Class1::var1 is still emitted. It just doesn't trigger the output of the
containing class any more.
If I add
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-03 15:51
---
FWIW, the reason this leaves a bad taste in my mouth is that I strongly believe
symbol visibility should be consistent between ELF platforms. There's at least
one ELF platform where resolving a function
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-08 19:27
---
Here's another related testcase. If you uncomment the store to global_int,
LIM will move only func_const out of the loop. With them both commented
out, however, the pure call gets moved out of the loop
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-08 19:36
---
Here's another one. This may be a different bug. Suppose we have two pure
functions, one which checks whether a library is present and one which fetches
some piece of data from the library. Code looks like
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-13 20:05
---
That's a pretty useless definition of pure functions - they may read global
memory, but not dereference any pointers which are invalid at any point in
the life of the program?
--
http://gcc.gnu.org
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-13 20:13
---
I've suggested when talking to someone else about this that they should be
assumed not to trap at the points where they are called. That would allow
calls to them to be removed, although still limit code
--- Additional Comments From drow at gcc dot gnu dot org 2004-10-20 19:42 ---
Appears to be gone with current HEAD. A number of new problems appeared, which
I will report separately.
--
What|Removed |Added
at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18089
--- Additional Comments From drow at gcc dot gnu dot org 2004-10-20 20:01 ---
Created an attachment (id=7389)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7389action=view)
Testcase.
valgrind --db-attach=yes gcc/stage2/cc1 -fpreprocessed ggc-common2.i -quiet -O1
-o ggc-common.s
1 - 100 of 228 matches
Mail list logo
