https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63977
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: ian at airs dot com
Reporter: rth at gcc dot gnu.org
CC: cmang at google dot com
In go_struct_to_ffi, an empty struct is maped to ffi_type_void.
On i386, some ABIs return a struct pop 4 bytes of stack. If one
calls a function returning a structure without preparing for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021
--- Comment #1 from Richard Henderson ---
Oh, that should read "fail after the merge of the new libffi".
Current libffi happens to have nothing interesting in the stack
slot that's incorrectly popped, and to happens not to fail. Not
so with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021
Richard Henderson changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #4 from Richard Hende
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021
--- Comment #6 from Richard Henderson ---
(In reply to Jakub Jelinek from comment #5)
> Isn't that just because in C++ empty structs are forced by the FE into
> having length of one byte?
Yes, of course.
> I mean, if you:
> struct S {};
> int a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021
--- Comment #8 from Richard Henderson ---
(In reply to Ian Lance Taylor from comment #7)
> I note that a zero-sized array is converted to an empty struct in go-ffi.c.
> I wonder how libffi handles that today.
It doesn't. There will be an asser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
--- Comment #5 from Richard Henderson ---
Author: rth
Date: Mon Jun 30 20:14:42 2014
New Revision: 212172
URL: https://gcc.gnu.org/viewcvs?rev=212172&root=gcc&view=rev
Log:
PR rtl-opt/61608
PR target/39284
* bb-reorder.c (pass_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
--- Comment #15 from Richard Henderson ---
Author: rth
Date: Mon Jun 30 20:14:42 2014
New Revision: 212172
URL: https://gcc.gnu.org/viewcvs?rev=212172&root=gcc&view=rev
Log:
PR rtl-opt/61608
PR target/39284
* bb-reorder.c (pass_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840
Richard Henderson changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840
--- Comment #9 from Richard Henderson ---
Created attachment 33105
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33105&action=edit
corrected test case
I believe that the original test case is in fact invalid.
Every asm goto has N labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840
Richard Henderson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2014-09-25
CC||rth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Henderson ---
Confirmed. Given the pointer to cgo/out.go above, the patch for this at
https://launchpadlibrarian.net
||2014-09-25
CC||rth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Henderson ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #4 from Richard Henderson ---
I think we should rather handle this in the front end than with
quite complex pattern matching.
If we want to do any complex logic with atomics in the middle-end,
we should change their representation so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68964
--- Comment #3 from Richard Henderson ---
The path on which this test goes off the rails is supposed to only
be used for structure assignments, where memmove must be used, and
thus taking the address of both sides of the assignment will work.
Ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68964
--- Comment #4 from Richard Henderson ---
Oh, yes, duh.
These vector types are (at least partially) target-specific, and so the
function definitions are left for the target to fill in at startup time.
See config/i386/i386.c bdesc_tm for MMX/SSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67811
--- Comment #3 from Richard Henderson ---
Author: rth
Date: Tue Dec 22 19:42:24 2015
New Revision: 231907
URL: https://gcc.gnu.org/viewcvs?rev=231907&root=gcc&view=rev
Log:
PR ipa/67811
* gimple.h (struct gtransaction): Add label_norm,
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org
--- Comment #4 from Richard Henderson ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67811
--- Comment #5 from Richard Henderson ---
Author: rth
Date: Thu Dec 24 00:45:15 2015
New Revision: 231943
URL: https://gcc.gnu.org/viewcvs?rev=231943&root=gcc&view=rev
Log:
PR ipa/67811
* tree-cfg.c (make_edges_bb): Add abort edge for outer tr
||rth at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org
--- Comment #10 from Richard Henderson ---
Created attachment 37267
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37267&action=edit
proposed patch
Andrew is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69176
Richard Henderson changed:
What|Removed |Added
Attachment #37267|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69176
--- Comment #14 from Richard Henderson ---
(In reply to Wilco from comment #12)
> The only remaining question I had whether it would be possible to use
> peephole expansions rather than the late splits. If they are evaluated in
> order then if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69176
--- Comment #16 from Richard Henderson ---
(In reply to Wilco from comment #15)
> The final split happens a few phases later, so I wondered whether it would
> be feasible to do all the splitting during peep2. There is likely no real CQ
> gain in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102
--- Comment #2 from Richard Henderson ---
The only additional deps in this entire function by the
quoted patch are three sequential insns involved in a call
that use REG_ARGS_SIZE. But all of these are well-removed
from the ICE.
The instruction
||rth at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #29 from Richard Henderson ---
Yes, I've re-tested all of the test case snipits herein
and they all pass with current mainline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69246
--- Comment #9 from Richard Henderson ---
There wouldn't be anything wrong with REG_ARGS_SIZE on a
call_pop pattern in and of itself -- in fact I'd expect it.
I don't know if it's worth generating one for a sibcall;
it might be easier to treat i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68964
--- Comment #5 from Richard Henderson ---
Author: rth
Date: Wed Jan 13 17:03:42 2016
New Revision: 232330
URL: https://gcc.gnu.org/viewcvs?rev=232330&root=gcc&view=rev
Log:
PR 68964
gcc/
PR tree-opt/68964
* target.def (builtin_tm_load, builti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63890
--- Comment #22 from Richard Henderson ---
I believe that Honza is over-thinking this in #c12.
Mike reports that the patch in #c9 works, which makes
sense to me based on where darwin emits its profiler call.
The patch could be improved to note t
||rth at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org
--- Comment #10 from Richard Henderson ---
I concur that doloop has performed an invalid transformation.
We should be able to detect the clobber of a live register in
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69014
--- Comment #11 from Richard Henderson ---
Created attachment 37336
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37336&action=edit
proposed patch
This appears to work on this test case, producing the expected
Doloop: doloop pattern cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69014
Richard Henderson changed:
What|Removed |Added
Attachment #37336|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69272
Richard Henderson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67145
--- Comment #9 from Richard Henderson ---
For x86, we have one pattern, and it has things in the correct order.
For aarch64, the only correct pattern is add3_carryin_alt2.
The nesting and canonicalization of all the others are bogus.
But powerp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69272
--- Comment #5 from Richard Henderson ---
Author: rth
Date: Thu Jan 14 21:36:12 2016
New Revision: 232390
URL: https://gcc.gnu.org/viewcvs?rev=232390&root=gcc&view=rev
Log:
PR c/69272
PR tree-opt/68964
* trans-mem.c (tm_log_emit_stmt): Fix un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68964
--- Comment #7 from Richard Henderson ---
Author: rth
Date: Thu Jan 14 21:36:12 2016
New Revision: 232390
URL: https://gcc.gnu.org/viewcvs?rev=232390&root=gcc&view=rev
Log:
PR c/69272
PR tree-opt/68964
* trans-mem.c (tm_log_emit_stmt): Fix un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69272
Richard Henderson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68964
Richard Henderson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69014
--- Comment #13 from Richard Henderson ---
Author: rth
Date: Thu Jan 14 23:12:53 2016
New Revision: 232395
URL: https://gcc.gnu.org/viewcvs?rev=232395&root=gcc&view=rev
Log:
PR rtl-opt/69014
* loop-doloop.c (record_reg_sets): New.
(doloop_o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69176
--- Comment #17 from Richard Henderson ---
Author: rth
Date: Mon Jan 18 20:56:13 2016
New Revision: 232540
URL: https://gcc.gnu.org/viewcvs?rev=232540&root=gcc&view=rev
Log:
PR target/69176
* config/aarch64/aarch64.md (add3): Move long immedi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69176
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org
--- Comment #10 from Richard Henderson ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69339
--- Comment #1 from Richard Henderson ---
Author: rth
Date: Wed Jan 20 18:53:56 2016
New Revision: 232631
URL: https://gcc.gnu.org/viewcvs?rev=232631&root=gcc&view=rev
Log:
PR bootstrap/69343
PR bootstrap/69339
PR tree-opt/68964
Revert:
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68964
--- Comment #9 from Richard Henderson ---
Author: rth
Date: Wed Jan 20 18:53:56 2016
New Revision: 232631
URL: https://gcc.gnu.org/viewcvs?rev=232631&root=gcc&view=rev
Log:
PR bootstrap/69343
PR bootstrap/69339
PR tree-opt/68964
Revert:
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69343
--- Comment #2 from Richard Henderson ---
Author: rth
Date: Wed Jan 20 18:53:56 2016
New Revision: 232631
URL: https://gcc.gnu.org/viewcvs?rev=232631&root=gcc&view=rev
Log:
PR bootstrap/69343
PR bootstrap/69339
PR tree-opt/68964
Revert:
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69343
Richard Henderson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69339
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rth at gcc dot gnu.org
Target Milestone: ---
aarch64 currently fails bootstrap in stage2 with
libtool: compile: /localhome/devel/rth/gcc/bld-orig/./gcc/xgcc
-B/localhome/devel/rth/gcc/bld-orig/./gcc/
-B/usr/local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416
Richard Henderson changed:
What|Removed |Added
Keywords||build, ice-checking,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416
--- Comment #3 from Richard Henderson ---
(In reply to Wilco from comment #2)
> It doesn't list the substitution before simplification, but it should be:
>
> (set (reg:SI 465)
> (gtu:SI
> (if_then_else:CC (ne (reg:SI 1002 [ ref_309(D)->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416
--- Comment #5 from Richard Henderson ---
Created attachment 37419
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37419&action=edit
proposed patch
I'm testing the following, but it does produce correct results
on a spot check of emit-rtl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416
--- Comment #9 from Richard Henderson ---
Author: rth
Date: Fri Jan 22 17:21:41 2016
New Revision: 232737
URL: https://gcc.gnu.org/viewcvs?rev=232737&root=gcc&view=rev
Log:
PR target/69416
* config/aarch64/aarch64.md (UNSPEC_NZCV): New.
(cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69305
--- Comment #12 from Richard Henderson ---
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01829.html
|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org
||rth at gcc dot gnu.org
--- Comment #3 from Richard Henderson ---
This is a register allocation problem.
From the ira dump:
(insn 17 16 18 2 (set (reg/v:DI 111 [ u64_3 ])
(mult:DI (zero_extend:DI (reg:SI 183 [ u64_3 ]))
(zero_extend:DI (reg:SI 183 [ u64_3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60908
--- Comment #6 from Richard Henderson ---
Author: rth
Date: Tue Jan 26 17:29:02 2016
New Revision: 232839
URL: https://gcc.gnu.org/viewcvs?rev=232839&root=gcc&view=rev
Log:
PR middle-end/60908
* trans-mem.c (tm_region_init): Mark entry block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60908
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447
--- Comment #5 from Richard Henderson ---
This appears to be exposed by lra-remat, but not
the location of the bug.
Before remat:
Insn 55: point = 3
...
Insn 17: point = 26
r111: [4..26]
After remat:
Inserting rematerialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447
--- Comment #6 from Richard Henderson ---
... except that's not the same set of live ranges
computed by IRA:
Insn 55(l0): point = 9
Insn 70(l0): point = 11
...
Insn 50(l0): point = 19
...
Insn 21(l0): point = 61
Insn 19(l0):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842
Richard Henderson changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842
--- Comment #7 from Richard Henderson ---
(In reply to Bin Fan from comment #6)
> Could you clarify what does aliased pages mean? Do you mean the same object
> is mapped into two or more different processes with different virtual
> addresses? And
|unassigned at gcc dot |rth at gcc dot gnu.org
|gnu.org |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #4 from Richard H
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
--- Comment #5 from Richard Henderson 2011-03-08
00:44:41 UTC ---
Author: rth
Date: Tue Mar 8 00:44:37 2011
New Revision: 170768
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170768
Log:
PR 47952
* trans-mem.c (tm_mangle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
Richard Henderson changed:
What|Removed |Added
Status|WAITING |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
--- Comment #7 from Richard Henderson 2011-03-08
22:27:31 UTC ---
The name isn't being properly demangled. Although this ought not
matter for correctness; what matters is that the group name is
consistent across all uses, and that functions that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
--- Comment #9 from Richard Henderson 2011-03-09
21:14:51 UTC ---
Author: rth
Date: Wed Mar 9 21:14:45 2011
New Revision: 170836
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170836
Log:
PR 47952
include/
* demangle.h (enum gnu_v3_c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
--- Comment #10 from Richard Henderson 2011-03-09
23:01:38 UTC ---
The remaining problem in the full glob2 test is
src/Unit.o: In function `transaction clone for Unit::~Unit()':
Unit.cpp:(.text._ZGTtN4UnitD2Ev[transaction clone for Unit::~Unit(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
--- Comment #13 from Richard Henderson 2011-03-10
23:04:11 UTC ---
Author: rth
Date: Thu Mar 10 23:04:05 2011
New Revision: 170854
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170854
Log:
PR 47952
* trans-mem.c (ipa_tm_create_versio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48021
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
--- Comment #14 from Richard Henderson 2011-03-10
23:42:10 UTC ---
*** Bug 48021 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
--- Comment #15 from Richard Henderson 2011-03-10
23:45:53 UTC ---
(In reply to comment #12)
> Should I fill a new PR for this even if I don't have any real testcase?
Yes please.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075
--- Comment #1 from Richard Henderson 2011-03-12
22:03:29 UTC ---
It is not TM related. If you remove the TM constructs, the test case
still crashes with stack overflow in mainline. Of course, there are
a number of errors produced beforehand, w
||2011.03.12 22:23:34
AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Richard Henderson 2011-03-12
22:23:34 UTC ---
Confirmed.
The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48074
--- Comment #2 from Richard Henderson 2011-03-12
22:58:25 UTC ---
Author: rth
Date: Sat Mar 12 22:58:23 2011
New Revision: 170911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170911
Log:
PR 48074
* trans-mem.c (ipa_tm_transform_tran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48074
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381
--- Comment #17 from Richard Henderson 2011-03-18
20:20:01 UTC ---
Author: rth
Date: Fri Mar 18 20:19:45 2011
New Revision: 171164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171164
Log:
PR bootstrap/45381
* lex.c [ALTIVEC] (search_lin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381
--- Comment #18 from Richard Henderson 2011-03-18
20:20:45 UTC ---
Author: rth
Date: Fri Mar 18 20:20:35 2011
New Revision: 171165
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171165
Log:
PR bootstrap/45381
* lex.c [ALTIVEC] (search_lin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381
Richard Henderson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
||2011.04.01 16:08:12
AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Richard Henderson 2011-04-01
16:08:12 UTC ---
Probably my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
--- Comment #5 from Richard Henderson 2011-04-01
18:15:50 UTC ---
Created attachment 23847
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23847
proposed patch
Re #c2: It's good to know that Apple is just as forgiving with
extensions to an e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
--- Comment #6 from Richard Henderson 2011-04-01
20:23:04 UTC ---
Author: rth
Date: Fri Apr 1 20:23:00 2011
New Revision: 171852
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171852
Log:
PR 48400
* dwarf2out.c (dwarf2out_source_line): D
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
Richard Henderson changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #9 from Richard H
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
--- Comment #11 from Richard Henderson 2011-04-02
00:45:46 UTC ---
Well, then someone will have to debug this somehow; it really looks
like we're producing the same output before and after...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
--- Comment #16 from Richard Henderson 2011-04-02
19:25:50 UTC ---
Created attachment 23855
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23855
second proposed patch
The fault is 100% with ld. GCC is producing valid dwarf2.
The *only* ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
--- Comment #18 from Richard Henderson 2011-04-03
02:57:45 UTC ---
Both the first and second hunks are part of the same change.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
--- Comment #19 from Richard Henderson 2011-04-03
03:06:35 UTC ---
What are the changes *after* the second patch? The first two hunks
ought to have disappeared.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
Richard Henderson changed:
What|Removed |Added
Attachment #23855|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
--- Comment #23 from Richard Henderson 2011-04-03
18:16:04 UTC ---
... and if that works, we'll see how much of the other line info
additions we can put back in. Assuming you've a modern debugger
that might be able to use them ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
Richard Henderson changed:
What|Removed |Added
Attachment #23860|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
--- Comment #29 from Richard Henderson 2011-04-04
22:13:58 UTC ---
Author: rth
Date: Mon Apr 4 22:13:54 2011
New Revision: 171955
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171955
Log:
PR 48400
* dwarf2out.c (output_line_info): Alway
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400
Richard Henderson changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381
--- Comment #6 from Richard Henderson 2010-10-01
22:00:47 UTC ---
(In reply to comment #5)
> I think altivec should disabled with "gcc version 4.0.1 (Apple Inc. build
> 5493)". Otherwise this pr could be closed as wontfix.
I'd prefer it if you p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12990
Richard Henderson changed:
What|Removed |Added
CC||davidm at hpl dot hp.com
--- Comment
||rth at gcc dot gnu.org
Resolution||DUPLICATE
Known to fail||
--- Comment #6 from Richard Henderson 2010-10-06
16:25:24 UTC ---
Dup
*** This bug has been marked as a duplicate of bug 12990 ***
||rth at gcc dot gnu.org
Resolution||FIXED
--- Comment #5 from Richard Henderson 2010-10-06
16:30:13 UTC ---
This was fixed for gcc 4.5.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12990
Richard Henderson changed:
What|Removed |Added
Target Milestone|--- |4.5.0
||rth at gcc dot gnu.org
--- Comment #6 from Richard Henderson 2010-10-06
16:34:08 UTC ---
Mine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45911
Summary: bugzilla: Changing status to assigned no longer
auto-adjusts the assign-to field
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priori
501 - 600 of 782 matches
Mail list logo
