--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 23:38
---
Confirmed. We need a way to represent an early-clobber between a register and
a memory-address with side-effects.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-17 00:03
---
Confirmed, this is a nasty bug that might silently bite users after a long
period of apparently correct operation.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-17 00:15
---
This is a case where early splitting (before register allocation) of a constant
in a plus expression leads to poor code. We should try disabling the split of
a plus when combined with the internal frame pointer
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-17 11:41
---
This isn't something that should be fixed in the back-end, but most likely an
enhancement to a pass such as ifcvt. To handle this case we would have to
teach ifcvt about dominated conditions and condit
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-03-17 11:02
---
Created an attachment (id=17475)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17475&action=view)
Proposed fix -- will commit after trunk reopens
--
rearnsha at gcc dot gnu dot org
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-03-17 11:19
---
(In reply to comment #6)
> foo:
> mov r3, r0
> cmn r1, r0
> rsbeq r0, r1, r0
> rsbne r0, r3, r1
> bx lr
This appears to be the code ge
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-03-17 13:46
---
Cold case analysis time. Have you seen this problem in recent releases of GCC?
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-03-18 11:49
---
No feedback in over a year. Presumed fixed in 4.3.0.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-19 16:53
---
Also affects all other EABI target builds.
THe bug is in movsfcc (and movdfcc) which have not been corrected to account
for the libcall comparisons returning a bool value in the EABI.
I'm currently testing
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-03-19 17:02
---
Correction: it doesn't affect movdfcc since that only matches on hard-float
targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-03-25 21:54
---
(In reply to comment #2)
> str r3, [fp, #-32]
> str r4, [fp, #-28]
> ldfd f0, [fp, #-32]
> sqtd f0, f0
> stfd
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-03-30 17:01
---
This is probably the same as target/37436. However, that fix has not been
back-ported to the 4.3 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36415
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39614
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39614
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-04-04 10:37
---
Subject: Bug 39501
Author: rearnsha
Date: Sat Apr 4 10:37:10 2009
New Revision: 145534
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145534
Log:
PR target/39501
* arm.md
--- Comment #14 from rearnsha at gcc dot gnu dot org 2009-04-04 12:25
---
Subject: Bug 39501
Author: rearnsha
Date: Sat Apr 4 12:25:06 2009
New Revision: 145537
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145537
Log:
PR target/39501
* arm.md
--- Comment #18 from rearnsha at gcc dot gnu dot org 2009-04-21 16:40
---
(In reply to comment #14)
> Something like that? (untested)
>
> Index: configure.ac
> ===
> --- configure.ac(
--- Comment #1 from rearnsha at gcc dot gnu dot org 2009-04-29 17:12
---
The ARM port does not currently support XIP (if it worked previously, it was by
chance, not design). The generated code is exactly what is wanted in a normal
shared library environment, so I'm not about to
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-04-29 21:14
---
There's a proposal in with the ARM ABI to change the behaviour for this case.
I'm suspending this bug until that is resolved.
--
rearnsha at gcc dot gnu dot org changed:
What
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29336
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-05-01 15:30
---
This smells like a memory corruption problem in the compiler...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
--- Comment #1 from rearnsha at gcc dot gnu dot org 2009-08-21 16:17
---
Fixed. Although I posted the patch for this to the mailing list several days
ago (Aug 12 IIRC), I somehow failed to actually commit the code. Now done.
Sorry about that.
--
rearnsha at gcc dot gnu dot org
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-09-17 17:03
---
The assertion in the source is clearly broken if a constant can legally be
passed to it. If a constant can't legally be passed, then the caller needs to
be fixed to diagnose it before we reach this
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-10-14 14:10
---
No feedback in 6 months. Closing as presumed fixed.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-10-14 14:11
---
No feedback in 6 months. Presumed fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-10-14 14:13
---
No useful feedback. Closing.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-10-14 14:16
---
Closing as presumed fixed.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-10-14 14:17
---
No feedback. Presumed fixed.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-10-14 14:20
---
No feedback
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-10-19 15:18
---
(In reply to comment #3)
> .text
> ldr r0, .L30
...
> .section.text.unlikely
> .L30: .word 1819043176
This is broken. We can't reference from .text to .te
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-10-19 15:26
---
(In reply to comment #1)
> Subject: Re: New: FAIL: gcc.dg/tree-prof/bb-reorg.c
> compilation, -fprofile-use -D_PROFILE_USE
>
> The ARM constant pool code needs to handle a
> NOTE_INSN_SWITC
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-10-19 15:50
---
(In reply to comment #6)
> You should not depend on NOTE_INSN_SWITCH_TEXT_SECTIONS. There are other ways
> to see if a jump goes from one section to another: edge->flags & EDGE_CROSSING
>
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-10-19 16:19
---
Created an attachment (id=18826)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18826&action=view)
Proposed patch
Currently only very lightly tested, but this should solve the issue.
--
--- Comment #11 from rearnsha at gcc dot gnu dot org 2009-10-19 17:51
---
(In reply to comment #9)
> Subject: Re: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation,
> -fprofile-use -D_PROFILE_USE
>
> On Mon, 19 Oct 2009, rearnsha at gcc dot gnu dot org wrote:
>
> >
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-10-20 15:18
---
Subject: Bug 39247
Author: rearnsha
Date: Tue Oct 20 15:17:30 2009
New Revision: 153018
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153018
Log:
PR target/39247
--- Comment #13 from rearnsha at gcc dot gnu dot org 2009-10-20 15:25
---
Fixed on trunk.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-11-04 14:10
---
Subject: Bug 40835
Author: rearnsha
Date: Wed Nov 4 14:09:55 2009
New Revision: 153895
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153895
Log:
2009-11-04 Richard Earnshaw
PR targ
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-11-14 18:17
---
Subject: Bug 42031
Author: rearnsha
Date: Sat Nov 14 18:17:21 2009
New Revision: 154182
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154182
Log:
PR target/42031
* arm.md (adddi_s
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-11-14 18:25
---
Fixed with posted patch
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rearnsha at gcc dot gnu dot org 2009-11-16 17:35
---
This is probably a consequence of some changes made to support Thumb-2. Only
a very limited number of instructions are permitted to modify SP there, and
co-processor operations are not amongst them.
I think
--- Comment #19 from rearnsha at gcc dot gnu dot org 2007-05-06 00:27
---
This patch is responsible for the code size regressions on CSiBE at -Os. It
also causes a bootstrap failure on arm-netbsdelf2: genautomata is being
miscompiled.
--
rearnsha at gcc dot gnu dot org changed
--- Comment #21 from rearnsha at gcc dot gnu dot org 2007-05-06 15:34
---
(In reply to comment #20)
> Re. comment #19: What "code size regression"? Your comment is too unspecific.
>
The code size regression that shows up on CSiBE between r123918 and r123919 on
ARM,
ation
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-netbsdelf2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-05-07 00:12
---
Created an attachment (id=13517)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13517&action=view)
compressed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
--- Comment #2 from rearnsha at gcc dot gnu dot org 2007-05-07 00:14
---
Created an attachment (id=13518)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13518&action=view)
assembly output (annotated)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
--- Comment #3 from rearnsha at gcc dot gnu dot org 2007-05-07 00:15
---
Created an attachment (id=13519)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13519&action=view)
RTL dump showing invariant hoisting
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-none-eabi
http
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-05-07 01:06
---
Created an attachment (id=13520)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13520&action=view)
source code showing regression
compiled code for this file regresses by approximately 3%
--
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-05-07 09:34
---
(In reply to comment #2)
> > 1) Hoists a register containing 0 out of the loop
> The correct thing to do.
>
Not necessarily. Hoisting literal constants means that opportunities to simply
insns b
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-05-07 10:43
---
Here's another example of code that is now significantly worse (~20% larger).
Rather than incrementing the base pointers on each iteration of the loop, we
now maintain both base pointers and and offset.
--- Comment #9 from rearnsha at gcc dot gnu dot org 2007-05-07 13:50
---
(In reply to comment #8)
>
> actually, this should save one addition (only the index is incremented, the
> additions of index to bases are done in the addressing mode).
When a machine has a post-
--- Comment #12 from rearnsha at gcc dot gnu dot org 2007-05-16 00:06
---
Confirmed fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-05-29 13:22
---
The __div0 function is called by the division routines when an attempt to
divide by zero is detected. On a linux system, it is expected that this will
cause SIGFPE to be raise(3)d, so the default implementation
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-06-19 09:41
---
Confirmed. This is a bug in the negscc pattern in arm.md. It's only been
there since 1994!
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from rearnsha at gcc dot gnu dot org 2007-06-23 18:11
---
Fixed on trunk.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rearnsha at gcc dot gnu dot org 2007-06-23 18:07
---
Subject: Bug 31152
Author: rearnsha
Date: Sat Jun 23 18:07:04 2007
New Revision: 125973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125973
Log:
PR target/31152
* arm.md (negscc
--- Comment #28 from rearnsha at gcc dot gnu dot org 2007-06-25 08:06
---
(In reply to comment #27)
> As for the code size regression, Richard E., have you had a chance to identify
> a specific CSiBE file that expands, so that Zdenek can look at that?
>
There were a number
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-01
10:19 ---
Subject: Re: arm-linux-gcj cross-compiler generates bad
assembler-code
On Wed, 2005-08-31 at 21:18, ngmlinux at gmail dot com wrote:
> (gdb) bt
> #0 GC_push_all_eager (bottom=0x0, top=0
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-01
13:13 ---
Really a dup of 15342. Fixed for 3.4.5
*** This bug has been marked as a duplicate of 15342 ***
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-01
13:14 ---
*** Bug 17810 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-01
15:21 ---
Not a regression since iwwmxt support was new in 3.4
Note that you cannot use __attribute__((aligned (4))) to reduce the alignement
of an object, so this code is invalid (code compiled for iwmmxt
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-02
12:39 ---
Undoubtedly. But I don't see much prospect of this being changed any time soon.
It would require too much co-operation between the mid and back-ends.
--
What|Re
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-02
22:27 ---
I've made a small amount of headway on this.
Labels L22 and L21 were (when created) the addresses of objects in the code.
However, they are deleted (presumably as unreachable), but the references t
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-09
10:17 ---
Some analysis here:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00570.html
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-14
13:56 ---
Confirmed. This seems to be a problem with loop unswitching
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-30
09:20 ---
Please send the entire pre-processed file, not just a fragment of it. Use the
'create a new attachment' link on the bugzilla page (see URL below).
You are also going to have to explain what yo
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-30
10:13 ---
Confirmed by visual inspection of the assembly code.
What seems to be happening is this:
After if conversion we have (pseudo code)
a ? alpha.style = 1
a ? ...
!a ? alpha.style = 2
!a
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-30
10:58 ---
testing a fix
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-30
10:59 ---
This is a bug in the arm backend.
--
What|Removed |Added
Component|rtl
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-30
13:58 ---
(In reply to comment #1)
> volatile is needed here.
No, the manual says:
An @code{asm} instruction without any output operands will be treated
identically to a volatile @code{asm} instruction.
So t
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-30
16:12 ---
ARM ports have never accepted $ in identifiers. So this isn't a regression. In
fact, the only regression would be if they started doing so, since as Paul
points out, they are reserved by th
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-10-01
13:33 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-06 12:48
---
Fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-10-07 15:51
---
Yes we need the preprocessed source code. Unless I can run the compiler under
a debugger there's no chance of working out what's going wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from rearnsha at gcc dot gnu dot org 2005-10-07 17:10
---
The problem here is that we have a complex compare-and-jump insn with side
effects, so the insn can't be simply removed. cfgrtl is getting confused and
is generating code that references a deleted
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-10-12 13:42
---
Stack backstrace suggests that this is probably a duplicate of PR23870.
*** This bug has been marked as a duplicate of 23870 ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-12 13:42
---
*** Bug 24322 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rearnsha at gcc dot gnu dot org 2005-10-13 15:25
---
Fixed again (hopefully).
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-10-18 16:13
---
Confirmed still fails on the 3.4 branch (arm-elf cross). The failure mode is
that we have
virtual_frame_pointer <= hard_frame_pointer
...
cond_jump somewhere
var <= virtual_frame_pointer
The i
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-10-19 09:51
---
Are you sure you've built and installed an ARM assembler (get gnu binutils).
If so, are you sure you've configured it with with exactly the same --target...
option as you used when configuring gcc, and
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-26 12:25
---
This is a duplicate
*** This bug has been marked as a duplicate of 22331 ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-10-26 12:25
---
*** Bug 24529 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-26 12:33
---
If you can't upgrade to gcc-3.4, see the patch link in the bug this is a
duplicate of
*** This bug has been marked as a duplicate of 22528 ***
--
rearnsha at gcc dot gnu dot org changed:
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-26 12:33
---
*** Bug 24528 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rearnsha at gcc dot gnu dot org 2005-11-01 09:37
---
Subject: Re: New: The comment start symbol of arm target
On Tue, 2005-11-01 at 07:31, hanzac at gmail dot com wrote:
> It's true that the arm comment start symbol is '@', but GCC will generat
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-02 10:13
---
> ../.././gcc/config/arm/lib1funcs.asm:731: Error: no such instruction: `moveq
> pc,lr'
This just shows that you aren't picking up an ARM assembler. Have you
installed GAS correctly? and does t
--- Comment #7 from rearnsha at gcc dot gnu dot org 2010-02-08 11:26
---
(In reply to comment #6)
> Does the ARM backend already support conditional compares?
>
Yes, but only by manipulating store-flag sequences in the combine pass. That's
a poor-man's implementation
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-02-08 16:50
---
Best to do it post RA, so that we can issue the best sequences of insns. I
have some better sequences that could be generated for Thumb2 which would avoid
the need for an IT instruction in many cases
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-02-17 10:09
---
Pinskia: The M1 is best thought of as a thumb1 only processor, blx is for
jumping across instruction sets.
We need a testcase that demonstrates this problem, without one we can't help.
--
rearnsha at gc
--- Comment #6 from rearnsha at gcc dot gnu dot org 2010-02-18 23:09
---
Please supply pre-processed source that will allow a developer to reproduce the
problem.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rearnsha at gcc dot gnu dot org 2010-02-19 00:13
---
Hmm, sorry about that, yes, I can confirm the bug as reported in comment #5,
also occurs on trunk.
Do you know if this code compiled on older releases of GCC?
--
rearnsha at gcc dot gnu dot org changed
--- Comment #11 from rearnsha at gcc dot gnu dot org 2010-02-19 00:23
---
There are two further targets that define a ..._mark_dllimport function: mcore
and sh (for symbian). The mcore code is the same as arm-pe, but the sh code
does not wrap the symbol inside a MEM operation
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-02-24 11:15
---
I think the real problem here is that shared_const_p thinks that _this_ const
expression can't be shared (though I can't see any reason why it couldn't).
The comment in that function says, "CO
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-02-24 14:17
---
As suggested, there's no bug in the compiler here, and the error message comes
from the linker. The linker doesn't know what the key function is, so I doubt
it could issue a more accurate diagnostic
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-02-26 14:39
---
I don't think this test case is valid.
Unfortunately, the division function is not completely pure. If a division by
zero occurs, then a handler function may be invoked, which might cause the
contents point
--- Comment #15 from rearnsha at gcc dot gnu dot org 2010-03-15 09:16
---
(In reply to comment #14)
> The bug was fixed for 4.5 by r148072:
>
> 2009-06-02 Richard Earnshaw
>
>* arm.c (arm_get_frame_offsets): Prefer using r3 for padding a
>push
1101 - 1200 of 1817 matches
Mail list logo
