n: 4.1.1
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/show_bug.cgi?id=27160
ity: 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=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
nent: 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=28063
tr is used only when 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://
ancellation 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:
--- 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, but
--- 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_"
> definition?
I think so, with suitable comment. Some future MIPS architecture may provid
--- Comment #4 from drow at gcc dot gnu dot org 2008-11-14 14:53 ---
Subject: Bug 38014
Author: drow
Date: Fri Nov 14 14:51:38 2008
New Revision: 141859
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141859
Log:
PR bootstrap/38014
PR bootstr
--- Comment #34 from drow at gcc dot gnu dot org 2008-11-14 14:53 ---
Subject: Bug 37923
Author: drow
Date: Fri Nov 14 14:51:38 2008
New Revision: 141859
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141859
Log:
PR bootstrap/38014
PR bootstr
--- Comment #5 from drow at gcc dot gnu dot org 2008-11-14 15:37 ---
Patches reverted. This is really a bug in gmp/mpfr/intl, but no point
triggering it.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from drow at gcc dot gnu dot org 2008-11-14 15:38 ---
Patches reverted. This is really a bug in gmp/mpfr/intl, but no point
triggering it.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from drow at gcc dot gnu dot org 2008-12-06 15:18 ---
I tried 4.4.0 20081130; it does not look fixed.
:
# mult_acc.14_40 = PHI
[break.c : 12] D.2737_41 = value_13 + -1;
[break.c : 12] D.2738_42 = (unsigned int) D.2674_12;
[break.c : 12] D.2739_43 = 2 - D.2738_42
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #14 from drow at gcc dot gnu dot org 2008-12-22 13:46 ---
Part fixed, part refiled.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from drow at gcc dot gnu dot org 2009-01-05 18:34 ---
Right. You would need an arm-elf (not arm-eabi) or arm-linux (not
arm-linux-gnueabi) toolchain to test this. Those are slowly becoming
obsolete...
--
drow at gcc dot gnu dot org changed:
What
--- Comment #2 from drow at gcc dot gnu dot org 2009-05-12 11:36 ---
Sorry, I don't know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35296
--- Comment #5 from drow at gcc dot gnu dot org 2009-05-16 17:31 ---
Subject: Re: ARM -fshort-enums attribute not emitted
for Fortran
On Sat, May 16, 2009 at 04:12:28PM -, fxcoudert at gcc dot gnu dot org
wrote:
> Probably fixed on trunk. Please reopen if not.
Thanks!
ion: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
--- Comment #1 from drow at gcc dot gnu dot org 2009-06-22 15:20 ---
CC'ing some people who know about CFI for opinions on the best resolution. Do
we need a new gas option and/or CFI directive for this?
--
drow at gcc dot gnu dot org changed:
What|Re
--- Comment #2 from drow at gcc dot gnu dot org 2009-06-22 15:22 ---
I've confirmed that older GCC emits both .debug_frame and .eh_frame.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
--- Comment #4 from drow at gcc dot gnu dot org 2009-06-23 12:24 ---
Subject: Re: [4.4/4.5 Regression] -g causes GCC to
generate .eh_frame
On Tue, Jun 23, 2009 at 11:09:48AM -, jakub at gcc dot gnu dot org wrote:
> I think if we don't want to emit .eh_frame, we sho
--- Comment #7 from drow at gcc dot gnu dot org 2009-06-23 15:49 ---
Nope. It would be somewhere between hard and impossible to do in the linker,
because these have to go in the middle of the .text section, and within
compile-time known offsets from the using functions (to accommodate
, Richi suggested on IRC that this might be related to your changes in
inline variable tracking. Any idea?
--
Summary: [4.4/4.5 Regression] DWARF for inlined subroutines
refers to the outlined copy
Product: gcc
Version: 4.5.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/show_bug.cgi?id=40573
--- Comment #1 from drow at gcc dot gnu dot org 2009-06-27 22:12 ---
Created an attachment (id=18083)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18083&action=view)
Test case
Compile with -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573
--- Comment #4 from drow at gcc dot gnu dot org 2009-06-30 14:19 ---
It looks like you're right. Jan K. recently added support to GDB to attach the
unreferenced children of abstract DIEs to each concrete instance, and that
caused my existing test case to fail in a new way.
--
--- Comment #5 from drow at gcc dot gnu dot org 2009-06-30 14:21 ---
(In reply to comment #3)
> Hmm, I tought GCC was doing the same thing for years. So we need
> abstract function for each inline?
Why? I think we each inlined copy (and the outlined copy) to refer to the one
ab
--- Comment #7 from drow at gcc dot gnu dot org 2009-06-30 17:52 ---
Subject: Re: DWARF for inlined subroutines refers to the
outlined copy
On Tue, Jun 30, 2009 at 04:29:25PM -, jakub at gcc dot gnu dot org wrote:
>
>
> --- Comment #6 from jakub at gcc dot gnu dot
--- Comment #9 from drow at gcc dot gnu dot org 2009-06-30 18:59 ---
Subject: Re: DWARF for inlined subroutines refers to the
outlined copy
On Tue, Jun 30, 2009 at 06:13:16PM -, jakub at gcc dot gnu dot org wrote:
> Weird, the difference I get with the patch on the testcase
--- Comment #1 from drow at gcc dot gnu dot org 2009-07-07 15:03 ---
It looks, roughly speaking, like the two nearby addresses are initially
commonized. In the process, the use after the loop ends up sharing a REG with
the use in the loop. Then the use in the loop is changed to use a
--- Comment #3 from drow at gcc dot gnu dot org 2009-07-15 21:30 ---
Hi Steven,
Maybe I'm missing something, but what do patches talking about
SMALL_REGISTER_CLASSES have to do with this issue? For ARM, the registers
involved are general purpose and ! SMALL_REGISTER_CLASSES. Th
--- Comment #17 from drow at gcc dot gnu dot org 2009-07-23 21:50 ---
Steven, have you had time for this? Anything we can do to help?
--
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 |
--- 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-a
ith 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
--- 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
--- 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 |
--- 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 the
--- 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 us
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
GCC host triplet: x86_64-pc-linux-gnu
--- 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 dwar
--- 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
--- 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 fo
--- 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 the
--- 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=gcc&view=rev&rev=115703
Log:
PR c++/28460
* decl.c (grokvarde
--- 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=gcc&view=rev&rev=115704
Log:
PR debug/27473
*
--- 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 chang
--- 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 of the
--- 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
--- 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:
> >
--- 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=gcc&view=rev&rev=115853
Log:
gcc/
PR debug/23336
* 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=gcc&view=rev&rev=115874
Log:
gcc/
PR debug/28063
* dwa
--- 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
NCONFIRMED
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
--
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 preventin
--- 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_1 = PHI ;
The difference in t17.alias1 is that, plus:
-Variable: list, UID 2, int[31], is addressable
--- 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=12141&action=view)
Aliasing fix.
Thank you Janis for the reghunt! Not too hard to track down given that.
I haven't
--- 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 tes
--- 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. Nor
--- 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|Re
--- 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-
--- 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
Version: 4.2.0
Status: UNCONFIRMED
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
gling.
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 |
--- 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
--- 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 the
--- 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
--- 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 t
--- 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 successfu
--- Comment #2 from drow at gcc dot gnu dot org 2007-01-27 20:20 ---
Testing a patch.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #16 from drow at gcc dot gnu dot org 2007-01-28 03:48 ---
Actually, I was wrong - we shouldn't try to make this case work. If you use
$prefix/$target_alias as a sysroot, then /bin/as in your sysroot needs to be a
host-x-target assembler!
Closing instead.
--
drow a
--- Comment #3 from drow at gcc dot gnu dot org 2007-01-28 14:08 ---
Subject: Bug 30469
Author: drow
Date: Sun Jan 28 14:08:13 2007
New Revision: 121257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121257
Log:
PR bootstrap/30469
* Makefile.in
--- Comment #4 from drow at gcc dot gnu dot org 2007-01-28 14:08 ---
Fixed.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from drow at gcc dot gnu dot org 2007-02-09 22:28 ---
Oops! I discovered this problem in testing but never moved the fix back to the
tree I committed from. Sorry for the inconvenience.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30748
--- Comment #5 from drow at gcc dot gnu dot org 2007-02-09 22:34 ---
Subject: Bug 30748
Author: drow
Date: Fri Feb 9 22:33:51 2007
New Revision: 121778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121778
Log:
PR bootstrap/30748
* configure.ac: Correc
--- Comment #6 from drow at gcc dot gnu dot org 2007-02-09 22:37 ---
Should be better now.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from drow at gcc dot gnu dot org 2007-02-10 00:41 ---
What's in config.log?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30753
--- Comment #3 from drow at gcc dot gnu dot org 2007-02-10 01:01 ---
Check earlier? Something must have gone wrong with AC_OBJEXT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30753
--- Comment #5 from drow at gcc dot gnu dot org 2007-02-10 01:36 ---
OK, I see it. The problem is that AC_PROG_CC is invoked inside an if
statement; objext doesn't get set before that point, so it's expanded inside
the if.
If this is covered in the autoconf documentation I
--- Comment #1 from drow at gcc dot gnu dot org 2007-02-11 21:21 ---
What evidence do you have that comparison was not done? bootstrap calls
stage3-bubble which calls make compare.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30767
--- Comment #7 from drow at gcc dot gnu dot org 2007-02-13 13:39 ---
Subject: Bug 30753
Author: drow
Date: Tue Feb 13 13:39:19 2007
New Revision: 121882
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121882
Log:
PR bootstrap/30753
* configure.ac: Remove
--- Comment #8 from drow at gcc dot gnu dot org 2007-02-13 13:40 ---
Should be better now.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status
gned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: mips-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31602
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: mips-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31605
--- Comment #4 from drow at gcc dot gnu dot org 2007-04-20 20:04 ---
Subject: Re: Overflow warning causes GDB
-Werror build failure
On Fri, Apr 20, 2007 at 03:17:19PM -, ian at airs dot com wrote:
> This patch fixes the test case in the PR. I am testing it. It would
1 - 100 of 228 matches
Mail list logo