--- Comment #25 from steven at gcc dot gnu dot org 2006-01-12 22:56 ---
I can not reproduce this ICE. We really need some way to reproduce the problem
that Mustafa's patch was supposed to fix.
I use a cross-compiler from AMD64 to ppc:
GNU C version 4.2.0 20060112 (experim
--- Comment #28 from steven at gcc dot gnu dot org 2006-01-13 17:48 ---
I am unable to reproduce the PowerPC SMS ICE with an AMD64 x PowerPC compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--- Comment #29 from steven at gcc dot gnu dot org 2006-01-13 17:56 ---
Re. comment #26, Dave: I think that Mustafa's patch is actually correct, but
I'm not sure. I _can_ reproduce the HPPA problem (at least, I used to be able
to reproduce it when I still had access to a HPPA
--- Comment #30 from steven at gcc dot gnu dot org 2006-01-13 18:51 ---
I wonder if HP-PA should not just make targetm.cannot_modify_jumps_p return
true after reload...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--- Comment #31 from steven at gcc dot gnu dot org 2006-01-13 19:24 ---
First, we need the following patch to try_simplify_condjump.
-
Index: cfgcleanup.c
--- Comment #2 from steven at gcc dot gnu dot org 2006-01-13 21:30 ---
I wonder if this problem can also be triggered without using two variables of
the same union type. There is code in add_alias_set_conflicts to avoid the
situation we're running into:
static
--- Comment #35 from steven at gcc dot gnu dot org 2006-01-13 22:09 ---
After too much trial-and-error, and thinking about it some more, I think we
should approach this as a SMS or powerpc bug. The code that Mustafa changed
makes us reject the RTL equivalent of "if (a) goto
--- Comment #37 from steven at gcc dot gnu dot org 2006-01-13 23:26 ---
I think I know what the problem is. At the point where we error in cfgrtl, we
have the following basic block:
Breakpoint 3, rtl_verify_flow_info_1 () at cfgrtl.c:2051
2051 error ("wrong amou
--- Comment #38 from steven at gcc dot gnu dot org 2006-01-13 23:28 ---
s/which is not supposed to appear on trees/which is not supposed to appear on
RTL/
The EDGE_{TRUE,FALSE}_VALUE flags are for tree-ssa only. On RTL they have no
meaning. We should probably add a check for this in
--- Comment #39 from steven at gcc dot gnu dot org 2006-01-13 23:39 ---
We should do the following:
Index: cfgloopmanip.c
===
--- cfgloopmanip.c (revision 108361)
+++ cfgloopmanip.c (working copy)
@@ -1419,7
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-14 00:10 ---
Hmm, not sure... Consider this modified test case:
nion setconflict
{
short a[20];
int b[10];
};
int
foo (void)
{
int sum = 0;
{
struct A { union setconflict u; } a;
short *c;
c = a.u.a
--- Comment #8 from steven at gcc dot gnu dot org 2006-01-14 12:22 ---
Mark,
Re. your comment #5, I think everyone respects your request that only the RM
sets priorities. But right now the RM fails to do so.
I have also set priorities on a number of bugs that obviously have the wrong
--- Comment #16 from steven at gcc dot gnu dot org 2006-01-14 13:56 ---
With this patch we force the alignment, but I have to admit I have no idea if
this approach is correct. The only other place in stor-layout.c where we look
at EMPTY_FIELD_BOUNDARY is in layout_decl, but that code
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-14 13:57 ---
If the approach is good, we should at least be checking (DECL_BIT_FIELD
(field)) also before forcing things...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #18 from steven at gcc dot gnu dot org 2006-01-14 14:48 ---
This code in layout_decl looks suspicous:
/* Should this be controlled by DECL_USER_ALIGN, too? */
if (maximum_field_alignment != 0)
DECL_ALIGN (decl) = MIN (DECL_ALIGN (decl
--- Comment #19 from steven at gcc dot gnu dot org 2006-01-14 15:17 ---
On AMD64, EMPTY_FIELD_BOUNDARY is 64 bits, so if we honnor that for the
zero-length bitfield, we get a size of 12 for the struct in the test case in
comment #9 (where we apparently expect 8, which is what you get
--- Comment #20 from steven at gcc dot gnu dot org 2006-01-14 15:35 ---
Indeed, in GCC 3.2 ("GNU C version 3.2.3 (x86_64-unknown-linux-gnu)") initially
we have a DECL_ALIGN of 64 bits for the zero-length bitfield when we enter
field_decl:
Breakpoint 2, place_field (rli=0xa15
--- Comment #21 from steven at gcc dot gnu dot org 2006-01-14 15:55 ---
Created an attachment (id=10641)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10641&action=view)
Fix x86_field_alignment for AMD64 zero-length bitfields; try to revert to
pre-jason ABI
So I'll
--- Comment #16 from steven at gcc dot gnu dot org 2006-01-14 16:59 ---
This is still not fixed on mainline, even with the new df implementation. The
code to record them is not executed (at least, not on AMD64). The function
responsible for recording them is df_bb_refs_record
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-14 17:24 ---
Created an attachment (id=10642)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10642&action=view)
Fix df-scan.c
There doesn't seem to be a good reason to make adding the artificial
--- Comment #44 from steven at gcc dot gnu dot org 2006-01-14 18:18 ---
Dave, this is another comment that isn't helpful. What is wrong in the
assembler output for comment #42, what do you expect the assembler output to
look like, how is the problem related to this bug (if it is)
--- Comment #48 from steven at gcc dot gnu dot org 2006-01-14 21:10 ---
I certainly don't see any way how this new issue has anything to do with the
ICE due to Mustafa's patch.
There's an easy check: is the code semantically equivalent to some other
compiler you trust
--- Comment #51 from steven at gcc dot gnu dot org 2006-01-15 00:47 ---
*sigh*
Almost no-one knows HPPA assembly these days. It completely puzzles me why you
call the assembler output "wrong" if you're not specifically stating what
you're expecting instead. But th
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-15 01:03 ---
Ping!
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #53 from steven at gcc dot gnu dot org 2006-01-15 04:05 ---
FWIW, the part of the C99 standard that talk about uninitialized automatic
variables are 3.17.2, 6.2.4, 6.7.8 (especially point 10), and 6.8.
Also see Appendix J2 "Undefined behavior".
To me, undefine
--- Comment #55 from steven at gcc dot gnu dot org 2006-01-15 09:22 ---
The "leap" indeterminate to uninitialized is simply C99 3.4.3:
1. undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of
erroneous data, for which this Internationa
--- Comment #15 from steven at gcc dot gnu dot org 2006-01-15 23:22 ---
I don't recall the results of testing this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
--- Comment #58 from steven at gcc dot gnu dot org 2006-01-16 21:52 ---
Re. comment #56,
Richard, only the patch of comment #39 is necessary to fix this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--- Comment #7 from steven at gcc dot gnu dot org 2006-01-16 22:32 ---
It's your bug. If you're happy with the current numbers, you should close the
bug as FIXED.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
--- Comment #24 from steven at gcc dot gnu dot org 2006-01-16 23:31 ---
Realistically, I don't think it's safe to still fix this for GCC 4.1. The
whole thing looks so complicated (to me at least) that the risk of introducing
new bugs just before the release is significa
--- Comment #25 from steven at gcc dot gnu dot org 2006-01-16 23:33 ---
Re. comment #23, iiuc the old behavior was to align the zero-length bitfield,
not the next field. My patch (one of them anyway) switches the order of
EMPTY_FIELD_BOUNDARY and PCC_BITFIELD_TYPE_MATTERS back to how
--- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08 ---
We should at least avoid introducing a third variant of how we lay out these
nasty zero-sized friends. People actually use them. For example Wine uses
them to enforce compatible alignment and data layout with MS
--- Comment #34 from steven at gcc dot gnu dot org 2006-01-19 17:40 ---
I looked up a few links to see how people use zero-length bit-fields and what
semantics they're expecting. I mostly found links to compiler documentation
about how other compilers interpret these bit-f
--- Comment #60 from steven at gcc dot gnu dot org 2006-01-20 00:06 ---
I've tested it on x86_64-unknown-linux-gnu and mips-elf (simulator, C only).
Richi, I would have commited the patch for this myself as obvious, with a
comment explaining why we have to call ir_type there
--- Comment #63 from steven at gcc dot gnu dot org 2006-01-20 12:05 ---
I still think there should be a comment in cfgloopmanip explaining the use of
ir_type there, but I'll take care of that with the additional-checking patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-19 23:03 ---
Wrong code. Bad.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-19 23:08 ---
Andrew, you're wrong. :-P
My gfortran skills are not what they used to be, but I believe this is the fix:
Index: trans-stmt.c
===
--- trans-s
--- Comment #1 from steven at gcc dot gnu dot org 2006-07-20 19:53 ---
Confirmed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-20 21:17 ---
>From the tree dumps, it would appear we totally mis-handle omitted arguments:
;; Function MAIN__ (MAIN__)
MAIN__ ()
{
:
_gfortran_set_std (70, 127, 0);
test_present (&C.1239, &C.1240);
test_prese
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-20 21:29 ---
Could this be a dup of the now-fixed Bug 28410 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-20 21:34 ---
Ping!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
--- Comment #5 from steven at gcc dot gnu dot org 2006-07-21 23:34 ---
Lahey agrees that this is invalid code:
1program test_string_present
2
3call test_present(1, "foo")
4call test_present(2)
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-21 23:39 ---
The definition of gfc_evaluate_now is:
trans.h:tree gfc_evaluate_now (tree, stmtblock_t *);
And the effect of adding &se.pre is to add the code to the block. You can see
this going on everywhere in gfortran wi
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-22 09:39 ---
Is this really such a big deal? Solaris uses DWARF, and so does Apple now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-22 11:08 ---
In the greg dump we have this RTL:
(insn:HI 10 8 11 2 (parallel [
(set (reg:SI 58 [ D.1540 ])
(plus:SI (reg/v:SI 5 di [ reg ])
(const_int -4 [0xfffc
--- Comment #5 from steven at gcc dot gnu dot org 2006-07-22 16:36 ---
We do the loop-and-putc thing in ASM_OUTPUT_LIMITED_STRING and in
dw2_asm_output_nstring as well. Probably it's best to add some kind of generic
"escaped string" print function, something like the
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-23 11:51 ---
Consider these lines in elfos.h:ASM_OUTPUT_ASCII:
\
for (p = _ascii_bytes; p < limit && *p
--- Comment #7 from steven at gcc dot gnu dot org 2006-07-23 13:11 ---
Happens on at least all the targets that includes elfos.h, cris/aout.h,
i386/ptx4-i.h, i386/i386-interix.h, i386/sysv4.h, i386/i386elf.h.
I'm only fixing elfos.h, but others can copy over the same
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-23 14:54 ---
Created an attachment (id=11925)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11925&action=view)
proposed fix, nukes quadratic behavior
needs detailed testing, but this cuts the time spent in deb
--- Comment #1 from steven at gcc dot gnu dot org 2006-07-23 15:22 ---
Yup. And a regression too because previous GCCs could dump without sending your
machine to swap space land.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-23 17:56 ---
Subject: Bug 25468
Author: steven
Date: Sun Jul 23 17:56:34 2006
New Revision: 115685
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115685
Log:
2006-07-23 Steven Bosscher <[EMAIL PROTECTED]&g
--- Comment #10 from steven at gcc dot gnu dot org 2006-07-23 17:57 ---
Fixed on the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-23 18:05 ---
Jakub, ping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25938
--- Comment #3 from steven at gcc dot gnu dot org 2006-07-24 05:29 ---
Yup. New feature lacking documentation. We've always treated those as
documentation quality regressions.
So confirmed.
--
steven at gcc dot gnu dot org changed:
What|Re
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-24 05:46 ---
gcc -v shows that only the last -fno-builtin-* is passed to cc1:
$ /xgcc -B. -fno-builtin-iswalpha -fno-builtin-iswalnum -c b.c -v
Reading specs from ./specs
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk
--- Comment #5 from steven at gcc dot gnu dot org 2006-07-24 20:52 ---
Works with "GCC: (GNU) 4.1.1 20060518 (prerelease)".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-24 21:46 ---
Also works with "GCC: (GNU) 4.1.2 20060724 (prerelease)", but fails with "GCC:
(GNU) 4.2.0 20060723 (experimental)".
So my guess is: HJ, no your patch is not in the FSF GCC 4.1 but it is in the
--- Comment #7 from steven at gcc dot gnu dot org 2006-07-24 21:47 ---
Not an FSF GCC 4.1 bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-24 21:51 ---
HJ definitely caused this bug:
Starting program: /home/steven/devel/build-trunk-test/gcc/xgcc -B.
-fno-builtin-iswalpha -fno-builtin-iswalnum -S b.c
Breakpoint 2, main (argc=6, argv=0x7fc7bbb8) at gcc.c:6096
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-24 22:13 ---
Created an attachment (id=11932)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11932&action=view)
Don't prune options that can be "Joined"
Seems to me like pruning Joined options is
--- Comment #68 from steven at gcc dot gnu dot org 2006-07-25 22:31 ---
New timings. These were taken on the same box as those of comment #62 and
comment #64 (Intel x86_64 3.20GHz, 1GB ram). Times are usr times
Invokation: time g++ -S -fpermissive -Ox -m64 generate-3.4.ii
GC params
--- Comment #69 from steven at gcc dot gnu dot org 2006-07-25 22:35 ---
Re. comment #68, I should have added that all compilers were built with "gcc
(GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)" with CFLAGS="-O2 -g".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-25 22:52 ---
In the .104.expand dump we have:
(insn 10 9 11 3 (set (reg/f:SI 63)
(label_ref:SI 16)) -1 (nil)
(insn_list:REG_LABEL 16 (nil)))
and
;; Start of basic block 4, registers live: (nil)
(code_label 16 15 52
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-27 13:25 ---
Thanks Volkert. I had a test case like that, I should have put it in this
audit trail.
I am *so* going to fix this bug. I think...
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from steven at gcc dot gnu dot org 2006-07-29 00:32 ---
Seems like a bug to me alright.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-29 00:41 ---
Is it necessary to wait with posting until the copyright assignment process is
finished, or can the patch be posted for a first review before the assignment
is on file?
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-29 10:32 ---
Zdenek's patch also can't be responsible for this. He probably also just
uncovered latent bugs.
Instead of pointing at random patches, it would be much more helpful to analyze
what is going wrong. For th
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-29 10:57 ---
Please stop adding test cases!!! :-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2006-07-30 10:52 ---
Please ping the patch. Add DJ Delorie to the CC: list, he is a build system
maintainer. You can find his email in MAINTAINERS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-30 23:12 ---
Shame on us for following the gut feeling instead of the Standard.
As Steve Kargl pointed out on the mailing list:
F95 standard, Section 9.3.5, page 143, lines 6 an 7.
Execution of a CLOSE statement specify a
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[4.1 only] flush() / write()|[4.2 Regression
--- Comment #11 from steven at gcc dot gnu dot org 2006-07-31 22:08 ---
Subject: Bug 25468
Author: steven
Date: Mon Jul 31 22:08:47 2006
New Revision: 115841
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115841
Log:
PR debug/25468
Backport from
--- Comment #12 from steven at gcc dot gnu dot org 2006-07-31 22:13 ---
Fixed in GCC 4.2 and GCC 4.1. But I am not interested in fixing this in GCC
4.0, so I'm finished with this bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.2 |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
--- Comment #10 from steven at gcc dot gnu dot org 2006-08-01 05:51 ---
Why is this a P1 regression? ia-64 is not a primary platform.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2006-08-02 19:03 ---
There are a million reasons why labels can disappear in GCC. This happens
because GCC deletes or keeps labels based on ref counting (LABEL_NUSES and
friends) and this is just too fragile.
The way for you to narrow
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from steven at gcc dot gnu dot org 2006-08-02 20:52 ---
;; Insn is not within a basic block
(code_label 48 47 49 11 "" [3 uses])
;; Insn is not within a basic block
(jump_insn 49 48 50 (addr_diff_vec:DI (label_ref:DI 48)
[
(label_
--- Comment #8 from steven at gcc dot gnu dot org 2006-08-02 21:10 ---
Happens when we are in find_if_case_1, where we call:
delete_basic_block (then_bb);
The basic block we try to remove is this one:
;; basic block 5, loop depth 1, count 0
;; prev block 9, next block 6
;; pred
--- Comment #6 from steven at gcc dot gnu dot org 2006-08-20 00:46 ---
Eric, can this bug be closed as FIXED now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25217
--- Comment #4 from steven at gcc dot gnu dot org 2006-08-28 13:59 ---
>From the hammer branch for AMD64:
.globl f
.type f, @function
f:
.LFB4:
testl %edi, %edi
movl%esi, %eax
jne .L3
movl%edx, %esi
movl%edx, %eax
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #3 from steven at gcc dot gnu dot org 2006-08-29 19:52 ---
I seem to have accepted this bug instead of confirming it. That wasn't my
intention.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #70 from steven at gcc dot gnu dot org 2006-09-03 10:39 ---
Based on my numbers of comment #69, I'm declaring this fixed once more.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #31 from steven at gcc dot gnu dot org 2006-09-03 11:05 ---
"real" times for hashes100.c (x86_64-linux, Intel Xeon 3.2 GHz, 1GB RAM):
3.4.6 4.0.4 4.1.2 4.2-svn20060724
-O0 0m1.618s 0m1.762s 0m1.661s 0m1.645s
-O1 0m2.743s
--- Comment #32 from steven at gcc dot gnu dot org 2006-09-03 11:37 ---
Just to be sure that between 7/24 and today we didn't speed up significantly:
"real" times for hashes100.c (x86_64-linux, Intel Xeon 3.2 GHz, 1GB RAM):
3.4.6 4.2-svn20060903delta
-
--- Comment #33 from steven at gcc dot gnu dot org 2006-09-03 11:41 ---
FWIW, the oprofile for both test cases is basically flat, nothing stands out.
We just do _so_ much more work (many more passes without removing anything) and
that hurts apparently (not surprising of course
--- Comment #35 from steven at gcc dot gnu dot org 2006-09-03 17:28 ---
Even if we did not hash SCEV data a lot, it would not buy you >50%.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-07 17:36 ---
Quadratic (or worse?) behavior
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-08 20:32 ---
See http://gcc.gnu.org/wiki/DebuggingGCC
Please stop asking questions here and try to figure out something for yourself,
from the wiki, from the documentation, by experimenting, or when all else
fails, on the
--- Comment #24 from steven at gcc dot gnu dot org 2006-09-09 10:54 ---
Closing because mainline is faster than 4.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15678
--- Comment #25 from steven at gcc dot gnu dot org 2006-09-09 10:54 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from steven at gcc dot gnu dot org 2006-09-09 15:32 ---
Paolo already said he won't backport his patch. And it seems like a bad idea
to backport reload patches to release branches. So closing this bug as FIXED
for mainline.
--
steven at gcc dot gnu dot org ch
--- Comment #9 from steven at gcc dot gnu dot org 2006-09-10 10:59 ---
In GCC3, the label is not removed because it is in label_value_list. In GCC4
we don't have that list anymore. That means we have to trust LABEL_NUSES, or we
have to force preservation of the labe
601 - 700 of 3051 matches
Mail list logo
