Hi Guys,
All I wanted to do was to make GCC's ARM assembler output slightly
easier to read...
I would like to propose a patch to create a new header file in the
include/ directory. This file would contain enums describing the
attributes that be can found in SHT_GNU_ATTRIBUTES
On 29 Sep 2011, at 10:34, Nick Clifton ni...@redhat.com wrote:
Hi Guys,
All I wanted to do was to make GCC's ARM assembler output slightly
easier to read...
I would like to propose a patch to create a new header file in the
include/ directory. This file would contain enums
On Tue, Sep 27, 2011 at 4:19 PM, Amker.Cheng amker.ch...@gmail.com wrote:
Hi,
I ran into a case and found conditional (const) propagation is
mishandled in cprop pass.
With following insn sequence after cprop1 pass:
(note 878 877 880 96 [bb
Hello,
the GCC 4.6.2 seems to be ready soon. It would be very nice if some ARM bugs
can be fixed for this release (in the GCC 4.6-20110923 snapshot they are not
fixed).
1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641
Here we have a test case and a fix.
2.
Amker.Cheng amker.ch...@gmail.com writes:
(insn 882 881 883 96 (set (reg:CC 24 cc)
(compare:CC (reg:SI 684 [ default_num_contexts ])
(const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
(nil))
The insn49 should be propagated with conditional const from insn882
Hi Richard,
I don't think it's a good idea to have the attributes of
every CPU we support in a single file. That's going to
get unmaintainable very quickly.
Really - why ?
These attributes are mostly static. Some new ones might be added from
time to time, but baring the introduction of
Unless there's something arch specific related to arm, insn 882 is a
compare, which won't change r684. Why do you think 0 should
propagated to r291 if r684 is not zero?
Thanks for replying.
Sorry if I misunderstood anything below, and please correct me.
insn 882 : cc - compare
insn 882 : cc - compare (r684, 0)
jump_insn 883 : if (cc != 0) goto insn 46
insn 49: r291 - r684
..
insn 46
cc contains the result of subtracting 0 from r684; control flow goes to
insn_49 only if (cc == 0), which implies (r684 == 0).
Then at insn_49 we have
On 09/29/11 16:43, Rahul Kharche wrote:
insn 882 : cc - compare (r684, 0)
jump_insn 883 : if (cc != 0) goto insn 46
insn 49: r291 - r684
..
insn 46
cc contains the result of subtracting 0 from r684; control flow goes to
insn_49 only if (cc == 0), which implies
On Thu, 29 Sep 2011, Nick Clifton wrote:
Hi Richard,
I don't think it's a good idea to have the attributes of
every CPU we support in a single file. That's going to
get unmaintainable very quickly.
Really - why ?
These attributes are mostly static. Some new ones might be added
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 09:26, Bernd Schmidt wrote:
On 09/29/11 16:43, Rahul Kharche wrote:
insn 882 : cc - compare (r684, 0) jump_insn 883 : if
(cc != 0) goto insn 46 insn 49: r291 - r684
.. insn 46
cc contains the result of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 08:43, Rahul Kharche wrote:
insn 882 : cc - compare (r684, 0) jump_insn 883 : if
(cc != 0) goto insn 46 insn 49: r291 - r684 ..
insn 46
cc contains the result of subtracting 0 from r684; control flow
goes
On 09/29/11 17:36, Jeff Law wrote:
On 09/29/11 09:26, Bernd Schmidt wrote:
ISTR cse.c has some support for this.
cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Bernd
On 09/29/11 17:36, Jeff Law wrote:
On 09/29/11 09:26, Bernd Schmidt wrote:
ISTR cse.c has some support for this.
cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Interesting. Are the two approaches subtly different
or do they apply precisely the same predication?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 09:48, Rahul Kharche wrote:
On 09/29/11 17:36, Jeff Law wrote:
On 09/29/11 09:26, Bernd Schmidt wrote:
ISTR cse.c has some support for this.
cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Interesting. Are
Amker.Cheng amker.ch...@gmail.com writes:
Thanks for replying.
Sorry if I misunderstood anything below, and please correct me.
insn 882 : cc - compare (r684, 0)
jump_insn 883 : if (cc != 0) goto insn 46
insn 49: r291 - r684
..
insn 46
cc contains the result of
I've had no success lately getting GCC to bootstrap successfully. My
last successful bootstrap was on September 6; my builds on September
7 through today all end with a comparison failure. Here's the end
of my build log:
gmake[2]: Entering directory `/export/home/arth/src/gcc-0929'
gmake[3]:
Snapshot gcc-4.5-20110929 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110929/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Nobody mentioned this so I might be way off but cc doesn't get (minus
(reg r684) (const_int 0)). It gets the `condition codes` modification as
a consequence of the subtraction.
Hi Paulo,
According to section comparison operations in internal:
The comparison operators may be used to compare
As some of you might know, I have been researching and working on a region-based
memory management plugin for GCC. My target is specifically the Go language.
With that said, I have been making a fair amount of progress. More recently, I
have been benchmarking my work, and it came to my attention
I believe, the optimization you may be referring to is value range
propagation which does predication of values based on predicates of
conditions. GCC definitely applies VRP at the tree stage, I am not
sure if there is an RTL pass to do the same.
There are also RTL optimizers which perform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #10 from Johannes Schaub schaub.johannes at googlemail dot com
2011-09-29 06:10:26 UTC ---
(In reply to comment #9)
Excellent, then could you possibly comment on the implication for this PR?
(for
you it's easy, I'm sure)
Hi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #11 from Johannes Schaub schaub.johannes at googlemail dot com
2011-09-29 06:14:32 UTC ---
(In reply to comment #10)
(In reply to comment #9)
Excellent, then could you possibly comment on the implication for this PR?
(for
you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514
--- Comment #4 from Vittorio Zecca zeccav at gmail dot com 2011-09-29
06:58:24 UTC ---
About run time checking: I believe the bit size of k is known at compile time,
and the overhead to check n against it is negligible as compared to computing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50563
Bug #: 50563
Summary: Weird syntax acceptance rules for non-static data
members initialized in place (C++0x)
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50563
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564
Bug #: 50564
Summary: [4.7 Regression] Front-end optimization - ICE with
FORALL
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565
Bug #: 50565
Summary: [4.5/4.6/4.7 Regression] initializer element is not
computable at load time
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557
--- Comment #3 from Igor Zamyatin izamyatin at gmail dot com 2011-09-29
08:34:45 UTC ---
William, thanks for quick response!
With -funroll-loops regression is still present.
Do you want me to attach some dumps?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29
09:23:36 UTC ---
Ah, point taken about the irrelevance of the defect for this specific PR, sorry
for bothering. Yesterday I didn't even try to reconstruct how the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258
Carlos Becker bsys.com.ar at gmail dot com changed:
What|Removed |Added
CC||bsys.com.ar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org |
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
--- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29
10:45:40 UTC ---
Never mind, I don't think it's the same, but 39813 is also pretty weird, why
error.c sees the member template as a friend it's a mystery to me...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50566
Bug #: 50566
Summary: [avr]: Add support for better logging similar to -mdeb
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15218
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50566
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32350
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34996
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org |jason at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547
--- Comment #3 from janus at gcc dot gnu.org 2011-09-29 11:23:52 UTC ---
Here is a better version which is regression-free:
Index: gcc/fortran/resolve.c
===
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-29
11:49:09 UTC ---
(In reply to comment #9)
Even though the proposed patch seems to be a proper solution, to me it seems
to
be that using -fpermissive just to come around
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50566
--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-29
11:52:04 UTC ---
Author: gjl
Date: Thu Sep 29 11:51:59 2011
New Revision: 179344
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179344
Log:
PR target/50566
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50553
--- Comment #3 from janus at gcc dot gnu.org 2011-09-29 11:57:40 UTC ---
Author: janus
Date: Thu Sep 29 11:57:35 2011
New Revision: 179345
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179345
Log:
2011-09-29 Janus Weil ja...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547
--- Comment #4 from janus at gcc dot gnu.org 2011-09-29 11:57:40 UTC ---
Author: janus
Date: Thu Sep 29 11:57:35 2011
New Revision: 179345
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179345
Log:
2011-09-29 Janus Weil ja...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50553
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
--- Comment #15 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-29
12:13:17 UTC ---
(In reply to comment #14)
Never mind, I don't think it's the same, but 39813 is also pretty weird, why
error.c sees the member template as a friend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547
--- Comment #5 from janus at gcc dot gnu.org 2011-09-29 12:14:03 UTC ---
Comment #0 is fixed with r179345.
I noticed that in 'resolve_formal_arglist' there are two separate checks for
procedure dummies in elemental procedures (for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557
--- Comment #4 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-09-29
12:16:46 UTC ---
No, that's OK. I should be able to reproduce this on a pool machine.
It may be difficult to come up with a good heuristic here given that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
--- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29
12:20:51 UTC ---
Thanks. Now in mainline we say this:
40793.C: In function ‘void f()’:
40793.C:5:31: error: no matching function for call to ‘staticPrint()’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34996
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-29
12:25:00 UTC ---
Derived1::X must be defined in every translation unit that needs it.
An explicit instantiation is *required* to not instantiate members of base
classes:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34996
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50262
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-29
12:35:32 UTC ---
Not disambiguated because the HEAP tag of q escapes and thus the points-to
set of q has vars_contains_global set, which then aliases with p which
just has
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-29
12:44:16 UTC ---
The problem is that with front-end optimization, the forall body is changed
from:
timeSteps(iTime)=ratio**(dble(iTime)-0.5d0)-ratio**(dble(iTime)-1.5d0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-29
13:01:49 UTC ---
Seemingly caused by the patch for PR 44649:
2010-07-08 Janus Weil ja...@gcc.gnu.org
PR fortran/44649
* check.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49944
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.5.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50047
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50045
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50350
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50275
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50421
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50437
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-29
13:17:46 UTC ---
Argument. X shall be an interoperable data entity that is not an assumed-size
array.
It might be sufficient to test -- besides the obvious stuff (cf. SIZEOF)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50354
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50057
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50458
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
janus at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.6.2 |---
--- Comment #8 from janus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50045
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.4.7 |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50389
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48660
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.5.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50279
--- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2011-09-29
13:47:12 UTC ---
(In reply to comment #0)
Peter, can you retest the failing lto-bootstrap building the go compiler under
current gcc trunk? I believe honza's recent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
William J. Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46715
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
--- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-29
14:35:14 UTC ---
(In reply to comment #16)
Thanks. Now in mainline we say this:
40793.C: In function ‘void f()’:
40793.C:5:31: error: no matching function for call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43723
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50567
Bug #: 50567
Summary: Reload pass generates sub-optimal spill code for
registers in presence of a vec_concat insn
Classification: Unclassified
Product: gcc
Version: 4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50567
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-29
15:11:55 UTC ---
I think this is because we prefer to do GR-sse register moves throuhg memory.
-mtune=core2 should avoid this I think.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50567
--- Comment #2 from Siddhesh Poyarekar siddhesh.poyarekar at gmail dot com
2011-09-29 15:24:52 UTC ---
Thanks, that eliminated the spill to stack. The extra xmm1 to xmm0 move still
remains:
process:
.LFB0:
.cfi_startproc
movq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949
--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29
15:26:30 UTC ---
Doesn't seem to make much sense, but thanks, anyway.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50567
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||hubicka at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29
15:31:03 UTC ---
It seems, the warning is emitted *before* the pragma is actually processed in
diagnostic_classify_diagnostic...
On Wed, 28 Sep 2011, paolo.carlini at oracle dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-29 15:40:19 UTC ---
On Wed, 28 Sep 2011, paolo.carlini at oracle dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29
15:45:44 UTC ---
Are you aware that *all* the new bugs do *not* have it?
Please explain that, if we want me to restore those CC (which I assumed were
just bogus/legacy
Something is strange ... messages sent to bugs from which gcc-bugs was
removed do in fact still go to gcc-bugs anyway. So maybe there is no real
problem with messages not going to gcc-bugs - but an apparent removal of
gcc-bugs should not appear in messages reporting a change that presumably
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
Bug #: 50568
Summary: [4.7 Regression] Massive LTO failures
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-29 15:48:40 UTC ---
Something is strange ... messages sent to bugs from which gcc-bugs was
removed do in fact still go to gcc-bugs anyway. So maybe there
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-29
15:49:32 UTC ---
(In reply to comment #8)
This patch itself doesn't do anything wrong AFAICS, it rather seems to expose
an underlying bug: Either we need to set the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||andi-gcc at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29
15:49:47 UTC ---
(and as you can see, this PR now is missing the CC, and all the messages we are
exchanging are sent to the gcc-bugs mailing list, no problem at all)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50448
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Component|target |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-09-29
15:58:26 UTC ---
Looking...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-09-29 15:59:54
UTC ---
I got
lto1: internal compiler error: resolution sub id not in object file^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
1 - 100 of 235 matches
Mail list logo
