On Fri, 7 Oct 2016, Frank Ch. Eigler wrote:
> joseph wrote:
>
> > Thanks, here are further authors map additions for new committers.
> > [...]
> > avieira = Andre Vieira
> > [...]
>
> FWIW, I thought at one point the consensus was that the mailmap would
> expand only to $use...@gcc.gnu.org rath
joseph wrote:
> Thanks, here are further authors map additions for new committers.
> [...]
> avieira = Andre Vieira
> [...]
FWIW, I thought at one point the consensus was that the mailmap would
expand only to $use...@gcc.gnu.org rather than $userid@$organization,
esp. considering the case where
On Fri, 7 Oct 2016, Jason Merrill wrote:
> But if you want to do it with reposurgeon, I won't complain. I've
> pushed my WIP to https://github.com/jicama/gcc-reposurgeon
Thanks, here are further authors map additions for new committers.
avieira = Andre Vieira
foreese = Fritz Reese
jemarch = J
On Fri, 7 Oct 2016, Jason Merrill wrote:
> no additional commits, and keeps other branches that were deleted in
> SVN, though I was able to work around this with a postprocessing
> script.
I suppose there's the question of what we want cases where branches might
have been deleted to look like, b
oops this works better:
alias reversed_make='make 2>&1 >/dev/null | tac | egrep --color
"\b(error|cpp|hpp)\b|$"'
On Fri, Oct 7, 2016 at 4:39 PM, nicolas bouillot
wrote:
> Thank you Joe and Dave.
>
> I tried -fmax-errors but my test error (c++ iterator type) is itself
> very long and still require
Thank you Joe and Dave.
I tried -fmax-errors but my test error (c++ iterator type) is itself
very long and still requires scrolling. In this case I had success
with tac. It just need to get some color back after filtering, which
is resulting for me in this following alias:
alias reversed_make='mak
Jason Merrill :
> > I've used both git-svn (sometimes with git filter-branch) and reposurgeon
> > for repository conversions. My experience is that if there's anything at
> > all complicated or messy about the history, using git-svn for the
> > conversion is not a good idea, so I don't think that'
On October 7, 2016 8:03:34 PM GMT+02:00, Martin Sebor wrote:
>On 10/07/2016 11:15 AM, Richard Biener wrote:
>> On October 7, 2016 6:49:39 PM GMT+02:00, Martin Sebor
> wrote:
>>> While processing the (p += i) expression below to validate the
>bounds
>>> of the pointer in I call get_range_info for i
On Thu, Oct 6, 2016 at 4:31 PM, Joseph Myers wrote:
> On Thu, 6 Oct 2016, Jason Merrill wrote:
>
>> After I ran into a couple of reposurgeon bugs and didn't hear back
>> from you, I started investigating rewriting the existing git svn
>> mirror with git filter-branch instead. That seems an attrac
On Fri, 2016-10-07 at 15:08 -0400, nicolas bouillot wrote:
> Hi,
>
> Was wondering this could be a feature request ? Basically, this could
> be a GCC option to print compilation errors in a reversed order, i.e.
> the first being printed last. This is because when compiling from the
> terminal, it
You can already do this today. Run the output of the compiler through 'tac'.
No need for a new feature.
https://linux.die.net/man/1/tac
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of nicolas
bouillot
Sent: Friday, October 07, 2016 12:09 PM
Hi,
Was wondering this could be a feature request ? Basically, this could
be a GCC option to print compilation errors in a reversed order, i.e.
the first being printed last. This is because when compiling from the
terminal, it would avoid mouse scrolling all day in order to get the
first error.
I
On 10/07/2016 11:15 AM, Richard Biener wrote:
On October 7, 2016 6:49:39 PM GMT+02:00, Martin Sebor wrote:
While processing the (p += i) expression below to validate the bounds
of the pointer in I call get_range_info for i (in tree-object-size.c).
The function returns the following VR_RANGE: [2
On October 7, 2016 6:49:39 PM GMT+02:00, Martin Sebor wrote:
>While processing the (p += i) expression below to validate the bounds
>of the pointer in I call get_range_info for i (in tree-object-size.c).
>The function returns the following VR_RANGE: [2147483648, -2147483649]
>rather than the expec
While processing the (p += i) expression below to validate the bounds
of the pointer in I call get_range_info for i (in tree-object-size.c).
The function returns the following VR_RANGE: [2147483648, -2147483649]
rather than the expected [0, 1]. Is such a range to be expected or
is it a bug?
In g
W dniu 2016-10-07 o 11:15, Richard Biener pisze:
> On Fri, Oct 7, 2016 at 10:17 AM, Marcin Noga wrote:
>> Hello.
>> I just starting their adventure with the GNU GCC.
>> Successfully compiled binutils and gcc 6.2.0 for FR30-elf target.
>> In an environment Msys2 under Windows 10.
>> Configuration
W dniu 2016-10-07 o 11:15, Richard Biener pisze:
> On Fri, Oct 7, 2016 at 10:17 AM, Marcin Noga wrote:
>> Hello.
>> I just starting their adventure with the GNU GCC.
>> Successfully compiled binutils and gcc 6.2.0 for FR30-elf target.
>> In an environment Msys2 under Windows 10.
>> Configuration
On Fri, Oct 7, 2016 at 10:17 AM, Marcin Noga wrote:
> Hello.
> I just starting their adventure with the GNU GCC.
> Successfully compiled binutils and gcc 6.2.0 for FR30-elf target.
> In an environment Msys2 under Windows 10.
> Configuration binutils:
>
> ../../src/binutils-2.27/configure --target=
Hello.
I just starting their adventure with the GNU GCC.
Successfully compiled binutils and gcc 6.2.0 for FR30-elf target.
In an environment Msys2 under Windows 10.
Configuration binutils:
../../src/binutils-2.27/configure --target=FR30-elf
prefix=/c/mingw/FR30-elf --disable-nls
Configuring gcc 6
19 matches
Mail list logo
