--- Comment #5 from nickc at redhat dot com 2006-01-10 13:15 ---
Created an attachment (id=10605)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10605&action=view)
When computing region not to schedule, include earlier cc0 setters
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #6 from nickc at redhat dot com 2006-01-10 13:19 ---
Hi Libor,
I have uploaded a patch which should fix the problem. It is not the most
elegant solution but I believe that it should work for now.
The patch amends the code in add_branch_dependencies() which searches
--- Comment #10 from nickc at redhat dot com 2006-01-11 15:37 ---
Created an attachment (id=10622)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10622&action=view)
Revised patch which should not walk over blocks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24376
--- Comment #11 from nickc at redhat dot com 2006-01-11 15:38 ---
Hi Libor,
Oops- there was a condition where the new code could walk backwards into a
previous block. Sorry about that. I have uploaded a revised patch which
should not fall into this trap. It certainly works with
--- Comment #3 from nickc at redhat dot com 2006-07-27 10:20 ---
Kazu,
I will apply your proposed patch.
One day we must really spend the time to fixup gcc so that the backends know
about these debug labels and their effect on code placement.
Cheers
Nick
PS. For the record
--- Comment #9 from nickc at redhat dot com 2007-02-05 14:28 ---
Hi Steven,
There is no longer a buf to fix. In fact the hack mentioned in comment #4
has been removed and the test case compiles without problems using the current
mainline sources.
Cheers
Nick
--
http
--- Comment #2 from nickc at redhat dot com 2007-03-28 11:38 ---
Subject: Re: gcc --help=target gives a linker error.
Hi Brooks,
I have a patch to fix this problem (attached). Unfortunately due to
an internal bugzilla error I cannot (currently) upload the patch to this PR
--- Comment #2 from nickc at redhat dot com 2007-03-28 13:40 ---
Subject: Re: --help= option isn't documented.
Hi Brooks,
The attached patch adds this missing documentation. It also takes
care of a small bug, whereby the name of the language whose options were
being disp
--- Comment #1 from nickc at redhat dot com 2007-03-28 13:50 ---
Hi Brooks,
I do not think that this is a bug, although it is possibly a documentation
issue. The --help=<> option restricts the output to a specified subset of the
full output obtained with just the --help option.
riority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nickc at redhat dot com
GCC host triplet: x86_64-pc-linux-gnulibc2.3
GCC target triplet: mips64vrel-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31388
--- Comment #4 from nickc at redhat dot com 2007-03-29 11:05 ---
Brooks' patch is better than mine, so I would recommend that it be adopted.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
--- Comment #4 from nickc at redhat dot com 2007-03-29 11:08 ---
Subject: Re: --help= option isn't documented.
Hi Brooks,
> The patch tracker missed the patch I'd already posted for this one as well:
> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01655.html
>
>
--- Comment #2 from nickc at redhat dot com 2007-03-29 11:11 ---
Hi Brooks,
> One difference that I see between our patches -- you have:
> + if (* descrip_extra == '\0')
> +descrip_extra = lang_names [i];
> whereas mine just unconditionally as
--- Comment #1 from nickc at redhat dot com 2007-08-06 08:12 ---
Subject: Re: New: -frecord-gcc-switches issues
Hi Jakub,
> .ascii "-isystem ./include-fixed"
> .zero 1
> .ascii "-D_GNU_SOURCE a.c"
> .zero 1
>
--- Comment #4 from nickc at redhat dot com 2007-08-07 08:11 ---
Subject: Re: -frecord-gcc-switches issues
Hi Roland,
> Absolute file names are a very bad idea. That makes for gratuitous
> differences
> in builds due to the build or source directory name, i.e. unr
--- Comment #5 from nickc at redhat dot com 2007-08-07 08:25 ---
Subject: Re: -frecord-gcc-switches issues
Hi Ben,
> Is there an easy way to separate out the include and link (-I, -L) bits from
> the macro defines and compiler option flags? Could the just the include bits
>
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nickc at redhat dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33122
--- Comment #1 from nickc at redhat dot com 2007-08-20 13:46 ---
Created an attachment (id=14080)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14080&action=view)
Compressed, pre-processed source file used to reproduce the problem
This source file was compiled with this
--- Comment #5 from nickc at redhat dot com 2007-08-20 13:48 ---
Bug report #33122 may be a duplicate of this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
--- Comment #1 from nickc at redhat dot com 2007-08-31 10:38 ---
Subject: Re: New: m32r: ICE: RTL check: expected elt 0
type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at
insn-attrtab.c:29:
RTL check: expected elt 0 type 'i&#
--- Comment #3 from nickc at redhat dot com 2007-08-31 14:18 ---
Created an attachment (id=14147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14147&action=view)
Fix length calculation for get_pc pattern
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
--- Comment #4 from nickc at redhat dot com 2007-08-31 14:19 ---
Hi Rask,
Ah, yes, I see what you mean. The uploaded patch should fix this for you.
Please let me know if you have any problems with it.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
--- Comment #4 from nickc at redhat dot com 2007-09-17 12:08 ---
Subject: Re: collect2: ld terminated with signal 11 [Segmentation
fault]
Hi Don,
> Thank you both for your replies. I have now built binutils 2.18.
> However I'm not root on this machine and so cannot in
--- Comment #8 from nickc at redhat dot com 2008-09-12 15:52 ---
Created an attachment (id=16303)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16303&action=view)
Implement alignment for non-local commons
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #9 from nickc at redhat dot com 2008-09-12 15:54 ---
Hi Brian,
Please could you try out the uploaded patch which is an implementation of
your idea to add an extra alignment directive when emitting commons. It seems
to work for the test case you gave, but I have not yet
--- Comment #13 from nickc at redhat dot com 2008-09-29 14:13 ---
Created an attachment (id=16425)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425&action=view)
Revised patch with correct section switching
--
nickc at redhat dot com changed:
What|
--- Comment #14 from nickc at redhat dot com 2008-09-29 14:16 ---
Hi Guys,
I am not able to reproduce the build problems that were reported with the
first version of my patch, but then again I do not have a native cygwin build
system or a system in which I can bootstrap mingw32. I
--- Comment #24 from nickc at redhat dot com 2008-09-30 14:05 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
> a printf in the code for ff_cos_16 causes the compiler to align the var,
> but at this point it crashes in another place
--- Comment #28 from nickc at redhat dot com 2008-10-03 16:52 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi Danny,
> This test case:
> t1.c:(.text+0x5): undefined reference to `_i'
Hmm, I cannot reproduce th
--- Comment #29 from nickc at redhat dot com 2008-10-03 16:54 ---
Created an attachment (id=16458)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16458&action=view)
Revised patch which handles (size == 0)
--
nickc at redhat dot com changed:
What|
--- Comment #31 from nickc at redhat dot com 2008-10-04 08:27 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
> the patch looks ok but unfortunately does not always solves the problem,
> something in the chain misalignes the symbol
--- Comment #33 from nickc at redhat dot com 2008-10-06 12:43 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi,
> http://people.netfarm.it/~sherpya/gcc/info.7z
Just a quick check: If you build with "-fno-common" does t
--- Comment #35 from nickc at redhat dot com 2008-10-06 16:43 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi sherpya,
> --- Comment #34 from sherpya at netfarm dot it 2008-10-06 14:13 ---
> $ nm ffmpeg_g.exe |grep ff_
--- Comment #37 from nickc at redhat dot com 2008-10-06 17:24 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi,
> so how with -fno-common can make aligned work?
Hang on - I thought that you had said that when ffmpeg_g.exe was bu
--- Comment #39 from nickc at redhat dot com 2008-10-06 18:16 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
> yes alignment works, and even my test align program with 4.2 without patches
> gives correct alignment to local and
--- Comment #45 from nickc at redhat dot com 2008-10-07 11:37 ---
Created an attachment (id=16475)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16475&action=view)
Enable -fno-common with -msse for Cygwin/Mingw
--
nickc at redhat dot com changed:
What|
--- Comment #46 from nickc at redhat dot com 2008-10-07 11:38 ---
Hi Brian,
> IMHO, we should just have gcc automatically enable -fno-common on PE if
> SSE is enabled. That's what the MS tools do, AFAICT.
Something like the newly uploaded patch ?
Cheers
Nick
--- Comment #44 from nickc at redhat dot com 2008-10-07 10:57 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
sherpya at netfarm dot it wrote:
> I mean that with -fno-common alignment works, even with non patched 4.2, my
> question
roduct: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nickc at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet
--- Comment #3 from nickc at redhat dot com 2008-11-10 13:49 ---
Hi Guys,
I have uploaded a potential patch for the problem. It fixes the testcase
originally provided and does not introduce any regressions into the g++
testsuite for an i686-pc-linux-gnu toolchain.
That's the
--- Comment #4 from nickc at redhat dot com 2008-11-10 16:22 ---
Created an attachment (id=16645)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16645&action=view)
Testcase for the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862
--- Comment #5 from nickc at redhat dot com 2008-11-10 16:22 ---
Oops - almost forgot - the bug needs a testcase for the g++ testsuite, so I
have uploaded a patch to add that as well.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862
--- Comment #2 from nickc at redhat dot com 2008-11-10 13:36 ---
Created an attachment (id=16644)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16644&action=view)
Allow postfix parser to pass cp_id_kind information back to the primary parser
--
http://gcc.gnu.org/b
--- Comment #9 from nickc at redhat dot com 2008-01-23 13:13 ---
Created an attachment (id=15007)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15007&action=view)
Improve --help= output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
--- Comment #10 from nickc at redhat dot com 2008-01-23 13:13 ---
Subject: Re: [4.3 Regression] gcc -v --help returns no options
for C, C++
Hi Manuel,
> % gcc -v --help=c
>
> returns the following for me
>
> The following options are language-independ
--- Comment #4 from nickc at redhat dot com 2008-02-13 10:45 ---
Created an attachment (id=15135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15135&action=view)
Suppress elimination of the frame pointer to the stack pointer in thumb mode
--
http://gcc.gnu.org/b
--- Comment #5 from nickc at redhat dot com 2008-02-13 10:49 ---
Hi Jim,
Given that this bug does not exist in the more modern 4.x gcc series I am
tempted to just suggest that you upgrade your toolchain. On the assumption
however that this is not a viable option for you I have
--- Comment #13 from nickc at redhat dot com 2008-02-19 14:12 ---
Subject: Re: [4.3 Regression] gcc -v --help returns no options
for C, C++
Hi Manu,
> Didn't this got approved for GCC 4.3?
No. :-(
> Also:
>
> + description = _("The following optio
--- Comment #15 from nickc at redhat dot com 2008-02-19 15:11 ---
Subject: Re: [4.3 Regression] gcc -v --help returns no options
for C, C++
Hi Manu,
> Too bad. On the other hand, we can close this, can't we?
Yes I agree.
Cheers
Nick
--
http://gcc.gnu.org/
--- Comment #2 from nickc at redhat dot com 2008-03-26 12:29 ---
Created an attachment (id=15380)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15380&action=view)
Do not allow INT+INT as a legitimate addressing mode
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
--- Comment #3 from nickc at redhat dot com 2008-03-26 12:30 ---
Hi Mike,
The attached patch takes care of this. I will be applying it shortly.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
--- Comment #5 from nickc at redhat dot com 2008-03-26 14:16 ---
Subject: Re: Problem while compiling gcc for mn10300-elf
Hi Jeff,
> What does CLASS, MODE and IN look like?
Err, presumably you are talking about these values when
default_secondary_reload() triggers the abort ?
--- Comment #7 from nickc at redhat dot com 2008-03-27 08:26 ---
Subject: Re: Problem while compiling gcc for mn10300-elf
Hi Jeff,
>> The CLASS is DATA_OR_EXTENDED_REGS.
>>(plus:SI (reg/f:SI 9 sp)
>>(const_int 1100 [0x44c]))
> Hmm, so why isn'
--- Comment #9 from nickc at redhat dot com 2008-03-28 08:43 ---
Hi Jeff,
Thanks - I have checked the patch in.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
--- Comment #13 from nickc at redhat dot com 2008-03-28 09:31 ---
Subject: Re: Problem while compiling gcc for mn10300-elf
Hi Mike,
> Can the patch be applied to the 4.3 branch too?
Done.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
--- Comment #6 from nickc at redhat dot com 2008-03-28 09:33 ---
Subject: Re: Problem while compiling gcc for xstormy16-elf
Hi Mike,
> Can the patch be applied to the 4.3 branch too?
Done.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
--- Comment #14 from nickc at redhat dot com 2009-03-11 16:09 ---
Created an attachment (id=17439)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17439&action=view)
Document the FR30 target options
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362
--- Comment #15 from nickc at redhat dot com 2009-03-11 16:09 ---
Hi Guys,
I have checked in a patch to add documentation for the FR30 target options.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362
--- Comment #17 from nickc at redhat dot com 2009-03-11 16:57 ---
Created an attachment (id=17441)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17441&action=view)
Add descriptions of MCore options
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362
--- Comment #18 from nickc at redhat dot com 2009-03-11 16:59 ---
Hi Guys,
I have checked in a patch to add descriptions of the MCore options.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362
--- Comment #1 from nickc at redhat dot com 2009-04-14 15:14 ---
Created an attachment (id=17633)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17633&action=view)
Do not assume that comparisons with small integers will always produce a short
branch
--
http://gcc.
--- Comment #2 from nickc at redhat dot com 2009-04-14 15:15 ---
Hi Paolo
I am going to apply the uploaded patch to fix this problem.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39601
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306
--- Comment #1 from Nick Clifton 2012-08-19 07:10:01
UTC ---
Created attachment 28049
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28049
Remove offending #endif
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306
--- Comment #3 from Nick Clifton 2012-08-19 07:13:25
UTC ---
Hi Daniel,
Thanks for catching this. It was a snafu, corrected with the obvious fix you
suggested.
Cheers
Nick
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54661
--- Comment #2 from Nick Clifton 2012-10-09 08:39:03
UTC ---
This was due to a silly typo, now fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
--- Comment #4 from Nick Clifton 2011-10-06 14:21:57
UTC ---
Created attachment 25430
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25430
workaround for bb live register checking problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
--- Comment #5 from Nick Clifton 2011-10-06 14:25:16
UTC ---
Hi Paulo,
Thanks for the step by step guide. I can now reproduce the problem.
It looks to me like a generic problem in the live register analysis code.
Which is a but beyond my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
--- Comment #10 from Nick Clifton 2011-10-10 13:33:45
UTC ---
Hi Paulo,
This should be fixed now.
Cheers
Nick
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49777
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53187
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507
--- Comment #1 from Nick Clifton ---
Created attachment 30910
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30910&action=edit
Fix objdump output
Proposed patch to fix objdump output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507
--- Comment #2 from Nick Clifton ---
Created attachment 30916
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30916&action=edit
Add parsing of known MSP430 MCU types
I am currently testing this patch to see if it introduces any regressions in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507
--- Comment #3 from Nick Clifton ---
Hi Ilya,
I have now checked my patches in. If you use the latest (development) FSF
sources for GCC and the binutils you should see that correct parsing of the
-mmcu command line option and the correct displ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51377
Bug #: 51377
Summary: ICE when generating debug info for targets with
multiple pointer sizes
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51377
--- Comment #1 from Nick Clifton 2011-12-01 10:44:57
UTC ---
Created attachment 25967
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25967
Test for mixed pointer modes in the assertion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51377
--- Comment #2 from Nick Clifton 2011-12-01 10:54:35
UTC ---
[Darn - hit return too early].
When compiling for a target that supports multiple pointer sizes (eg s390)
generating debug information can trigger an ICE in the compiler:
% s390-gcc
--- Comment #3 from nickc at redhat dot com 2007-07-03 10:59 ---
Subject: Re: [4.3 Regression] gcc -v --help returns no options
for C, C++
Hi Mark,
> Nick, would you be able to look into this?
Certainly - I'll get on it today.
Cheers
Nick
--
http://gcc.gnu.org/
--- Comment #4 from nickc at redhat dot com 2007-07-03 16:26 ---
Hi Brooks,
I do not think that this is a bug, but rather a feature. The command line
options are all still in the "--help -v" otuput, they are just in different
locations. For example the -Wall option is now
--- Comment #3 from nickc at redhat dot com 2007-07-04 13:28 ---
Hi Rask,
Well the patch is definitely an improvement, so I have applied it. I will
try to find time to look at the regressions in the next week or two.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #7 from nickc at redhat dot com 2007-07-04 13:40 ---
Subject: Re: [4.3 Regression] gcc -v --help returns no options
for C, C++
Hi Brooks,
> So, if I understand correctly: all of the options are listed somewhere, but we
> no longer provide any information about wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #13 from Nick Clifton ---
Hi Aldy,
> pc: 8ca4, instr: e1c520fc
> pc: 4, instr: ea00089b
>
> I took a peek at the executable being run with "/my-arm-build/objdudump -D
> the-executable.exe", and I see we are failing in
> initialise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028
--- Comment #11 from Nick Clifton ---
Hi Richard,
> If the backend doesn't support mixing of -msingle-float/-mno-single-float
> within a compilation unit then this will only work if the user didn't mix TUs
> with conflicting setting at link-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #20 from Nick Clifton ---
Hi Aldy,
>>> for the store is not double word aligned. Which leads me to wonder,
>>> what value is stored in r5 when the STRD instruction is being executed ?
>>
>> 1: x/i $pc
>> => 0x8c24 : strdr2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #21 from Nick Clifton ---
Hi Aldy,
>>> instruction. :-( Looking at the code in Handle_Store_Double() in
>>> sim/arm/armemu.c, I think that the reason is probably because the address
>>> for the store is not double word aligned. Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #23 from Nick Clifton ---
Hi Guys,
>> But, as you have just discovered, (r5 + 12) is not 64-bit aligned...
>
> But from ARMv7 onwards it only has to be 4-byte aligned, which it is. And
> this
> code was build for cortex-a9, which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55351
--- Comment #1 from Nick Clifton 2012-11-19 16:01:36
UTC ---
Created attachment 28732
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28732
Fixes to allow libgcc to build for the sh64-linux target
I am no SH expert, so this patch ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #4 from Nick Clifton ---
Created attachment 35123
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35123&action=edit
Disable the generation of real_jump insns
This patch works around the problem by disabling the generation of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
--- Comment #4 from Nick Clifton ---
Created attachment 35376
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35376&action=edit
Patch resend
Darn - apparently the previous version of this patch suffered from TAB/space
corruption. So here i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
--- Comment #5 from Nick Clifton ---
Created attachment 35379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35379&action=edit
this time with a %0xlx
Hi Guys,
*sigh* this has not been my day. The previous two patches both had a sma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57232
--- Comment #17 from Nick Clifton ---
Hi Alex,
> if (reg != hard_frame_pointer_rtx && fixed_regs[REGNO (reg)])
> cselib_preserve_cfa_base_value (val, REGNO (reg));
This works for the RX port - thanks!
Cheers
Nick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54882
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67702
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2
1 - 100 of 148 matches
Mail list logo
