On Tue, Nov 18, 2014 at 1:44 PM, Jeff Law wrote:
> On 11/18/14 05:18, Richard Biener wrote:
>
>>>
>>> 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 f
On 11/18/14 05:18, Richard Biener wrote:
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 cour
On 11/18/14 02:55, Richard Biener wrote:
On Tue, Nov 18, 2014 at 3:59 AM, Jeff Law wrote:
On 11/17/14 13:05, Ilya Enkovich wrote:
How comes you emit debug info for functions that do not exist and thus
are never used? Is problem caused by builtins going after
END_CHKP_BUILTINS? Or some info
On Tue, Nov 18, 2014 at 9:07 AM, Richard Biener
wrote:
> Can we emit this particular STABS piece in "raw" form then? Thus
> does it work to have sth like
>
>.stabs ...
>.string "..."
>.stabs ...
>
> or whatever way to emit assembled data there?
The stabstring debug information is sa
On Tue, Nov 18, 2014 at 2:44 PM, David Edelsohn wrote:
> On Tue, Nov 18, 2014 at 8:33 AM, Ilya Enkovich wrote:
>> 2014-11-18 15:18 GMT+03:00 Richard Biener :
>>> On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich
>>> wrote:
2014-11-18 15:04 GMT+03:00 Richard Biener :
> On Tue, Nov 18, 2014
On Tue, Nov 18, 2014 at 8:33 AM, Ilya Enkovich wrote:
> 2014-11-18 15:18 GMT+03:00 Richard Biener :
>> On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich
>> wrote:
>>> 2014-11-18 15:04 GMT+03:00 Richard Biener :
On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich
wrote:
> 2014-11-18 5:56
2014-11-18 15:18 GMT+03:00 Richard Biener :
> On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich wrote:
>> 2014-11-18 15:04 GMT+03:00 Richard Biener :
>>> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich
>>> wrote:
2014-11-18 5:56 GMT+03:00 Jeff Law :
> On 11/17/14 13:43, Ilya Enkovich wrote
On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich wrote:
> 2014-11-18 15:04 GMT+03:00 Richard Biener :
>> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich
>> wrote:
>>> 2014-11-18 5:56 GMT+03:00 Jeff Law :
On 11/17/14 13:43, Ilya Enkovich wrote:
>
> I don't fully understand how thi
2014-11-18 15:04 GMT+03:00 Richard Biener :
> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich
> wrote:
>> 2014-11-18 5:56 GMT+03:00 Jeff Law :
>>> 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 af
On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich wrote:
> 2014-11-18 5:56 GMT+03:00 Jeff Law :
>> 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
2014-11-18 5:56 GMT+03:00 Jeff Law :
> 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
>>
On Tue, Nov 18, 2014 at 3:59 AM, Jeff Law wrote:
> On 11/17/14 13:05, Ilya Enkovich wrote:
>
>>
>> How comes you emit debug info for functions that do not exist and thus
>> are never used? Is problem caused by builtins going after
>> END_CHKP_BUILTINS? Or some info generated for all builtins igno
On 11/17/14 13:05, Ilya Enkovich wrote:
How comes you emit debug info for functions that do not exist and thus
are never used? Is problem caused by builtins going after
END_CHKP_BUILTINS? Or some info generated for all builtins ignoring
its existence?
IIRC, stabs aren't pruned based on whether
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
On 11/17/14 18:18, David Edelsohn wrote:
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.
I am not a stabstring expert, but the output that I am seeing in
almost every assembler file and the output that is overflo
On 11/17/14 19:06, David Edelsohn wrote:
The following patch seems to allow me to at least build stage1 GCC.
We'll see how far it get through bootstrap and testing. Hopefully it
is a work-around until we find a complete solution.
Thanks, David
Index: tree-core.h
===
The following patch seems to allow me to at least build stage1 GCC.
We'll see how far it get through bootstrap and testing. Hopefully it
is a work-around until we find a complete solution.
Thanks, David
Index: tree-core.h
===
--- tr
On Mon, Nov 17, 2014 at 3:43 PM, Ilya Enkovich wrote:
> 2014-11-17 21:41 GMT+03:00 Jeff Law :
>> On 11/17/14 11:22, David Edelsohn wrote:
>>>
>>> However, the patch causes another problem that breaks bootstrap on
>>> AIX. All of the builtins are emitted as an enum in debug information
>>> and the
On Mon, 17 Nov 2014, 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
It sounds to me like this is actually an AIX
2014-11-17 21:41 GMT+03:00 Jeff Law :
> On 11/17/14 11:22, David Edelsohn wrote:
>>
>> However, the patch causes another problem that breaks bootstrap on
>> AIX. All of the builtins are emitted as an enum in debug information
>> and the CHKP enums now cause an overflow in the debug data on AIX.
>>
On 11/17/14 11:55, David Edelsohn wrote:
Recent versions of AIX now have support for DWARF. I don't know if it
has arbitrary length limits like this as well. Adacore has an
implementation and I hope that they will contribute the patch
eventually.
Ah. Good. Though we probably shouldn't depend
2014-11-17 21:22 GMT+03:00 David Edelsohn :
> Ilya,
>
> Thanks for fixing the reference to BNDmode.
>
> However, the patch causes another problem that breaks bootstrap on
> AIX. All of the builtins are emitted as an enum in debug information
> and the CHKP enums now cause an overflow in the debug
On Nov 17, 2014, at 10:55 AM, David Edelsohn wrote:
>
>> It's unfortunately AIX continues to use stabs rather than an embedded dwarf
>> format. Sigh.
> The other complexity is IBM backported the feature to earlier versions
> of AIX, but there is no major or minor AIX version number that
> defin
On Mon, Nov 17, 2014 at 1:41 PM, Jeff Law wrote:
> On 11/17/14 11:22, David Edelsohn wrote:
>>
>> However, the patch causes another problem that breaks bootstrap on
>> AIX. All of the builtins are emitted as an enum in debug information
>> and the CHKP enums now cause an overflow in the debug dat
On 11/17/14 11:22, David Edelsohn wrote:
However, the patch causes another problem that breaks bootstrap on
AIX. All of the builtins are emitted as an enum in debug information
and the CHKP enums now cause an overflow in the debug data on AIX.
AIX continues to use stabstrings debugging and does
Ilya,
Thanks for fixing the reference to BNDmode.
However, the patch causes another problem that breaks bootstrap on
AIX. All of the builtins are emitted as an enum in debug information
and the CHKP enums now cause an overflow in the debug data on AIX.
AIX continues to use stabstrings debugging
On Mon, 2014-11-17 19:17:34 +0300, Ilya Enkovich wrote:
> On 17 Nov 16:12, Jan-Benedict Glaw wrote:
> > On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf
> > wrote:
> > > On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> > > > On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich
> > > >
On 17 Nov 16:12, Jan-Benedict Glaw wrote:
> On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf
> wrote:
> > On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> > > On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich
> > > wrote:
> [...]
> > > It seems this part of the patch series causes
On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf
wrote:
> On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> > On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich
> > wrote:
[...]
> > It seems this part of the patch series causes some build breakage
> > right now, see eg. build
> > htt
On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich
> wrote:
> > Hi,
> >
> > This patch adds support of instrumented builtin calls in expand.
> > Calls are mostly expanded as calls. But some of them reuse existing
> > string function calls e
On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich wrote:
> Hi,
>
> This patch adds support of instrumented builtin calls in expand.
> Calls are mostly expanded as calls. But some of them reuse existing
> string function calls expand functions (memcpy expand was slightly
> refactored for that).
>
On 11/06/14 05:24, Ilya Enkovich wrote:
Hi,
This patch adds support of instrumented builtin calls in expand. Calls are
mostly expanded as calls. But some of them reuse existing string function
calls expand functions (memcpy expand was slightly refactored for that).
This is the last enabling
Hi,
This patch adds support of instrumented builtin calls in expand. Calls are
mostly expanded as calls. But some of them reuse existing string function
calls expand functions (memcpy expand was slightly refactored for that).
This is the last enabling patch in this series. Remaining two patc
33 matches
Mail list logo