On Tue, 16 Apr 2019 at 17:36, Jakub Jelinek wrote:
>
> On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote:
> > I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though,
> > the *.log files are complete there.
> >
> > And I have no idea if it was introduced with your chan
Google is offering to pair and sponsor documentation writers for
topics in Open Source projects. A number of new developers have
requested better documentation of GIMPLE and I would like to submit a
proposal, but we need mentors for the documentation writer.
Google Season of Docs is scheduled for
Am 16.04.2019 um 17:36 schrieb Jakub Jelinek:
> On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote:
>> I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though,
>> the *.log files are complete there.
>>
>> And I have no idea if it was introduced with your change or earlie
Hi,
On Tue, Apr 16 2019, Jakub Jelinek wrote:
> On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote:
>> > I executed the dg-extract-results.sh manually in the gcc/testsuite
>> > directory after a complete testsuite run which didn't give the correct
>> > results. Rev. 240429 gives the e
On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote:
> I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though,
> the *.log files are complete there.
>
> And I have no idea if it was introduced with your change or earlier.
Actually, I managed to reproduce in a Fedora 31
On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote:
> > I executed the dg-extract-results.sh manually in the gcc/testsuite
> > directory after a complete testsuite run which didn't give the correct
> > results. Rev. 240429 gives the expected results, where rev 268511 fails.
> > I'm on
Am 16.04.2019 um 14:49 schrieb Christophe Lyon:
> On Tue, 16 Apr 2019 at 14:34, Rainer Emrich
> wrote:
>>
>> Am 16.04.2019 um 14:10 schrieb Christophe Lyon:
>>> On Tue, 16 Apr 2019 at 13:04, Rainer Emrich
>>> wrote:
Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
> Am 15.04.2019 um
On Tue, 16 Apr 2019 at 14:34, Rainer Emrich wrote:
>
> Am 16.04.2019 um 14:10 schrieb Christophe Lyon:
> > On Tue, 16 Apr 2019 at 13:04, Rainer Emrich
> > wrote:
> >>
> >> Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
> >>> Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
> Am 15.04.2019 um 17
Am 16.04.2019 um 14:10 schrieb Christophe Lyon:
> On Tue, 16 Apr 2019 at 13:04, Rainer Emrich
> wrote:
>>
>> Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
>>> Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
> Am 15.04.2019 um 17:38 schrieb Jaku
On Tue, 16 Apr 2019 at 13:04, Rainer Emrich wrote:
>
> Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
> > Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
> >> Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
> >>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek:
> On Mon, Apr 15, 2019 at 05:30:14PM +0
On Tue, Apr 16, 2019 at 1:39 PM Jakub Jelinek wrote:
>
> On Tue, Apr 16, 2019 at 01:25:38PM +0200, Richard Biener wrote:
> > So for the parser it's small differences that accumulate, for example
> > a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new
> > conversion_null_warn
Last few days I’ve added my comments/patches into almost all
modulo-scheduler PRs appeared in the last two years. Here I want to
discuss five PRs. First of all, I have four patches which fix
regressions, so technically I can ask about applying them right now on
stage4. But we don’t have a ma
On Tue, Apr 16, 2019 at 01:25:38PM +0200, Richard Biener wrote:
> So for the parser it's small differences that accumulate, for example
> a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new
> conversion_null_warnings which is called even without any warning option.
>
> Possi
On Tue, Apr 16, 2019 at 11:56 AM Richard Biener
wrote:
>
> On Tue, Apr 16, 2019 at 10:53 AM Michael Matz wrote:
> >
> > Hello Martin,
> >
> > On Tue, 16 Apr 2019, Martin Liška wrote:
> >
> > > Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm
> > > going to start using kdeco
On Tue, 16 Apr 2019 at 04:06, Justin Bassett wrote:
>
> The following code will emit a warning with -Wattributes:
>
> [[some_ns::some_attribute]]
> void call_me();
>
> :2:14: warning: 'some_ns::some_attribute' scoped attribute
> directive ignored [-Wattributes]
> 2 | void call_me();
> |
Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
> Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
>> Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
>>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek:
On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote:
> There seems to be a generic issu
Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
> Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek:
>>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote:
There seems to be a generic issue with the tests in gcc/testsuite. The
log file
On Tue, Apr 16, 2019 at 10:53 AM Michael Matz wrote:
>
> Hello Martin,
>
> On Tue, 16 Apr 2019, Martin Liška wrote:
>
> > Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm
> > going to start using kdecore.ii as well.
>
> If the kdecore.cc is the one from me it's also preproce
Hello Martin,
On Tue, 16 Apr 2019, Martin Liška wrote:
> Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm
> going to start using kdecore.ii as well.
If the kdecore.cc is the one from me it's also preprocessed and doesn't
contain any #include directives, I just edited it
On 4/16/19 9:48 AM, Martin Liška wrote:
> On 4/15/19 5:07 PM, Michael Matz wrote:
>> Hi,
>>
>> On Mon, 15 Apr 2019, Jakub Jelinek wrote:
>>
It seems the C++ parser got quite a bit slower with gcc 9 :-( Most
visible in the compile time for tramp-3d (24%) and kdecore.cc (18%
slower w
On 4/15/19 5:07 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 15 Apr 2019, Jakub Jelinek wrote:
>
>>> It seems the C++ parser got quite a bit slower with gcc 9 :-( Most
>>> visible in the compile time for tramp-3d (24%) and kdecore.cc (18%
>>> slower with just PGO); it seems that the other .ii file
21 matches
Mail list logo
