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
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.
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
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
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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #31 from Nick Clifton ---
Hi Alexander,
> Nick, can you please post the patch to gcc-patches too, to avoid confusing
> future people who wouldn't be able to find the explanation of the patch in the
> archives?
> (did you get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012
--- Comment #18 from Nick Clifton ---
Hi Bernd,
> I am still unsure, if we shouldn't also do something like this,
> to prevent any remaining possibility for a further regression:
> + /* Don't change the frame info after reload completed. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #11 from Nick Clifton ---
Hi Marek,
> You need to sign in with your @gcc.gnu.org address.
Doh! Totally forgot about that. Thanks!
Cheers
Nick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410
--- Comment #15 from Nick Clifton ---
Sorry I meant:
I am not sure of the best way to proceed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770
--- Comment #8 from Nick Clifton ---
Patch applied. (Unfortunately I cannot close this BZ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770
--- Comment #5 from Nick Clifton ---
Created attachment 37099
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37099=edit
Initialise the t_icode field of the sri structure created by copy_cost.
Hi Markus,
Please could you try out the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68795
--- Comment #4 from Nick Clifton ---
Hi David,
> Bother; I have another patch for this I was about to post, which is
> bootstrapping right now
Oops - sorry for treading on your toes!
Cheers
Nick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67598
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66764
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68913
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68795
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68304
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68638
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1
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=54882
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2
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=66156
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
--- Comment #5 from Nick Clifton nickc at redhat dot com ---
Created attachment 35379
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35379action=edit
this time with a %0xlx
Hi Guys,
*sigh* this has not been my day. The previous two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
--- Comment #4 from Nick Clifton nickc at redhat dot com ---
Created attachment 35376
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35376action=edit
Patch resend
Darn - apparently the previous version of this patch suffered from TAB/space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #4 from Nick Clifton nickc at redhat dot com ---
Created attachment 35123
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35123action=edit
Disable the generation of real_jump insns
This patch works around the problem by disabling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64407
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160
--- Comment #6 from Nick Clifton nickc at redhat dot com ---
Hi Ulrich,
if (reg_overlap_mentioned_p (operands[3], operands[7])
|| reg_overlap_mentioned_p (operands[3], operands[8]))
FAIL;
Thanks - that is indeed a better solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
--- Comment #9 from Nick Clifton nickc at redhat dot com ---
Hi Ulrich,
Thanks - ypur patch does work, and it is certainly better than mine. Will
you be applying it to the gcc mainline sources ? (And maybe the 4.9 branch as
well ?)
Cheers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
--- Comment #3 from Nick Clifton nickc at redhat dot com ---
Hi Alex,
This appears to be a reload bug. Before reload we have:
(call_insn 12 (call:HI (mem:HI (mem:HI (plus:HI (reg:HI R14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901
--- Comment #4 from Nick Clifton nickc at redhat dot com ---
Hi Peter,
In mspgcc, TI provided a CSV file that listed every device along with all
its characteristics. This is still present in the GCC header bundle TI
provides. This in turn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901
--- Comment #2 from Nick Clifton nickc at redhat dot com ---
Hi Peter,
The whole hardware multiply selection thing is a bit of a mess...
The uploaded patch should resolve the problem for now by building newlib with
software multiply enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63709
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57232
--- Comment #17 from Nick Clifton nickc at redhat dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507
--- Comment #3 from Nick Clifton nickc at redhat dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507
--- Comment #1 from Nick Clifton nickc at redhat dot com ---
Created attachment 30910
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30910action=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 nickc at redhat dot com ---
Created attachment 30916
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30916action=edit
Add parsing of known MSP430 MCU types
I am currently testing this patch to see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55351
--- Comment #1 from Nick Clifton nickc at redhat dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54661
--- Comment #2 from Nick Clifton nickc at redhat dot com 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=54306
--- Comment #1 from Nick Clifton nickc at redhat dot com 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 nickc at redhat dot com 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=53187
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat dot
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51377
--- Comment #1 from Nick Clifton nickc at redhat dot com 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 nickc at redhat dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49777
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
--- Comment #10 from Nick Clifton nickc at redhat dot com 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=49801
--- Comment #4 from Nick Clifton nickc at redhat dot com 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 nickc at redhat dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
CC||nickc at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49899
Summary: ICE when redeclaring a static function as weak
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49403
--- Comment #2 from Nick Clifton nickc at redhat dot com 2011-06-14 15:32:13
UTC ---
Fixed in mainline.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49402
--- Comment #2 from Nick Clifton nickc at redhat dot com 2011-06-14 15:32:49
UTC ---
Fixed in mainline.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48897
Nick Clifton nickc at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48899
--- Comment #2 from Nick Clifton nickc at redhat dot com 2011-05-09 10:07:20
UTC ---
I have checked in a patch to initialise the iq2000_tune variable, thus
eliminating the warning.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46432
--- Comment #3 from Nick Clifton nickc at redhat dot com 2010-11-15 12:37:35
UTC ---
Hi Joern,
FWIW, following the GNU coding standard advice on 'swallowing the semicolon'
avoids the warning:
I think that it would be better to just delete
--- Comment #3 from nickc at redhat dot com 2010-07-28 13:55 ---
Created an attachment (id=21338)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21338action=view)
Force functions that return small unsigned values to use zero-extension
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from nickc at redhat dot com 2010-07-28 14:05 ---
Hi Kazuhiro-san,
If the func() is external function, output code is the following.
bsr_func
mouv.B r1, r1
If the return value is zero exteneded,
movu.B r1, r1 code can be removed.
Not really. The problem
--- Comment #1 from nickc at redhat dot com 2010-07-22 09:42 ---
Hi Kazuhiro-san,
This is not a bug, it is the expected behaviour.
What is happening is that the return value from func() is being promoted to
signed int (and not unsigned int as you might expect). Thus since the
MOV.B
ReportedBy: nickc at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44438
--- 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=17633action=view)
Do not assume that comparisons with small integers will always produce a short
branch
--
http://gcc.gnu.org
--- 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
--- 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=17439action=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=17441action=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 #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 good
--- 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=16645action=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=16644action=view)
Allow postfix parser to pass cp_id_kind information back to the primary parser
--
http://gcc.gnu.org/bugzilla
: 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: i686-pc-linux-gnu
GCC target
--- 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=16475action=view)
Enable -fno-common with -msse for Cygwin/Mingw
--
nickc at redhat dot com changed:
What|Removed
--- 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
--
http
--- 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 is due
--- 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 the executable
--- 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_cos_16
--- 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 built
--- 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 global
--- 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 #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 this, however
--- 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=16458action=view)
Revised patch which handles (size == 0)
--
nickc at redhat dot com changed:
What|Removed
--- 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 using sse
--- 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=16425action=view)
Revised patch with correct section switching
--
nickc at redhat dot com changed:
What|Removed
--- 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 #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=16303action=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 #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
1 - 100 of 147 matches
Mail list logo