Hi Filip,
Thanks for your reply. But I'm not so familiar with VIM actually. Thus
when I try the options listed there, nothing happened. (VSCODE is the
IDE I'm using for development.)
And I notice that there is a `vimrc` in the `contrib` directory, I
tried it too, but sadly, it didn't work for me.
On Tue, 2024-04-30 at 21:15 +0200, Richard Biener via Gcc wrote:
>
>
> > Am 30.04.2024 um 21:11 schrieb Jason Merrill via Gcc
> > :
> >
> > On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc
> > wrote:
> > >
> > > In implementing prange (pointer ranges), I have found a 1.74%
> > > slowdow
On 4/30/24 12:22, Jakub Jelinek wrote:
On Tue, Apr 30, 2024 at 03:09:51PM -0400, Jason Merrill via Gcc wrote:
On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc wrote:
In implementing prange (pointer ranges), I have found a 1.74% slowdown
in VRP, even without any code path actually using
I bootstrapped and tested on powepc64 8 and 9 BE and 8, 9, and 10 LE and
it looks good.
On 4/30/24 5:33 AM, Jakub Jelinek via Gcc wrote:
The first release candidate for GCC 14.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/
ftp://gcc.gnu.org/pub/gcc/snapshots
On Tue, Apr 30, 2024 at 03:09:51PM -0400, Jason Merrill via Gcc wrote:
> On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc
> wrote:
> >
> > In implementing prange (pointer ranges), I have found a 1.74% slowdown
> > in VRP, even without any code path actually using the code. I have
> > track
> Am 30.04.2024 um 21:11 schrieb Jason Merrill via Gcc :
>
> On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc
> wrote:
>>
>> In implementing prange (pointer ranges), I have found a 1.74% slowdown
>> in VRP, even without any code path actually using the code. I have
>> tracked this do
On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc wrote:
>
> In implementing prange (pointer ranges), I have found a 1.74% slowdown
> in VRP, even without any code path actually using the code. I have
> tracked this down to irange::get_bitmask() being compiled differently
> with and without
Status
==
The gcc-13 branch is open for regression and documentation fixes.
It's time to do the annual release from the branch, GCC 13.3, and
the plan is to do a release candidate in two weeks, around May 14th,
following with the actual release around May 21st.
Please look through bugzilla a
On 30/04/2024 13:43, Jan Hubicka wrote:
The problem is testing. If gcc would re-number the basic blocks then
tests comparing hard-coded test paths would break, even though the path
coverage itself would be just fine (and presumably the change to the
basic block indices), which would add an unreas
On 30/04/2024 13:43, Jan Hubicka wrote:
The problem is testing. If gcc would re-number the basic blocks then
tests comparing hard-coded test paths would break, even though the path
coverage itself would be just fine (and presumably the change to the
basic block indices), which would add an unreas
> > The problem is testing. If gcc would re-number the basic blocks then
> > tests comparing hard-coded test paths would break, even though the path
> > coverage itself would be just fine (and presumably the change to the
> > basic block indices), which would add an unreasonable maintenance
> > bur
On 30/04/2024 12:45, Richard Biener wrote:
On Tue, Apr 30, 2024 at 11:45 AM Jørgen Kvalsvik wrote:
Hi,
I am working on adding path coverage support to gcc/gcov and need to
develop a good testing strategy.
So far I can reasonably well report on the uncovered path as such:
paths covered 6 of
Hi Mark,
On Sun, Apr 21, 2024 at 10:40:14PM +0200, Alejandro Colomar wrote:
[...]
> Let's generate a v2 patch set, showing the range-diff against v1. We
> need to check the commit IDs of the first set, which can be found in the
> mailing list archives, thanks to the trick we used. The v1 range
On Tue, Apr 30, 2024 at 11:45 AM Jørgen Kvalsvik wrote:
>
> Hi,
>
> I am working on adding path coverage support to gcc/gcov and need to
> develop a good testing strategy.
>
> So far I can reasonably well report on the uncovered path as such:
>
> paths covered 6 of 17
> path not covered: 2 8 3 4
>
The first release candidate for GCC 14.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/
ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/
and shortly its mirrors. It has been generated from git commit
r14-10154-g7a00c459cbb913a.
I have so far bootstrapped
On Tue 2024-04-30 13:52:16, Hanke Zhang via Gcc wrote:
> Hi
> I'm trying to format my code in GCC style.
>
> But I don't know how to finish it. I try `indent` and
> `check_GNU_style.sh` in the `contrib` directory. But none of them seem
> to work well.
>
> So I wondered is there any official tools
Hi,
I am working on adding path coverage support to gcc/gcov and need to
develop a good testing strategy.
So far I can reasonably well report on the uncovered path as such:
paths covered 6 of 17
path not covered: 2 8 3 4
path not covered: 2 8 3 5 6
path not covered: 2 8 3 5 7 10
...
where th
Hi,
On Fri, Apr 26 2024, Aldy Hernandez via Gcc wrote:
> Hi folks!
>
> In implementing prange (pointer ranges), I have found a 1.74% slowdown
> in VRP, even without any code path actually using the code. I have
> tracked this down to irange::get_bitmask() being compiled differently
> with and wit
On Tue, Apr 30, 2024 at 9:58 AM Richard Biener
wrote:
>
> On Fri, Apr 26, 2024 at 11:45 AM Aldy Hernandez via Gcc
> wrote:
> >
> > Hi folks!
> >
> > In implementing prange (pointer ranges), I have found a 1.74% slowdown
> > in VRP, even without any code path actually using the code. I have
> >
On Fri, Apr 26, 2024 at 11:45 AM Aldy Hernandez via Gcc wrote:
>
> Hi folks!
>
> In implementing prange (pointer ranges), I have found a 1.74% slowdown
> in VRP, even without any code path actually using the code. I have
> tracked this down to irange::get_bitmask() being compiled differently
> wi
> On 30 Apr 2024, at 08:33, Iain Sandoe wrote:
>
> Hi,
>
>> On 30 Apr 2024, at 00:39, Andrew Pinski via Gcc wrote:
>>
>> On Mon, Apr 29, 2024 at 4:26 PM Lucier, Bradley J via Gcc
>> wrote:
>>>
>>> The question: How to interpret scheduling info with the compiler listed
>>> below.
>>>
>>>
Hi,
> On 30 Apr 2024, at 00:39, Andrew Pinski via Gcc wrote:
>
> On Mon, Apr 29, 2024 at 4:26 PM Lucier, Bradley J via Gcc
> wrote:
>>
>> The question: How to interpret scheduling info with the compiler listed
>> below.
>>
>> Specifically, a tight loop that was reported to be scheduled in 23
23 matches
Mail list logo
