On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: > 2014-11-18 15:04 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich <enkovich....@gmail.com> >> wrote: >>> 2014-11-18 5:56 GMT+03:00 Jeff Law <l...@redhat.com>: >>>> On 11/17/14 13:43, Ilya Enkovich wrote: >>>> >>>>> >>>>> I don't fully understand how this problem appears. Is it fully AIX >>>>> specific and doesn't affect any other target? May we put all _CHKP >>>>> codes to the end of enum and ignore them by AIX? Limiting number of >>>>> codes in enum due to restrictions of specific debug info format seems >>>>> weird. If something cannot be encoded for debug info then it should >>>>> be ignored. I really hoped that creation of functions by demand would >>>>> allow to avoid such kind of problems :( >>>>> >>>>> I'll try to make a patch reducing amound of builtin codes to a >>>>> required minimum in case it appears to be the best option we have. >>>> >>>> It's a problem with the AIX native tools. Presumably they don't like >>>> really >>>> long lines -- it was a relatively common issue in the past with vendor >>>> tools. >>>> >>>> I think we should proceed on two fronts. First if David could investigate >>>> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to >>>> resolve the issue. Second if you could look at now duplicating every >>>> builtin in the enumeration since it's a combination of the number of enums >>>> and the length of the debug strings to represent them that's causing AIX >>>> heartburn. >>>> >>>> >>>> >>>> jeff >>> >>> I see. I can reduce the number of _CHKP builtin codes. Experimental >>> patch shows resulting END_BUILTINS = 1242. But we should expect >>> similar problem for i386 target builds hosted on AIX (here >>> http://toolchain.lug-owl.de/buildbot/ I see such build is tested). >>> Current IX86_BUILTIN_MAX is 2467 which is greater than current >>> END_BUILTINS. >> >> I think it's better to fix dbxout.c to do something sensible with >> too long lines for enum types. It should be easy to cook up a >> testcase that is not GCC. >> >> enum { entry1, entry2, entry3.... }; >> > > As I understand the main problem is that fixing dbxout in trunk won't > help to build stage1 compiler.
Simply build stage1 without debug info on AIX then. Btw, you have to start fixing the bug at some point ... (we can backport to 4.8 and 4.9). Of course dbxout.c is in kind of deep-freeze unmaintained state. I don't think we ever encouraged work-arounds for broken host compilers if that requires substantial work. >> not sure how exactly the issue breaks AIX bootstrap though. I suppose >> the assembler complains? > > It is linker how complaints. Here is a build log example: > http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=3073584 I see. Thanks, Richard. > Ilya > >> >> Richard. >> >>> Ilya
