On Fri, Sep 26, 2014 at 1:04 AM, Maxim Ostapenko
wrote:
> Thank you all for your help!
>
> Done in r215633.
>
> -Maxim
>
> On 09/25/2014 11:05 PM, Jeff Law wrote:
>>
>> On 09/23/14 01:14, Maxim Ostapenko wrote:
>>>
>>>
>>>
>>> 2014-09-04 Jakub Jelinek
>>> Max Ostapenko
>>>
>>> * commo
On 09/26/14 10:31, Thomas Schwinge wrote:
Hi!
On Fri, 26 Sep 2014 10:18:32 -0600, Jeff Law wrote:
On 09/26/14 07:23, Thomas Schwinge wrote:
On Fri, 26 Sep 2014 12:04:45 +0400, Maxim Ostapenko
wrote:
Done in r215633.
This is causing compiler warnings, respectively bootstrap errors: [...]
Hi!
On Fri, 26 Sep 2014 10:18:32 -0600, Jeff Law wrote:
> On 09/26/14 07:23, Thomas Schwinge wrote:
> > On Fri, 26 Sep 2014 12:04:45 +0400, Maxim Ostapenko
> > wrote:
> >> Done in r215633.
> > This is causing compiler warnings, respectively bootstrap errors: [...]
> > OK to fix as follows? O
On 09/26/14 07:23, Thomas Schwinge wrote:
Hi!
On Fri, 26 Sep 2014 12:04:45 +0400, Maxim Ostapenko
wrote:
Thank you all for your help!
Done in r215633.
-Maxim
On 09/25/2014 11:05 PM, Jeff Law wrote:
On 09/23/14 01:14, Maxim Ostapenko wrote:
2014-09-04 Jakub Jelinek
Max Ostapenk
Ugh, sorry. Thanks for fixing this.
On 09/26/2014 05:23 PM, Thomas Schwinge wrote:
Hi!
On Fri, 26 Sep 2014 12:04:45 +0400, Maxim Ostapenko
wrote:
Thank you all for your help!
Done in r215633.
-Maxim
On 09/25/2014 11:05 PM, Jeff Law wrote:
On 09/23/14 01:14, Maxim Ostapenko wrote:
2014-0
Hi!
On Fri, 26 Sep 2014 12:04:45 +0400, Maxim Ostapenko
wrote:
> Thank you all for your help!
>
> Done in r215633.
>
> -Maxim
> On 09/25/2014 11:05 PM, Jeff Law wrote:
> > On 09/23/14 01:14, Maxim Ostapenko wrote:
> >>
> >>
> >> 2014-09-04 Jakub Jelinek
> >> Max Ostapenko
> >>
> >>
Hi Maxim,
> Thank you all for your help!
>
> Done in r215633.
unfortuntely, the applied patch cannot have been tested properly and
breaks native i386-pc-solaris2.11 (and every other) bootstrap:
/vol/gcc/src/hg/trunk/local/gcc/gcc.c: In function 'attempt_status
run_attempt(const char**, const ch
Thank you all for your help!
Done in r215633.
-Maxim
On 09/25/2014 11:05 PM, Jeff Law wrote:
On 09/23/14 01:14, Maxim Ostapenko wrote:
2014-09-04 Jakub Jelinek
Max Ostapenko
* common.opt: New option.
* doc/invoke.texi: Describe new option.
* gcc.c (execute): Don't free
On 09/23/14 01:14, Maxim Ostapenko wrote:
2014-09-04 Jakub Jelinek
Max Ostapenko
* common.opt: New option.
* doc/invoke.texi: Describe new option.
* gcc.c (execute): Don't free first string early, but at the end
of the function. Call retry_ice if c
On 09/19/2014 02:16 AM, Joseph S. Myers wrote:
On Thu, 11 Sep 2014, Maxim Ostapenko wrote:
In general, when cc1 or cc1plus ICE-es, we try to reproduce the bug by running
compiler 3 times and comparing stderr and stdout on each attempt with
respective ones that were gotten as the result of prev
On 09/19/2014 02:16 AM, Joseph S. Myers wrote:
On Thu, 11 Sep 2014, Maxim Ostapenko wrote:
In general, when cc1 or cc1plus ICE-es, we try to reproduce the bug by running
compiler 3 times and comparing stderr and stdout on each attempt with
respective ones that were gotten as the result of previ
On Thu, 11 Sep 2014, Maxim Ostapenko wrote:
> In general, when cc1 or cc1plus ICE-es, we try to reproduce the bug by running
> compiler 3 times and comparing stderr and stdout on each attempt with
> respective ones that were gotten as the result of previous compiler run (we
> use temporary dump fi
Ping.
On 09/11/2014 08:20 PM, Maxim Ostapenko wrote:
Hi, Joseph,
Thanks for your review! I've added comments for new functions and
replaced POSIX subprocess interfaces with libiberty's ones.
In general, when cc1 or cc1plus ICE-es, we try to reproduce the bug by
running compiler 3 times and c
Hi, Joseph,
Thanks for your review! I've added comments for new functions and
replaced POSIX subprocess interfaces with libiberty's ones.
In general, when cc1 or cc1plus ICE-es, we try to reproduce the bug by
running compiler 3 times and comparing stderr and stdout on each attempt
with respe
14 matches
Mail list logo
