[Bug demangler/88539] A memory leak issue was discovered in cplus-dem.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88539 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #4

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

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

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

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

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

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,

[Bug target/68028] [6/7/8 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC

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

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

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

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

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 approval

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

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. */ >

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

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

[Bug target/43052] [4.9/5/6 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #32

[Bug target/60410] [4.9/5/6 Regression] -fshort-double ICEs x86_64

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.

[Bug target/60410] [4.9/5/6 Regression] -fshort-double ICEs x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #14

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 --- Comment #8 from Nick Clifton --- Patch applied. (Unfortunately I cannot close this BZ...)

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

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&action=edit Initialise the t_icode field of the sri structure created by copy_cost. Hi Markus, Please could you try out t

[Bug testsuite/68913] [6 Regression] gcc.dg/lto/pr61886 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68913 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1

[Bug bootstrap/67598] [6 Regression] Target powerpc-e500v2-linux-gnuspe failed to bootstrap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67598 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3

[Bug ipa/66764] [6 Regression] ICE in analyze_function() on AIX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66764 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #8

[Bug c++/68795] [6 Regression] Use of uninitialised value of size 8 in cp_parser_postfix_expression (parser.c:6831)

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

[Bug c++/68795] [6 Regression] Use of uninitialised value of size 8 in cp_parser_postfix_expression (parser.c:6831)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68795 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #5

[Bug preprocessor/68638] [6 Regression] ICE in linemap_macro_map_lookup

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68638 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1

[Bug rtl-optimization/68304] [6 Regression] FAIL: gcc.c-torture/compile/950612-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68304 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1

[Bug c++/67702] [4.9/5/6 Regression] Internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67702 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3

[Bug target/54882] build fails for rl78-elf building libstdc++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54882 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #5

[Bug rtl-optimization/66156] [msp430] wrong code generated with -O2 -mlarge (zero extension HI -> SI)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1

[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu

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

[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu

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

[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3

[Bug target/65052] ICE in c6x-uclinux target when building libgcc

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

[Bug target/64407] xstormy16-elf: ICE in simplify_const_unary_operation, at simplify-rtx.c:1730

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64407 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug target/64408] fr30-elf ICE in extract_insn, at recog.c:2202

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug target/64027] inefficient handling of msp430 byte operands

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug target/64160] msp430 code generation error adding 32-bit integers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160 --- Comment #6 from Nick Clifton --- 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 to the bug. > B.t.w. i

[Bug target/64160] msp430 code generation error adding 32-bit integers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 --- Comment #9 from Nick Clifton --- 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 Nick

[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 --- Comment #3 from Nick Clifton --- 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) (const_int 2

[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug target/63901] msp430 multilib must distinguish mhwmult

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901 --- Comment #4 from Nick Clifton --- 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 was processed to produ

[Bug target/63901] msp430 multilib must distinguish mhwmult

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901 --- Comment #2 from Nick Clifton --- 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. In the long term we

[Bug target/63901] msp430 multilib must distinguish mhwmult

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1

[Bug target/63709] msp430 Y constraint generates unacceptable constant in large mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63709 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1

[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #6

[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug target/57232] wcstol.c:213:1: internal compiler error

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

[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`

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

[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`

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

[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`

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

[Bug target/35294] iwmmxt intrinsics, internal compiler error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com

[Bug target/55351] can't build libgcc for -m5-compact variant in SH64

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

[Bug target/54661] mcore_output_movedouble: operation on ‘memexp’ may be undefined

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.

[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h

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

[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h

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

[Bug target/53187] ICE in arm_select_dominance_cc_mode

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53187 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3

[Bug debug/51377] ICE when generating debug info for targets with multiple pointer sizes

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

[Bug debug/51377] ICE when generating debug info for targets with multiple pointer sizes

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.

[Bug debug/51377] New: ICE when generating debug info for targets with multiple pointer sizes

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

[Bug c++/49777] for c++ code, without -g option, cannot generate PIC *.so library.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49777 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3

[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend

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

[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend

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

[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend

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

[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2

[Bug middle-end/49899] New: ICE when redeclaring a static function as weak

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 AssignedTo

[Bug target/49402] Duplicate use of v850.opt

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49402 --- Comment #2 from Nick Clifton 2011-06-14 15:32:49 UTC --- Fixed in mainline.

[Bug target/49403] v850e-elf: incompatible pointer type (near initialization for ‘targetm.memory_move_cost’)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49403 --- Comment #2 from Nick Clifton 2011-06-14 15:32:13 UTC --- Fixed in mainline.

[Bug target/48899] enum conversion initializing global_options_init.x_iq2000_tune

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48899 --- Comment #2 from Nick Clifton 2011-05-09 10:07:20 UTC --- I have checked in a patch to initialise the iq2000_tune variable, thus eliminating the warning.

[Bug target/48897] mn10300.c:extract_bundle’: error: variable ‘s’ set but not used

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48897 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

[Bug target/46432] v850-elf --enable-werror-always build fails

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46432 --- Comment #3 from Nick Clifton 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 the definitions. They a

[Bug target/45000] RX signed extened unsigned char or short return value.

--- 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 r

[Bug target/45000] RX signed extened unsigned char or short return value.

--- 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=21338&action=view) Force functions that return small unsigned values to use zero-extension -- http://gcc.gnu.org/b

[Bug target/45000] RX signed extened unsigned char or short return value.

--- 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 expe

[Bug c/44438] New: ISO C99 6.7.4p3 not obeyed in C99 mode

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 triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44438

[Bug target/39601] xstormy16 target broken, cannot build newlib

--- 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

[Bug target/39601] xstormy16 target broken, cannot build newlib

--- 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.

[Bug target/5362] Undocumented target options

--- 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

[Bug target/5362] Undocumented target options

--- 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

[Bug target/5362] Undocumented target options

--- 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

[Bug target/5362] Undocumented target options

--- 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

[Bug c++/37862] Parenthesised indirection alters class member access

--- 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

[Bug c++/37862] Parenthesised indirection alters class member access

--- 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

[Bug c++/37862] Parenthesised indirection alters class member access

--- 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

[Bug c++/37862] Parenthesised indirection alters class member access

--- 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

[Bug c++/37862] New: Parenthesised indirection alters class member access

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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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|

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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_

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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|

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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|

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

--- 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

  1   2   >