[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 is ARMv7-a. Ok, so this is a simulator bug. Aldy - these easiest thing for now would be to unilaterally relax the alignment test in Handle_Store_Double and see if that allows you to get further with your tests. (But yes, I agree, a reduced testcase would be a much better help than all this mucking about in the simulator). Cheers Nick
[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. Which leads me to wonder, >>> what value is stored in r5 when the STRD instruction is being executed ? >> => 0x8c24: strdr2, [r5, #12] >> (gdb) info reg r5 >> r5 0x1b6e8 112360 >> ...which is 64 bit aligned. But, as you have just discovered, (r5 + 12) is not 64-bit aligned...
[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, [r5, #12] >> (gdb) info reg r5 >> r5 0x1b6e8 112360 >> ...which is 64 bit aligned. Hmm, curious. OK - my next recommendation would be to add some printf()s to the simulator to find out a) if Handle_Store_Double() really is being called, or if the abort is happening somewhere else. Plus, if it is being called, then b) where inside that function the abort is happening. Maybe the store operations are triggering a memory access failure. Cheers Nick
[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. So the following will not be diagnosed > but will instead have conflicting IL accepted silently with your > patch (with unknown effect): > >> gcc -c t1.c -flto -msingle-float >> gcc -c t2.c -flto -mdouble-float >> gcc t1.o t2.o -flto But even without the patch, if the user does the above, but leaves out the final -flto then the problem will still not be diagnosed: gcc -c t1.c -flto -msingle-float gcc -c t2.c -flto -mdouble-float gcc t1.o t2.o That is, unless the linker detects and reports this problem. Which it does. There are tags recorded in the build notes which specify the precision of floating point used, and the linker will complain if these do not match. So, since the linker will report conflicts there is no need for the LTO compiler to do so. Especially when, as this bug report shows, it gets the warning wrong under some circumstances. So I still think that my patch is viable. Comments ? Cheers Nick
[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_monitor_handles(). > This suggests we're failing during the start-up code: > 8ca4: e1c520fcstrdr2, [r5, #12] > > It seems that last store is corrupting things and making us jump to a PC of > 4??? Address 4 is the "undefined instruction" vector. If the simulator thinks that the instruction is illegal/unknown then it will branch to address 4 and start executing from there. (Or else it loads the value stored at address 4 and starts executing from that address. I forget which). So, this basically means that the simulator does not like that STRD 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. Which leads me to wonder, what value is stored in r5 when the STRD instruction is being executed ? > Am I running the simulator correctly? Yes. > Does it require a special flag for > cortex-a9? No. > Is the cortex-a9 CPU even handled by the simulator? Yes. > Should I run the dejagnu tests with -mcpu= or whatever, or is the > --with-cpu=cortex-a9 configury flag enough? Be paranoid - add the option. :-) > Does the arm newlib/libgloss/whatever code have instructions that aren't > handled by the GDB simulator? No. Well not in the assembler parts of it. The possible exception to this are the memory manipulation functions (memcpy, strlen ,etc) in newlib/libc/ sys/arm/ which tend to be very tightly coded, and will often be updated to take advantage of new instructions as they are added to the ISA. Of course the C parts of these libraries might use unsupported instructions if gcc generates them. But if you have configured gcc correctly (and I think that you have) then this should not be an issue. Cheers Nick
[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 for this patch offline?) Oh foo - no I did not. I will post to gcc-patches now. If approval is forthcoming quickly then I will leave things as they are. Otherwise I will revert my patch and wait for proper authorisation. Sorry about mucking up. Cheers Nick
[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. */ > + if (reload_completed) > +return; Actually that might not be a bad idea. Or maybe, to be even more paranoid, we should check that a post-reload frame computation matches the last pre-reload frame computation. Hmm, maybe that is going to far. Anyway I like your patch idea, but I cannot approve it. Maybe the MIPS maintainers will like it... Cheers Nick
[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/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 from Nick Clifton --- Created attachment 37275 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37275=edit Use SFmode variant of DFmode builtin vector types when -fshort-doubles is enabled. Hi Guys, I recently created and posted a patch for PR 55113 which also fixes this PR. (Patch attached here for easy reference). One reviewer however has suggested that a better solution would be to disable -fshort-double option entirely: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01900.html I am not of the best way to proceed. Any suggestions ? Cheers Nick
[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/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 from Nick Clifton --- Is this PR still a problem ? I tried building the testcase from comment #1 today and found the memcmp is being called even at -O3. The run times are approximately the same for -O3 and -O0 as well. Cheers Nick
[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=edit Initialise the t_icode field of the sri structure created by copy_cost. Hi Markus, Please could you try out the uploaded patch. I am currently running regression tests, but if it passes, and it works for you, then I will submit it for review. 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 --- 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 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 from Nick Clifton --- (In reply to Arseny Solokha from comment #2) > Fixed during the last week, as of 6.0.0-alpha20151122 snapshot (in r230440, > apparently). If it is fixed, please could you close this PR ? Cheers Nick
[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 from Nick Clifton --- Created attachment 37079 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37079=edit Convert to unsigned before shifting (In reply to Jakub Jelinek from comment #7) > The question is about the others, but it has been so long that the > locations are all useless. I have just checked. The only problems that still remain are in libiberty/regex.c. The uploaded patch fixes this problem. I plan to submit it for review after running a few more regression tests.
[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 from Nick Clifton --- Hi David, > Analyzing compilation unit I am unable to reproduce this ICE. What command line options were being used when it happened ? Cheers Nick
[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 from Nick Clifton --- Hi Markus, How do I reproduce this ? IE please could you upload a testcase to demonstrate this problem. Cheers Nick
[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 from Nick Clifton --- Created attachment 37086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37086=edit Provide weak version of __fread_chk It seems to me that we could solve this problem by providing our own definition of __fread_chk. It does not have to work, since this is a link test, and the real purpose of the test is to check that __fread_chk_warn is not referenced at link time. So I plan on submitting the uploaded patch after a few more local checks.
[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 from Nick Clifton --- Created attachment 37064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37064=edit Define MAKE_DECL_ONE_ONLY for cygming targets Hi Guys, I think that this patch should resolve the problem, although I do not have the means to test it locally. The issue I believe is not that the ming32 definition of bind_local_p is wrong, but rather than G++ thinks that it cannot make the decl weak even though bind_local_p says that it should. By defining MAKE_DECL_ONE_ONLY we allow G++ to make the decl weak and so the compilation works. Well that is the theory at least... If someone could test out this patch I would be very grateful. 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 from Nick Clifton --- Created attachment 37066 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37066=edit Always set a location for the closing parenthesis in cp_parser_parenthesized_expression_list Hi Guys, This patch fixes the problem, although it may not be the best way to resolve the bug. The problem is that cp/parser.c:cp_parser_postfix_expression assumes that cp_parser_parenthesized_expression_list always sets a value for the location of the closing parenthesis, even if there is an error in the parsing. This location is then passed to make_location and on down until it is eventually used in libcpp/line-map.c:location_adhoc_data_hash. This is where valgrind detects the unitinialised use. (Although it reports the location as being somewhere else). The uploaded patch makes cp_parser_parenthesized_expression_list set a default, unknown, location for the closing parenthesis first, and then later on it can be overridden with the correct location if one is found. This means that all callers of cp_parser_parenthesized_expression_list can now assume that the closing parenthesis location will be set. An alternative patch would be to make cp_parser_parenthesized_expression_list set the location to unknown only if it cannot find the location, or to just modify cp_parser_postfix_expression so that it initialises the location to unknown before calling cp_parser_parenthesized_expression_list. Cheers Nick
[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 from Nick Clifton --- Hi John, I just tried to reproduce this using the current (r231159) sources and I could not. Ie the test compiled without problems. Perhaps this bug has already been fixed ? Cheers Nick
[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 from Nick Clifton --- Hi Martin, I tried to reproduce this problem using the latest (r231159) sources bug could not. I tried both an x86_64-pc-linux-gnu toolchain and an mep-elf toolchain. Is it possible that this bug has already been fixed ? Cheers Nick
[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 from Nick Clifton --- Created attachment 36826 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36826=edit Workaround This patch avoids the problem. Not sure if it is the correct fix though. There is a comment in mangle.c:decl_mangling_context() which says "template type parms have no mangling context." and it is this which is causing write_template_prefix() to crash - it assumes that there is always a context available. But maybe template type parameters should never be passed to template_write_prefix ?
[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 from Nick Clifton --- I just tried building the toolchain with r230800 and it worked without any problems...
[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 from Nick Clifton --- Ping ? The patch works for us, and fixes a problem that a customer was having, so we would really like to see it checked in. Cheers Nick
[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 nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton nickc at redhat dot com --- Hi Ronald, What's going on is that this is a reload bug. Reload wants to extend r42 into r43 (or rather r12 into r10) and it is assuming that the zero_extendhisi pattern will do this. Unfortunately it does not, it only extends in place, and so an extra move is required to make the conversion complete. Reload generates this extra move, but of course it is too late, r13 has already been clobbered. Not being a reload guru, I have decided to take the easy way out and extend the zero_extendhisi2 pattern so that it can cope with moving the value whilst extending it. This works, although it does still leave a potential bug in reload for other targets. But for now it is the simplest solution. So I am going to apply this patch to the msp430 sources. Please let me know if you have any problems with it. Cheers Nick Index: gcc/config/msp430/msp430.md === --- gcc/config/msp430/msp430.md (revision 223348) +++ gcc/config/msp430/msp430.md (working copy) @@ -588,10 +588,12 @@ ;; patterns. Doing these manually allows for alternate optimization ;; paths. (define_insn zero_extendhisi2 - [(set (match_operand:SI 0 nonimmediate_operand =rm) - (zero_extend:SI (match_operand:HI 1 nonimmediate_operand 0)))] + [(set (match_operand:SI 0 nonimmediate_operand =rm,r) + (zero_extend:SI (match_operand:HI 1 nonimmediate_operand 0,r)))] msp430x - MOV.W\t#0,%H0 + @ + MOV.W\t#0,%H0 + MOV.W\t%1,%L0 { MOV.W\t#0,%H0 ) (define_insn zero_extendhisipsi2
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
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 dot com --- Comment #3 from Nick Clifton nickc at redhat dot com --- Created attachment 35373 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35373action=edit Use %lx/%ld to print long types Hi Guys, Here is a patch to fix this problem. The bug is that in a couple of places the microblaze backend is using %llx to print out the value of a long type. On a 64-bit host this does not matter, but compiling on a 32-bit host the result is extra garbage digits in the output. Cheers Nick
[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 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 patches both had a small thinko in them - I was printing a hex value into the assembler file without a preceeding 0x prefix... Doh. So, a third attempt at the patch is attached. Cheers Nick
[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 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 corruption. So here is a resend of the patch
[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 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 the generation of the real_jump insns. I am not enough of a C6X expert to determine why these instruction patterns are not working, but they are definitely part of the problem.
[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 nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton nickc at redhat dot com --- This is fixed in the mainline sources. I have not tracked where though. Cheers Nick
[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 nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton nickc at redhat dot com --- Fixed by: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00247.html
[Bug target/64027] inefficient handling of msp430 byte operands
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 dot com --- Comment #2 from Nick Clifton nickc at redhat dot com --- Hi Peter, I have applied a patch to the linker: https://sourceware.org/ml/binutils/2015-01/msg00090.html This will transform the 4-byte BR instructions into 2-byte JMP instructions, which the code size issue you raised as point 2. Cheers Nick
[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 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 to the bug. B.t.w. is there a particular reason why the target-specific msp430_subreg is needed instead of the usual operand_subword? I am not sure. According to the comments in msp430.c it is because; Simplify_gen_subreg() doesn't handle memory references the way we need it to below, so we use this function for when we must get a valid subreg in a 'natural' state. I think that this is all connected with the fact that for the MSP430 in large mode, pointers are 20-bits long, and that this tends to confuse gcc. Cheers Nick
[Bug target/64160] msp430 code generation error adding 32-bit integers
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 dot com --- Comment #2 from Nick Clifton nickc at redhat dot com --- Created attachment 34232 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34232action=edit Proposed patch Hi Peter, Please try out this patch and let me know what you think. 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 #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 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 Nick Clifton nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton nickc at redhat dot com --- Created attachment 34168 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34168action=edit Patch for reload to avoid using argument regiesters when reloading a call insn
[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 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) (const_int 2 (const_int 0)) After reload this becomes: (insn 17 (set (reg:HI R14) (mem:HI (plus:HI (reg:HI R14) (const_int 2) (call_insn 12 (call:HI (mem:HI (reg:HI R14)) (const_int 0))) The uploaded patch fixes this but, not being a reload expert, I am not sure if this is the correct way to solve the problem. It also seems suspicious that if this is a generic reload problem, then why has it not been reported and fixed before now ?
[Bug target/63901] msp430 multilib must distinguish mhwmult
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 was processed to produce a specs fragment that provided rules to default all the -m* flags from a specific -mmcu= value. Could the tool that converted the CSV file into a spec fragment be altered so that it produces the relevent -mhwmult= option based upon an MCU input ? Ie would it be possible to provide the users with a tool that takes an MCU name, reads in the CSV file and outputs the correct -mhwmult option ? Somthing like: msp430-elf-gcc `gen-hwmult-opt -mmcu=foo` If the tool was stand-alone then it would not need to be updated when the CSV file changes, and it could work with any CSV file, old or new. Cheers Nick PS. I have applied the patch to the newlib sources so that at least that part of the problem is resolved for now.
[Bug target/63901] msp430 multilib must distinguish mhwmult
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 dot com --- Comment #1 from Nick Clifton nickc at redhat dot com --- Created attachment 33997 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33997action=edit Built newlib with -mhwmult=none
[Bug target/63901] msp430 multilib must distinguish mhwmult
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. In the long term we ought to work out a way to enable multilib versions of newlib based upon the hardware multiply supported. The problem with that is that multilib selection is based solely upon the command line options used which means that a list of all known MSP430 MCU types would probably have to be built into the specs - a bad idea that will fail as soon as a new MCU type is created. Cheers Nick
[Bug target/63709] msp430 Y constraint generates unacceptable constant in large mode
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 dot com --- Comment #1 from Nick Clifton nickc at redhat dot com --- Hi Peter, Sorry - this was a snafu in the assembler. Its range checking of 20-bit immediates was not quite right. This is now fixed however so please update your master binutils sources and try again. Cheers Nick PS. The patch is also in the 2.25 branch...
[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 nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #6 from Nick Clifton nickc at redhat dot com --- Created attachment 33562 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33562action=edit Patch to fix typo in sync.md This bug is due to a typo in the sync.md file. I will be applying the uploaded patch to fix it shortly.
[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 nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton nickc at redhat dot com --- Hi Rainer, Given that the 2.9 target is deprecated, do we really care about this problem ? Also - when I tried to assemble the file you uploaded I had no problems. This was using gas built from today's FSF mainline binutils sources, but I also tried a version built from the 2.24 sources and the 2.23 sources - they all worked. Cheers Nick
[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 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 Nick
[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`
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 option and the correct display of the MSP430 architecture variant. Cheers Nick
[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`
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
[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`
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 if it introduces any regressions into the gcc testsuite...
[Bug target/35294] iwmmxt intrinsics, internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294 Nick Clifton nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #18 from Nick Clifton nickc at redhat dot com 2013-01-28 15:09:52 UTC --- I have checked in a modified version of serowk's patch to the 4.7 branch. The modification was to produce an error message in the cases where the modes do not match, and to allow for the automatic forcing of constants into registers for those builtins that do not accept immediates as their third operand. Cheers Nick
[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 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 expert, so this patch may well be wrong. But it does allow libgcc to built (for all supported multilibs) for the sh64-linux target. There seem to be three problems: 1. As reported in this PR, the sdivsi3 function is being built for the L_div_table target when it clearly uses instructions that are not supported by the target SH variant. I have assumed that this is a mistake and so stopped the function from being built for the m5-compact multilib. 2. The udiv_qrnnd_16 function is not being built. It is built for non-Linux Sh targets, so I have assumed that it is an oversight and added it to the list of functions to build. 3. The m5-media64 and m5-media64-nofpu multilibs need the linker to support a shlefl64_linux emulation. The linker does not do this, so I have suppressed all multilibs based on these options.
[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 nickc at redhat dot com 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 #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
[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 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
[Bug target/53187] ICE in arm_select_dominance_cc_mode
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 com --- Comment #3 from Nick Clifton nickc at redhat dot com 2012-05-03 07:44:12 UTC --- Hi Jakub, I have tested the patch - it works and there are no regressions in the gcc testsuite. Thus I am happy to approve the ARM specific parts of the patch (for the mainline and the 4.7 branch). Cheers Nick
[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: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: ni...@redhat.com Created attachment 25966 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25966 Source for test case This is a follow up to a problem first reported here: http://gcc.gnu.org/ml/gcc/2011-11/msg00397.html
[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 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.
[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 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 in the compiler: % s390-gcc -c -g -O2 -m64 fred.i fred.i: In function 'bar': fred.i:37:1: internal compiler error: in expand_debug_locations, at cfgexpand.c:3687 The insn looks like this: (debug_insn 6 5 7 2 (var_location:SI temp$union_field$ptr_field (scratch)) fred.i:31 -1 (nil)) but the debug expression associated with it looks like this: (debug_expr:DI D#1) The problem, I believe, is in the assertion at line 3687, not the debug expression itself. The expression has been created by converting the gimple for the right hand side of the assignment on line 31 of fred.i: arg_1(D)-bytes into tree form. This conversion chooses DImode since that is the default pointer mode on this particular target. The fact that this expression is then cast to an SImode pointer is irrelevant - the expression itself is a DImode pointer expression. I have uploaded a proposed patch for this problem, based on an original patch created by DJ, but tweaked a little bit by me. It extends the assetion in expand_debug_locations() to allow for the fact that pointer expressions might use multiple modes. Cheers Nick
[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 nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton nickc at redhat dot com 2011-10-13 09:59:53 UTC --- Hi Kun, I am unable to reproduce this problem. :-( Can I check a couple of things: How was the toolchain that you are using configured ? I assumed that it was basically like this: --target=arm-linux-gnueabi --with-arch=armv7-a Secondly were you using the 4.5.1 point release or the latest 4.5 branch sources ? I was using the latter, so maybe this is a case of bug which has already been fixed ? 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 #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
[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 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
[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 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. Which is a but beyond my debugging capabilities, so I have uploaded a simple workaround to avoid the issue. Please note, this is definitely a workaround, not a patch, so use it at your discretion. In the meantime I will continue to investigate and see if I can get my head around the df-core.c code. 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 Nick Clifton nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton nickc at redhat dot com 2011-10-04 09:08:57 UTC --- Hi Paulo, Is this bug still reproducible for you ? I tried building an rx-elf toolchain from the current 4.6 branch sources and I could not reproduce the problem... Cheers Nick
[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: unassig...@gcc.gnu.org ReportedBy: ni...@redhat.com Created attachment 24862 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24862 Proposed patch and new testcase If an already defined static function is redefined as being both public and weak, the compiler generates an ICE: % cat test.c static long foo (void) { return 0; } long foo (void) __attribute__((weak)); % gcc test.c test.c:1:12: internal compiler error: in function_and_variable_visibility, at ipa.c:408 The uploaded patch is an attempt to fix this by adding a check into varasm.c:merge_weak(). I was not sure however whether the redeclaration is an error, or if it should be honoured and the function made non-static.
[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 nickc at redhat dot com 2011-06-14 15:32:13 UTC --- Fixed in mainline.
[Bug target/49402] Duplicate use of v850.opt
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.
[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 nickc at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Nick Clifton nickc at redhat dot com 2011-05-09 09:03:20 UTC --- The variable was left over from an attempt to simplify the code. It is not needed and so I have checked in the obvious patch to remove it.
[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 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.
[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 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 the definitions. They are bogus; the v850 does not currently support profiling, so it will be cleaner to just remove them. At patch that does this is pre-approved. Cheers Nick
[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=21338action=view) Force functions that return small unsigned values to use zero-extension -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000
[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 removed. Not really. The problem is that the compiler cannot guarantee the behaviour of the func function, since it is external to the compilation unit. It might not actually return an unsigned byte value. Is the explanation san integer conversion rank? I am not sure what you mean here. The simplest thing that I can say is that the code produced by gcc is what is required by the ISO C99 standard. If the RX ABI requires a different behaviour then it is not compatible with the ISO C99 standard. That said I have uploaded a patch which offers a compromise. It makes functions which return small unsigned values insert a zero-extend instruction into their epilogues. This is less efficient than the change that you were requesting (using MOVU.B to load the value from memory in the first place), but it does mean that the code produced by gcc will work both with other code produced by gcc and with code produced by Renesas's own compiler. May I also suggest that you contact Matt Newsome matt.news...@renesas.com at Renesas who is also concerned with this particular problem. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000
[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 expect). Thus since the MOV.B instruction performs a sign extension it is a sufficient instruction for the load operation. Note - if you try using the result of calling func() then you will see a zero extension being performed. Eg: int bar (int a) { return a func(); } results in: mov.L #_uA, r14 movu.B [r14], r14 cmp r1, r14 sclt.L r1 rts with inlining, or: push.l r7 mov.L r1, r7 bsr _func movu.B r1, r1 cmp r7, r1 sclt.L r1 rtsd#4, r7-r7 without. Cheers Nick Clifton PS. See section 6.3.1.1 of the ISO C99 standard for more information about this behaviour -- nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000
[Bug c/44438] New: ISO C99 6.7.4p3 not obeyed in C99 mode
Section 6.7.4 paragraph 3 of the ISO C99 standard states that: An inline definition of a function with external linkage ... shall not contain a reference to an identifier with internal linkage. GCC has code to check for this condition, but it does not work in C99 mode. Reproduce by: % cat iso-c99-test.c static int a = 7; extern inline int foo (void) { return a; } int main (void) { return foo (); } % gcc -c iso-c99-test.c iso-c99-test.c:2:39: warning: 'a' is static but used in inline function 'foo' which is not static [enabled by default] % gcc -c -std=c99 iso-c99-test.c % -- Summary: ISO C99 6.7.4p3 not obeyed in C99 mode Product: gcc Version: 4.6.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 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 #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/bugzilla/show_bug.cgi?id=39601
[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/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=17439action=view) Document the FR30 target 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 #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
[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 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 good news. The bad news is that I am not sure if the patch will be acceptable since I am not a C++ expert. The problem I believe is that the status of the cp_id_kind enum which is computed by cp_parser_postfix_dot_deref_expression() when it is parsing A::get is not passed back to cp_parse_primary_expression() which is currently parsing (p-A::get). So it goes with its default value, which allows overloading of virtual functions, and so the wrong member function is selected. The patch attempts to fix this problem by allowing the cp_id_kind enum computed in cp_parser_postfix_dot_deref_expression to be passes back, via a long chain of intermediary functions, to cp_parser_primary_expression. My concern is that I am not familiar enough with the C++ parser to tell if the patch breaks some other parser requirement. (One that is not tested by the g++ testsuite). So - is this patch acceptable ? Cheers Nick -- nickc at redhat dot com changed: What|Removed |Added Status|NEW |WAITING 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=16645action=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 #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 #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/show_bug.cgi?id=37862
[Bug c++/37862] New: Parenthesised indirection alters class member access
Hi Guys, Compiling and then executing this program: #include stdio.h class A { public: virtual void get() { printf (A\n); } }; class B:public A { public: virtual void get() { printf (B\n); } }; class C:public B { }; int main (void) { C c; C* p = c; p-A::get(); (p-A::get)(); return 0; } Results in: A B Being displayed, rather than: A A As far as I can tell the parentheses around the class member access should not change anything. Cheers Nick -- Summary: Parenthesised indirection alters class member access Product: 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: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862
[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=16475action=view) Enable -fno-common with -msse for Cygwin/Mingw -- nickc at redhat dot com changed: What|Removed |Added Attachment #16458|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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 is due to the fact that it's not so clear for me what no-common does -fno-common stops uninitialized variables declared in C and C++ programs from being treated in the same way as common variables declared in FORTRAN programs. and adding -fno-common what are side effects? Essentially there are two side effects: The first is that you will get a link time error if you declare the same uninitialized variable twice in two different source files, without using the 'extern' keyword on one of them. eg: % cat foo.c int a; % cat bar.c int a; int main (void) { return 0; } % gcc foo.c bar.c % gcc -fno-common foo.c bar.c multiple definition of `a' This is often a problem with badly written header files which declare variables without using 'extern'. eg: % cat header.h int a; % cat foo.c #include header.h int a; % cat bar.c #include header.h int main (void) { return 0; } % gcc -fno-common foo.c bar.c multiple definition of `a' The other side-effect, and the one that is more interesting for our purposes, is that it forces uninitialised variables to be placed into the .bss section. This is important because symbols in the PE/COFF file format do not have an alignment attribute of their own. Instead the alignment is inherited by the containing section, with the maximum alignment of any symbol inside a section being taken as the section's alignment as a whole. Symbols are placed inside the section on suitably aligned boundaries, so that providing that the section itself is placed on an alignment boundary everything will work. eg: % cat foo.c int normal_align; int aligned_16 __attribute__((aligned(16))); % gcc -fno-common -c foo.c % objdump --syms foo.o [ 8](sec 3)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x _normal_align [ 9](sec 3)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x0010 _aligned_16 Note how the 'aligned_16' variable starts at an offset of 0010 from the start of section 3, whereas 'normal_align' starts at an offset of . Ie there is a gap of 12 bytes from offset 0004 to 000f. % objdump -h foo.o Idx Name Size VMA LMA File off Algn 2 .bss 0020 2**4 Note that the .bss section has been given an alignment of 2^4. This is because it contains 'aligned_16'. If that variable had not been declared then the .bss section would have been given its default alignment of 2^2. Also note that section numbering differs between the two uses of objdump. Ie (sec 3) in the objdump --syms output refers to the third declared section which is the section with an index of 2 in the objdump -h output. % cat bar.c int a; % gcc -fno-common bar.c foo.o % nm a.exe 00402000 B _a 00402020 B _aligned_16 00402010 B _normal_align So after linking 'aligned_16' still has a 16-bit alignment because of the 2^4 alignment of the .bss section in the foo.o object file. The reason that all of this is important is that when common variables are stored in a PE/COFF object file they are not assigned to any section. Since only sections, not symbols, have an alignment attribute in PE/COFF object files, any alignment requirements of common symbols are lost. This is what has been causing the problems that you have experienced. eg: % cat foo.c int normal_align; int aligned_16 __attribute__((aligned(16))); % gcc -c foo.c % objdump --syms foo.o [ 8](sec 0)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x0004 _normal_align [ 9](sec 0)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x0004 _aligned_16 Note how the variables are assigned to (sec 0) which does not exist and that there is no field or flag specifying the alignment for either of them. You may ask why common variables are not assigned to the .bss section. The reason is that if there are multiple declarations of the same variable and all but one of which are common, then the non-common declaration takes precedence. eg: % cat foo.c int a; % cat bar.c int a = 1; % gcc foo.c bar.c % nm a.exe 00402000 D _a Ie the 'a' variable has been placed in the .data section and not the .bss section, despite the fact that it was declared uninitialised in foo.c. So common variables are not assigned to a section until the final link takes places. If there are no non-common definitions of a variable to specify where they should be placed then they are assigned to the .bss section, but by then it is too late - the alignment requirements of the symbol have been lost. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id
[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 the executable then work ? Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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_cos_16 00dd84e0 B _ff_cos_16 00de04c0 B _ff_cos_16384 except snow and svq1 tests, crashing because of bugs in tree opts on win32 sse code is working fine As I suspected. The PE/COFF file format does not provide for specifying the alignment of commons. Hmm, I wonder if gcc should complain if it finds aligned commons with COFF backends or if we should try to generate a GNU extension to the COFF format. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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 built with -fno-common that it worked, modulo some (completely separate) tree optimization bugs. Is that not right ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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 global symbols OK, so when you said: so how with -fno-common can make aligned work? did you really mean: so how without -fno-common can make aligned work? In which case the answer is - I do not know. The problem is that the PE/COFF file format does not support aligned commons. We could try to create an extension to the format to support them, but that would be non-standard. Another possibility would be to turn any common symbol with an alignment attribute into a weak symbol instead. This would work (I think, I have not tried it), provided that there are no other definitions of the same symbol with a different size. Which would possibly cause problems with FORTRAN programs but it is unlikely to be an issue with C/C++ programs. Another possibility is to modify the linker so that when it is placing common symbols into the .bss section of the output executable every symbol is aligned to the maximum alignment specified for any of the .bss sections of any input object file. This would probably waste huge amounts of space in the .bss section (for large programs anyway) but it ought to work. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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 This does not happen always but in some circumstances :( Possibly a linker bug. Could you investigate some more ? For example what alignment does the .bss section have in the object file and in the executable ? Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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 this, however... .comm _i, 0 size of i[0] I did drop the code to handle (size == 0) because I was not sure why it was there. I suspect we need to add this bit, or similar, back in - rounded = size ? size : 1; How about this third revision of the patch ? Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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=16458action=view) Revised patch which handles (size == 0) -- nickc at redhat dot com changed: What|Removed |Added Attachment #16425|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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 using sse code So, does this mean that the align patch is working, but that there is some other bug that is preventing some sse code from working ? If so then I can formally submit the align patch for approval. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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=16425action=view) Revised patch with correct section switching -- nickc at redhat dot com changed: What|Removed |Added Attachment #16303|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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 think that Brian may well be right however in that the patch is behaving badly when it manually switches into the .bss section. I have uploaded a revised version of the patch which uses the correct gcc function to perform the section switch, so please can anyone who is interested give this new patch a run. Cheers Nick -- nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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=16303action=view) Implement alignment for non-local commons -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[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 run it through a full rebuild and retest cycle... Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- 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