https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119
--- Comment #6 from Richard Earnshaw ---
(In reply to PeteVine from comment #5)
> Wait, what about #1?
Sorry, I hadn't spotted that there were two issues in the one report. Please
create separate bug reports for each issue - it's much easier to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124
--- Comment #4 from Richard Earnshaw ---
Does -fno-strict-aliasing help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
--- Comment #7 from Richard Earnshaw ---
Ah! And the maximum range of offset for these relocations in REL format is
-32768,+32767.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #9 from Richard Earns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
Richard Earnshaw changed:
What|Removed |Added
CC||renlin at gcc dot gnu.org
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69248
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #47 from Richard Earnshaw ---
(In reply to ard.biesheuvel from comment #46)
> One issue that this causes, which I did not see mentioned anywhere in the
> thread, is that the use of adrp/add and adrp/ldr imposes a 4 KB section
> alignm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69460
Richard Earnshaw changed:
What|Removed |Added
Keywords||missed-optimization
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #13 from Richard Earn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66547
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66912
--- Comment #1 from Richard Earnshaw ---
Erm, isn't that the whole point of marking the symbol 'protected'?
>From the ELF spec:
STV_PROTECTED
A symbol defined in the current component is protected if it is visible in
other components but n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Richard Earnshaw changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #12 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
--- Comment #2 from Richard Earnshaw ---
(In reply to Richard Biener from comment #1)
> I think this boils down to the fact that memcpy expansion is done too late
> and
> that (with more recent GCC) the "inlining" done on the GIMPLE level is
> re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
--- Comment #9 from Richard Earnshaw ---
Does that really do the right thing? That is, does force_reg understand a
misaligned memory op?
Also, what if one memory operand is aligned, but the other not? Don't we want
to have the right combinatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67415
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48061
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329
--- Comment #3 from Richard Earnshaw 2011-03-10
17:00:10 UTC ---
Another test (from the dup).
int __attribute__ ((vector_size (32))) x;
void
foo (void)
{
x <<= x;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329
Richard Earnshaw changed:
What|Removed |Added
CC||mgretton at sourceware dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48380
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48380
--- Comment #3 from Richard Earnshaw 2011-03-31
21:05:55 UTC ---
Created attachment 23843
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23843
testcase reduced from libgfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48380
Richard Earnshaw changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455
Summary: Huge code size regression for all ARM configurations
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455
--- Comment #4 from Richard Earnshaw 2011-04-07
16:00:04 UTC ---
Created attachment 23914
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23914
first testcase
Compile with -Os -mcpu=arm7tdmi -marm -fno-short-enums -fno-builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455
--- Comment #5 from Richard Earnshaw 2011-04-08
13:01:41 UTC ---
Created attachment 23928
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23928
second testcase
Compile with -Os -mcpu=arm7tdmi -marm -fno-short-enums
Note, it looks like a com
||rearnsha at gcc dot gnu.org
Resolution||FIXED
Target Milestone|--- |4.3.0
--- Comment #8 from Richard Earnshaw 2011-04-18
16:10:01 UTC ---
gcc-4.2 is no-longer being maintained. Closing as fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48628
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941
--- Comment #4 from Richard Earnshaw 2011-05-16
08:13:04 UTC ---
(In reply to comment #3)
> Created attachment 24234 [details]
> Proposed patch
>
> The attached patch seems to fix the testcase and doesn't
> regress neon.exp. I'll test it fully
||2011.05.21 18:14:27
CC||rearnsha at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Richard Earnshaw 2011-05-21
18:14:27 UTC ---
Confirmed. The back-end doesn't currently know how to h
||rearnsha at gcc dot gnu.org
Resolution||INVALID
--- Comment #1 from Richard Earnshaw 2010-09-27
16:30:35 UTC ---
This particular case is invalid.
The ARM ABI requires that short and char result types are extended to 32 bits
(using signed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45804
--- Comment #3 from Richard Earnshaw 2010-09-27
21:52:38 UTC ---
(In reply to comment #2)
>
> What do you mean by "returned"? This is an inline function, so it depends
> entirely on what the referencing code is doing whether or not this value is
||
CC||rearnsha at gcc dot gnu.org
--- Comment #1 from Richard Earnshaw 2010-09-29
16:28:17 UTC ---
So the compiler is correct not to be using vld1 for this code. The memory
format of int32x4_t is defined to be the format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40893
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
Severity|minor
||2010.11.04 17:18:27
CC||rearnsha at gcc dot gnu.org
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440
--- Comment #11 from Richard Earnshaw 2010-11-13
23:08:31 UTC ---
Author: rearnsha
Date: Sat Nov 13 23:08:26 2010
New Revision: 166723
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166723
Log:
PR target/43440
* tm
||rearnsha at gcc dot gnu.org
Resolution||FIXED
Target Milestone|--- |4.6.0
--- Comment #12 from Richard Earnshaw 2010-11-13
23:09:47 UTC ---
Fixed on trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46298
--- Comment #4 from Richard Earnshaw 2010-11-14
17:19:03 UTC ---
Jason - is this fixed now? If so can you close this please.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46631
--- Comment #2 from Richard Earnshaw 2010-12-08
16:38:14 UTC ---
Author: rearnsha
Date: Wed Dec 8 16:38:10 2010
New Revision: 167595
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167595
Log:
2010-12-08 Richard Earnshaw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46631
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48637
--- Comment #3 from Richard Earnshaw 2011-06-27
21:09:32 UTC ---
Author: rearnsha
Date: Mon Jun 27 21:09:25 2011
New Revision: 175565
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175565
Log:
PR target/48637
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48637
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49526
--- Comment #2 from Richard Earnshaw 2011-06-27
21:58:26 UTC ---
Confirmed. Also need patterns for the accumulate and subtract variants, plus
rounding variants.
||2011.06.27 21:59:03
CC||rearnsha at gcc dot gnu.org
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641
Richard Earnshaw changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
|NEW
Last reconfirmed||2011.07.08 16:47:18
CC||rearnsha at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Richard Earnshaw 2011-07-08
16:47:18 UTC ---
I think the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49822
Summary: [gcc-4.7 regression] Segfault in
remove_prop_source_from_use
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49816
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49816
--- Comment #2 from Richard Earnshaw 2011-07-23
14:43:37 UTC ---
Author: rearnsha
Date: Sat Jul 23 14:43:33 2011
New Revision: 176687
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176687
Log:
PR target/49816
||rearnsha at gcc dot gnu.org
Resolution||FIXED
--- Comment #3 from Richard Earnshaw 2011-07-23
14:47:21 UTC ---
Fixed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49057
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799
--- Comment #5 from Richard Earnshaw 2011-07-25
09:03:30 UTC ---
We should never generate a shift of -1. Instead the code that does that should
return (clobber const_int 0).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799
--- Comment #7 from Richard Earnshaw 2011-07-25
09:45:51 UTC ---
No, you miss the point.
Internally we must not generate (ashift (reg) (const_int)) where the const is
negative.
Note that your testcasegenerates a reg shift.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49822
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49891
Summary: [4.7 regression] ICE in redirect_jump_1
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: critical
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
--- Comment #12 from Richard Earnshaw ---
We considered that, but it won't work. For example, in ILP32 address registers
need to use the X form, but are still 32-bits in size. There are other cases
as well where a W or X form is required but th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60882
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #27 from Richard Earnshaw ---
(In reply to David Malcolm from comment #26)
> (In reply to Ramana Radhakrishnan from comment #25)
> > Fixed presumably ?
>
> Mostly. The remaining issue with configure-time options reaching the jit is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #23 from Richard Earnshaw ---
Any plans to backport to 4.9, or should this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
--- Comment #9 from Richard Earnshaw ---
Any plans to backport to 4.9, or should this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69187
--- Comment #15 from Richard Earnshaw ---
Any plans to backport this further?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #3 from Richard Earnshaw ---
Atomic loads and stores have to use the same policy for a single object, you
can't have loads using one model and stores another.
Atomic loads have to work even if the object is marked const.
C/C++ permi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #5 from Richard Earnshaw ---
I don't think so. It's to do with whether the CPU is permitted to 'crack' the
operation into multiple micro-ops that proceed independently down the pipeline.
LDAXP could still be cracked in this way prov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #8 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #7)
> Closing as invalid. Though for v8.4 or so it would be nice if there was
> 128bit atomic loads.
That probably wouldn't help. It would require a new ABI befor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #10 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #9)
> On x86, they use ifuncs for this purpose inside libatomic. Basically the
> requirement is only one libatomic can be used at a time.
If we can guarantee that,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
--- Comment #12 from Richard Earnshaw ---
(In reply to notasas from comment #11)
> FWIW I've tried sending a backport patch, but it was ignored:
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03116.html
If you don't get a response from a mainta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71942
Richard Earnshaw changed:
What|Removed |Added
Keywords||missed-optimization
Targe
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-04-21 08:27
---
There's no need to pass -mthumb to the assembler. If the compiler has emitted
thumb code it will have inserted a suitable directive into the assembly file
that will cause the assembler to act accord
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-04-24 12:49
---
The testcase doesn't compile. Please attach a full, *compilable*, example of
the program that shows the bug.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from rearnsha at gcc dot gnu dot org 2006-04-24 14:26
---
Confirmed. Also appears on trunk on an arm-elf cross with the flags:
-O3 -funroll-all-loops -fomit-frame-pointer -mno-apcs-frame -finline-functions
-mfpu=vfp -mfloat-abi=softfp -mcpu=arm926ej-s
We are
intl.a
../libiberty/libiberty.a
libbackend.a(options.o)(.rodata+0xb700): undefined reference to
`target_fpe_name'
libbackend.a(options.o)(.rodata+0xb740): undefined reference to
`target_fpe_name'
libbackend.a(arm.o)(.text+0x1274): In function `arm_override_options':
/home/rearnsha/gnusrc/gcc/g
--- Comment #4 from rearnsha at gcc dot gnu dot org 2006-05-31 10:12
---
Confirmed on trunk.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rearnsha at gcc dot gnu dot org 2006-05-31 10:13
---
Created an attachment (id=11549)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11549&action=view)
patch in testing
--
rearnsha at gcc dot gnu dot org changed:
What|
--- Comment #6 from rearnsha at gcc dot gnu dot org 2006-05-31 13:41
---
Subject: Bug 27829
Author: rearnsha
Date: Wed May 31 13:41:08 2006
New Revision: 114265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114265
Log:
PR target/27829
--- Comment #7 from rearnsha at gcc dot gnu dot org 2006-05-31 13:50
---
patch installed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27829
The arm-none-eabi compiler gets a segmentation fault while building libstdc++.
A back-trace shows that the fault is in determine_visibility() where we are
dereferencing a null pointer.
#0 determine_visibility (decl=0xbca2e280)
at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cp/decl2.c:1753
#1
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-07-01 18:04
---
Created an attachment (id=11787)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11787&action=view)
gziped attachment of failing source file (pre-processed)
cc1plus fstream-inst.ii -quiet -dumpbase
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot
|dot org
--- Comment #3 from rearnsha at gcc dot gnu dot org 2008-12-10 14:58
---
Subject: Bug 37668
Author: rearnsha
Date: Wed Dec 10 14:57:18 2008
New Revision: 142647
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142647
Log:
Martin Guy <[EMAIL PROTECTED]>
PR target
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-10 15:00
---
Fixed in 4.4.0
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2008-12-10 15:10
---
Confirmed. Still present on trunk.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-10 15:38
---
Some notes on the failure path:
combine generates the pattern
(insn 1466 1464 1467 192 regeximp.h:320 (set (reg:SI 1002)
(sign_extend:SI (mem/s/j:QI (plus:SI (reg:SI 1000)
(mult:SI
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot
|dot org
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
--- Comment #6 from rearnsha at gcc dot gnu dot org 2008-12-16 12:12
---
Fixed on trunk
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-16 16:45
---
I'm unable to reproduce this with any of svn-trunk, gcc-4.1.3 (debian),
gcc-4.3.3 (SVN) or gcc-4.3.2 (debian). The loop essentially reads as
mov r7, #1
mov r6, #0
L5:
...
add r6, r6, #1
cmp r
--- Comment #5 from rearnsha at gcc dot gnu dot org 2008-12-16 12:04
---
Subject: Bug 37436
Author: rearnsha
Date: Tue Dec 16 12:03:41 2008
New Revision: 142778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142778
Log:
PR target/37436
* arm.c (arm_legitimate_inde
--- Comment #2 from rearnsha at gcc dot gnu dot org 2008-12-16 17:12
---
Confirmed. This appears to be a bug in the register-renaming pass, where the
insn
(insn:HI 84 79 82 8 proc/sysinfo.c:890 (parallel [
(set (reg:CC_NOOV 24 cc)
(compare:CC_NOOV
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-16 17:39
---
Not a bug. You need to write your macro like this:
#define burst_copy(dst,src,len) {\
unsigned t1, t2, t3; \
__asm__ __volatile__ ( \
"1: \n\t" \
"ldmia %1!,{r3-r6} \n\t" \
&qu
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-19 10:22
---
I'm already testing fixes for this, but my native arm board is very
sl
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from rearnsha at gcc dot gnu dot org 2008-12-19 17:24
---
Subject: Bug 38578
Author: rearnsha
Date: Fri Dec 19 17:22:58 2008
New Revision: 142837
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142837
Log:
PR bootstrap/38578
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-19 17:25
---
Fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot
|dot org
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-19 17:32
---
Subject: Bug 38548
Author: rearnsha
Date: Fri Dec 19 17:31:12 2008
New Revision: 142838
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142838
Log:
PR target/38548
* arm
901 - 1000 of 1812 matches
Mail list logo
