Hi all,
This fixes inefficient bitfield code reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328
Bootstrapped and regtested on x86_64.
Ok for trunk?
-I
pr67328-2.patch
Description: Binary data
On Tue, Jan 24, 2017 at 11:59:36PM +0100, Jakub Jelinek wrote:
> Though, I wonder why configure.ac/Makefile.am have been based on one of the
> only 2 that aren't GPL licensed, there are over dozen other libraries that
> have very simple GPL configure.ac and Makefile.am, can't we just rewrite
> thos
The following patch fixes PR78363, debug confused by early debug emitted
from inconsistent IL which happens after OMP outlining wrecks parts of
the BLOCK tree (outlined TYPE_DECLs have wrong context).
Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
Thanks,
Richard.
2017-01-25
On 24 January 2017 at 18:15, Bernd Schmidt wrote:
> On 01/24/2017 06:03 PM, Christophe Lyon wrote:
>>
>> Ha... the regression occurred between r 244818 and r 244816,
>> and I read r 244816 ChangeLog too quickly and did not notice
>> it was modifying ifcvt.c in addition to x86-only files.
>>
>> So
On Wed, Jan 25, 2017 at 09:52:41AM +0100, Richard Biener wrote:
> 2017-01-25 Richard Biener
>
> PR debug/78363
> * omp-expand.c: Include debug.h.
> (expand_omp_taskreg): Make sure to generate early debug before
> outlining anything from a function.
> (expand_omp_ta
On 25/01/17 08:53, Christophe Lyon wrote:
On 24 January 2017 at 18:15, Bernd Schmidt wrote:
On 01/24/2017 06:03 PM, Christophe Lyon wrote:
Ha... the regression occurred between r 244818 and r 244816,
and I read r 244816 ChangeLog too quickly and did not notice
it was modifying ifcvt.c in add
Hi Naveen,
On 25/01/17 06:16, Hurugalawadi, Naveen wrote:
Hi,
Please find attached the patch that adds AES and CMP_BRANCH
fusion for Thunderx2t99.
Bootstrapped and Regression tested on aarch64-thunderx2t99.
Please review the patch and let us know if its okay?
Code looks ok (it's quite simple
On 25 January 2017 at 10:18, Kyrill Tkachov wrote:
>
> On 25/01/17 08:53, Christophe Lyon wrote:
>>
>> On 24 January 2017 at 18:15, Bernd Schmidt wrote:
>>>
>>> On 01/24/2017 06:03 PM, Christophe Lyon wrote:
Ha... the regression occurred between r 244818 and r 244816,
and I read r
Hi!
On Tue, 24 Jan 2017 13:52:10 +0100, Martin Jambor wrote:
> [BRIG front end]
"contrib/gcc_update" needs to be updated for "libhsail-rt".
Here is a patch to fix some Autotools issues in libhsail-rt (currently
testing); OK for trunk?
commit 00d64708323f74191ce5a39b223bca92295fc606
Author: Th
On 24/01/17 13:44, Richard Earnshaw (lists) wrote:
On 23/01/17 16:45, Gerald Pfeifer wrote:
Hi Kyrill,
On Mon, 23 Jan 2017, Kyrill Tkachov wrote:
This patch adds a short entry for the store merging pass in GCC 7 to the
"General Optimizer Improvements" section.
+ A new store merging pass has
On 23/01/17 23:39, Jeff Law wrote:
On 01/23/2017 10:28 AM, Kyrill Tkachov wrote:
Hi all,
I had forgotten to update the -fstore-merging documentation from a
previous iteration of the pass
and it says that it's enabled at -O and higher. The option is in fact
enabled at -O2 and higher, as well as
This fixes PR69264, reverting an earlier change that was trying to
bypass the broken/unclear vector_alignment_reachable hook. x86
doesn't define this hook and thus inherits the default implementation.
Now - the args we feed to the hook changed over time, esp. the
is_packed arg now (correctly) te
On 23/01/17 19:26, Christophe Lyon wrote:
Hi Nick,
On 23 January 2017 at 10:04, Richard Biener wrote:
On Fri, 20 Jan 2017, Nick Clifton wrote:
Hi Guys,
[I have been asked to look at this PR in the hopes that it can be
fixed soon and so no longer act as a blocker for the gcc 7 branch]
Hi Richard, Hi Ramana,
The patch below is a simple fix for PR0. I am not really
expecting you to agree with it, but I thought that it was worth
posting so that this PR could be looked at again and maybe a better
patch found. (Plus I am trying to close PRs so that the gcc 7 branch
w
On 25/01/17 09:29, Christophe Lyon wrote:
> On 25 January 2017 at 10:18, Kyrill Tkachov
> wrote:
>>
>> On 25/01/17 08:53, Christophe Lyon wrote:
>>>
>>> On 24 January 2017 at 18:15, Bernd Schmidt wrote:
On 01/24/2017 06:03 PM, Christophe Lyon wrote:
>
> Ha... the regression occ
On Tue, Jan 24, 2017 at 4:05 PM, Jeff Law wrote:
> On 01/24/2017 07:29 AM, Marc Glisse wrote:
>>
>> On Tue, 24 Jan 2017, Richard Biener wrote:
>>
That was my thought as well, but AFAICT we only call into match.pd
from VRP if we changed the insn.
>>>
>>>
>>> Yes - there was thoughts to ch
On 24/01/17 17:22, Bin Cheng wrote:
> Hi,
> Test gcc.dg/vect/vect-24.c starts passing after my vectorizer changes, but
> not on all targets. For x86_64, looks like other passes still mess up the IR
> and prevent it from being vectorized. This patch removes xfail for ARM
> targets.
> Test resul
On Wed, 25 Jan 2017, Yuri Gribov wrote:
> Hi all,
>
> This fixes inefficient bitfield code reported in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328
>
> Bootstrapped and regtested on x86_64.
>
> Ok for trunk?
This isn't a regression fix and thus not appropriate at this stage.
Some comm
Hi all,
We're hitting an ICE when expanding a DImode xor with an immediate on
TARGET_IWMMXT:
(insn 6 5 7 2 (set (reg:DI 111 [ t1.1_3 ])
(xor:DI (reg:DI 110 [ t1.0_2 ])
(const_int 85 [0x55]))) ./z32.c:13 -1
(nil))
The problem is that the general xordi3 expander accepts s
On 25/01/17 10:28, Nick Clifton wrote:
> Hi Richard, Hi Ramana,
>
> The patch below is a simple fix for PR0. I am not really
> expecting you to agree with it, but I thought that it was worth
> posting so that this PR could be looked at again and maybe a better
> patch found. (Plus I
On 25/01/17 10:58, Kyrill Tkachov wrote:
> Hi all,
>
> We're hitting an ICE when expanding a DImode xor with an immediate on
> TARGET_IWMMXT:
> (insn 6 5 7 2 (set (reg:DI 111 [ t1.1_3 ])
> (xor:DI (reg:DI 110 [ t1.0_2 ])
> (const_int 85 [0x55]))) ./z32.c:13 -1
> (nil))
>
On Wed, Jan 25, 2017 at 10:49 AM, Richard Biener wrote:
> On Wed, 25 Jan 2017, Yuri Gribov wrote:
>
>> Hi all,
>>
>> This fixes inefficient bitfield code reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328
>>
>> Bootstrapped and regtested on x86_64.
>>
>> Ok for trunk?
>
> This isn't
On Tue, Jan 24, 2017 at 11:59 PM, Jakub Jelinek wrote:
> Hi!
>
> Apparently the configury of this library has been copied over before the
> PR79046 changes were done, the following patch updates it. Ok for trunk?
Ok.
Richard.
> Though, I wonder why configure.ac/Makefile.am have been based on o
On 24/01/17 18:05, Adhemerval Zanella wrote:
On 03/01/2017 13:13, Wilco Dijkstra wrote:
+ /* If function uses stacked arguments save the old stack value so morestack
+ can return it. */
+ reg11 = gen_rtx_REG (Pmode, R11_REGNUM);
+ if (cfun->machine->frame.saved_regs_size
+ || cfun
On Wed, Jan 25, 2017 at 11:00:50AM +0100, Thomas Schwinge wrote:
> Hi!
>
> On Tue, 24 Jan 2017 13:52:10 +0100, Martin Jambor wrote:
> > [BRIG front end]
>
> "contrib/gcc_update" needs to be updated for "libhsail-rt".
>
>
> Here is a patch to fix some Autotools issues in libhsail-rt (currently
ARM libatomic inline asm uses sel, uadd8, uadd16 instructions
which are only available if __ARM_FEATURE_SIMD32 is defined.
libatomic/
2017-01-25 Szabolcs Nagy
PR target/78945
* config/arm/exch_n.c (libat_exchange): Check __ARM_FEATURE_SIMD32.
diff --git a/libatomic/config/arm/e
This changes the testcase back to its original form, it had been
adjusted for the new threading passes but those were tamed down
by a cost change later.
Tested on x86_64-unknwon-linux-gnu, applied.
Richard.
2017-01-25 Richard Biener
PR testsuite/72850
* gcc.dg/tree-ssa/pr692
On Tue, Jan 24, 2017 at 05:27:26PM +, David Sherwood wrote:
> I have a patch to fix the following openmp issue:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79212
>
> Writing openmp directives in a certain way in fortran programs can lead to
> the following assert:
>
> internal compiler
Hello.
Following patch documents DO loop changes which were done for upcoming GCC 7.1.
Thanks for feedback,
Martin
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.40
d
Hello.
Following patch documents changes in PGO and GCOV which were done for upcoming
GCC 7.1.
Thanks for feedback,
Martin
--- /tmp/wwwdocs/htdocs/gcc-7/changes.html 2017-01-25 11:10:56.0 +0100
+++ htdocs/gcc-7/changes.html 2017-01-25 14:48:56.257587082 +0100
@@ -630,6 +630,18 @@
GC
Hello.
Following patch documents new option -fsanitize-address-use-after-scope which
was done for upcoming GCC 7.1.
Thanks for feedback,
Martin
--- /tmp/wwwdocs/htdocs/gcc-7/changes.html 2017-01-25 11:10:56.0 +0100
+++ htdocs/gcc-7/changes.html 2017-01-25 15:44:54.441943930 +0100
@@ -47,
On 01/25/2017 10:18 AM, Kyrill Tkachov wrote:
The test is supposed to test the generation of the vsel instruction.
I believe adding an -mcpu=cortex-a57 to the testcases would be best, as
VSEL isn't actually available on Cortex-A5, it's just enabled by the
-mfpu=fp-armv8 option.
A more realistic c
On Tue, 2017-01-24 at 10:09 -0800, Carl E. Love wrote:
> On Tue, 2017-01-24 at 11:08 -0600, Segher Boessenkool wrote:
> > On Tue, Jan 24, 2017 at 08:28:37AM -0800, Carl E. Love wrote:
> > > The following patch fixes an issue with the entries in the table of
> > > built-in functions. All of the ent
Hi Martin,
On 25/01/17 14:54, Martin Liška wrote:
Hello.
Following patch documents new option -fsanitize-address-use-after-scope which
was done for upcoming GCC 7.1.
Thanks for feedback,
Martin
+ Using -O2 optimization level (and above) rewrites variables of a
GIMPLE
+ type that
On Wed, Jan 25, 2017 at 03:00:19PM +, Kyrill Tkachov wrote:
> Hi Martin,
>
> On 25/01/17 14:54, Martin Liška wrote:
> > Hello.
> >
> > Following patch documents new option -fsanitize-address-use-after-scope
> > which was done for upcoming GCC 7.1.
> >
> > Thanks for feedback,
> > Martin
>
We implemented DR 1137 which changed the return types of proj and conj
on scalars, but then before the final C++11 standard DR 1522 reverted
that change, and we never implemented it. That means since GCC 4.5.0
we've been shipping non-conforming proj and conj functions.
This fixes the return types
* doc/invoke.texi (C++ Dialect Options): Fix typo.
Committed as obvious.
commit 8d4ebdf7bfffefb077a28174aed5cb13e89cb90e
Author: Jonathan Wakely
Date: Wed Jan 25 14:30:12 2017 +
Fix "classe" typo in C++ Dialect Options docs
* doc/invoke.texi (C++ Dialect Options)
On 25/01/17 15:07 +, Jonathan Wakely wrote:
* doc/invoke.texi (C++ Dialect Options): Fix typo.
Committed as obvious.
Oops, this was only meant for gcc-patches, not the libstdc++ list,
sorry.
On 25 January 2017 at 15:55, Bernd Schmidt wrote:
> On 01/25/2017 10:18 AM, Kyrill Tkachov wrote:
>>
>> The test is supposed to test the generation of the vsel instruction.
>> I believe adding an -mcpu=cortex-a57 to the testcases would be best, as
>> VSEL isn't actually available on Cortex-A5, it'
On 25/01/17 15:20, Christophe Lyon wrote:
On 25 January 2017 at 15:55, Bernd Schmidt wrote:
On 01/25/2017 10:18 AM, Kyrill Tkachov wrote:
The test is supposed to test the generation of the vsel instruction.
I believe adding an -mcpu=cortex-a57 to the testcases would be best, as
VSEL isn't act
Hello.
Following patch adds what was said in the changes file to our documentation.
Thanks,
Martin
>From 0da7f4d9a2a895e63271e9dc870814c6c7e3f419 Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 25 Jan 2017 16:41:23 +0100
Subject: [PATCH] Enhance doc for -fprofile-arcs
gcc/ChangeLog:
2017-01-2
Hi!
I was worried this patch would prevent too many other optimisations,
so I looked into better options. I didn't find any. I tested the
effects of the patch on 31 architectures (building GCC and then Linux
with it; 6 errored out building the kernel). There were exactly zero
differences in gen
Hi!
On Wed, 25 Jan 2017 13:21:13 +0100, Jakub Jelinek wrote:
> On Wed, Jan 25, 2017 at 11:00:50AM +0100, Thomas Schwinge wrote:
> > On Tue, 24 Jan 2017 13:52:10 +0100, Martin Jambor wrote:
> > > [BRIG front end]
$ git grep --cached libbrig
gcc/brig/config-lang.in:target_libs="target-lib
On Wed, Jan 25, 2017 at 3:56 PM, Segher Boessenkool
wrote:
> Hi!
>
> I was worried this patch would prevent too many other optimisations,
> so I looked into better options. I didn't find any. I tested the
> effects of the patch on 31 architectures (building GCC and then Linux
Thanks very much fo
On Wed, Jan 25, 2017 at 04:08:54PM +, Bin.Cheng wrote:
> > I was worried this patch would prevent too many other optimisations,
> > so I looked into better options. I didn't find any. I tested the
> > effects of the patch on 31 architectures (building GCC and then Linux
> Thanks very much for
Hi,
As analyzed in PR71437, it's a missed PRE issue due to missed jump threading,
and then due to inaccurate VRP information. In function
extract_range_for_var_from_comparison_expr,
we compute range for variable "a" under condition that comparison like "a <=
limit"
is true. It extracts limit's
Hi,
Test gcc.target/aarch64/ldp_vec_64_1.c because we don't choose [base+offset]
addressing mode in IVOPT
on AArch64. Given auto-increment addressing mode is disabled in IVOPT on
AArch64, we can't really test
the addressing mode. I may try to enable it only for small loops in GCC8, so
this pa
The improvements to the handling of flexible array members in
C++ in GCC 6 inadvertently removed the pedantic warnings GCC
used to issue for their declarations. The attached patch
restores it.
Martin
PR c++/71290 - [6/7 Regression] Flexible array member is not diagnosed with -pedantic
gcc/cp/Ch
On 01/25/2017 03:34 AM, Richard Biener wrote:
On Tue, Jan 24, 2017 at 4:05 PM, Jeff Law wrote:
On 01/24/2017 07:29 AM, Marc Glisse wrote:
On Tue, 24 Jan 2017, Richard Biener wrote:
That was my thought as well, but AFAICT we only call into match.pd
from VRP if we changed the insn.
Yes - t
OK.
On Wed, Jan 25, 2017 at 12:02 PM, Martin Sebor wrote:
> The improvements to the handling of flexible array members in
> C++ in GCC 6 inadvertently removed the pedantic warnings GCC
> used to issue for their declarations. The attached patch
> restores it.
>
> Martin
On 25/01/17 16:49, Bin Cheng wrote:
> Hi,
> Test gcc.target/aarch64/ldp_vec_64_1.c because we don't choose [base+offset]
> addressing mode in IVOPT
> on AArch64. Given auto-increment addressing mode is disabled in IVOPT on
> AArch64, we can't really test
> the addressing mode. I may try to ena
Hi,
this patch modifies profitable_jump_thread_path heuristics by enabling
code expansion when the threaded path contains at least one hot path.
The basic idea is that while we do not decrease instruction count on the
non-duplicated path, we reduce number of entry edges and by this path
separation
Hi,
Here's a different approach that doesn't introduce indirection for privatized
variables at all, and keeps dependencies obvious in the IR, but, on the flip
side, requires mentioning all subfields of privatized structures in a few
places.
For each privatized variable, add it to the list of outp
Bill:
> >
> > I don't see any tests for the two built-in entries in rs6000-c.c which the
> > patch moves, i.e.
> >
> > { P8V_BUILTIN_VEC_VGBBD, P8V_BUILTIN_VGBBD,
> >
> > RS6000_BT
On Fri, Jan 20, 2017 at 01:24:15PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 20, 2017 at 01:33:59PM +0100, Bernd Schmidt wrote:
> > So, when looking for situations where we have only one condition, we can
> > try to undo the conversion of a plain REG into a condition, on the
> > grounds that
Hi!
As mentioned in the PR, lambda templates are something that in the end
didn't end up in C++14 nor C++17 (only generic lambdas with auto arguments
made it). This patch pedwarns on them if -pedantic{,-errors}.
Bootstrapped/regtested on x86_64-linux and i686-linux, acked by Jason in the
PR, com
Hi!
This patch adds a little optimization, if %st and %st(1) are results of
memory loads and we need to exchange them, it is shorter (and on older
machines probably also cheaper) to swap the two loads.
This triggers 26783 in x86_64-linux and i686-linux bootstraps+regtests.
Bootstrapped/regtested
Hi!
As discussed in the PR, while lambda closure types are class types, it
is implementation dependent on what those class types actually contain,
allowing that to be decomposed is just weird.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-01-25 Jakub Jelinek
While putting together examples for the GCC 7 changes document
I noticed that a few of the buffer overflow warnings issued by
-Wstringop-overflow are defeated by Glibc's macros for string
manipulation functions like strncat and strncpy.
While testing my fix I also noticed that I had missed a coup
On 01/25/2017 02:06 PM, Jakub Jelinek wrote:
Hi!
This patch adds a little optimization, if %st and %st(1) are results of
memory loads and we need to exchange them, it is shorter (and on older
machines probably also cheaper) to swap the two loads.
This triggers 26783 in x86_64-linux and i686-lin
GCC Maintainers:
After further discussion of the two P8V_BUILTIN_VGBBD built-ins that do
not take any arguments, it was determined they should just be removed as
they are not valid.
The patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE)
with no regressions.
Is the patch OK for t
On Wed, Jan 25, 2017 at 02:43:34PM -0700, Jeff Law wrote:
> > 2017-01-25 Jakub Jelinek
> >
> > PR target/70465
> > * reg-stack.c (emit_swap_insn): Instead of fld a; fld b; fxchg %st(1);
> > emit fld b; fld a; if possible.
> >
> > * gcc.target/i386/pr70465.c: New test.
> So plea
I merged trunk revision 244906 to the gccgo branch.
Ian
On Wed, Jan 11, 2017 at 10:53 AM, Nathan Sidwell wrote:
> On 01/04/2017 12:53 AM, Jason Merrill wrote:
>
>> Hmm, that seems like where the problem is. We shouldn't try to
>> instantiate the inheriting constructor until we've already chosen the
>> base constructor; in the new model the inheriting
OK.
On Wed, Jan 25, 2017 at 4:07 PM, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, while lambda closure types are class types, it
> is implementation dependent on what those class types actually contain,
> allowing that to be decomposed is just weird.
>
> Bootstrapped/regtested on x86_64
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160 records that
gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc64 big-endian. The
test was developed just prior to the introduction of D-form memory
access instructions lxv and stxv, so it relied on output of X-form
instructions lxvx and stx
On 01/22/2017 04:53 PM, Martin Sebor wrote:
The attached patch adds the concept of likely and unlikely results
of formatted functions to improve the quality of diagnostics (reduce
false positives and negatives) while at the same time allowing for
rare cases such as a multibyte decimal point in fl
On Wed, Jan 25, 2017 at 10:02:23AM -0700, Martin Sebor wrote:
> --- gcc/cp/decl.c (revision 244844)
> +++ gcc/cp/decl.c (working copy)
> @@ -11798,6 +11798,17 @@ grokdeclarator (const cp_declarator *declarator,
> }
> else
> {
> + /* Array is a
On 01/25/2017 04:53 PM, Jakub Jelinek wrote:
On Wed, Jan 25, 2017 at 10:02:23AM -0700, Martin Sebor wrote:
--- gcc/cp/decl.c (revision 244844)
+++ gcc/cp/decl.c (working copy)
@@ -11798,6 +11798,17 @@ grokdeclarator (const cp_declarator *declarator,
}
else
On Tue, Jan 24, 2017 at 06:33:51PM +, Jonathan Wakely wrote:
> --- a/libstdc++-v3/libsupc++/new_opa.cc
> +++ b/libstdc++-v3/libsupc++/new_opa.cc
> @@ -55,9 +55,30 @@ extern "C" void *memalign(std::size_t boundary,
> std::size_t size);
> #endif
> #define aligned_alloc memalign
> #else
> -//
As has been discussed extensively, we're not doing a good job at
simplifying overflow tests, particularly those which collapse down to an
EQ/NE test.
x + -1 > x -> x == 0
x + -1 < x -> x != 0
x + 1 < x -> x == -1U
x + 1 > x -> x != -1U
The simplifications allow us to propagate a constant
This patch fixes the wrong constraint (o instead of wY) for a STXSD instruction
on a vector extract operation that is optimizd to do a store if the element
being extracted is in the right position.
I have built a compiler with/with out the patch on a little endian power8
system. The runs finished
On Wed, Jan 25, 2017 at 01:52:34PM -0800, Carl E. Love wrote:
> After further discussion of the two P8V_BUILTIN_VGBBD built-ins that do
> not take any arguments, it was determined they should just be removed as
> they are not valid.
>
> The patch has been tested on powerpc64le-unknown-linux-gnu (P
On Wed, Jan 25, 2017 at 04:41:06PM -0600, Bill Schmidt wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160 records that
> gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc64 big-endian. The
> test was developed just prior to the introduction of D-form memory
> access instructions lxv and
On 01/25/2017 03:01 PM, Jakub Jelinek wrote:
On Wed, Jan 25, 2017 at 02:43:34PM -0700, Jeff Law wrote:
2017-01-25 Jakub Jelinek
PR target/70465
* reg-stack.c (emit_swap_insn): Instead of fld a; fld b; fxchg %st(1);
emit fld b; fld a; if possible.
* gcc.target
On Wed, Jan 25, 2017 at 08:03:04PM -0500, Michael Meissner wrote:
> This patch fixes the wrong constraint (o instead of wY) for a STXSD
> instruction
> on a vector extract operation that is optimizd to do a store if the element
> being extracted is in the right position.
>
> I have built a compil
On Wed, 25 Jan 2017, Jeff Law wrote:
As has been discussed extensively, we're not doing a good job at simplifying
overflow tests, particularly those which collapse down to an EQ/NE test.
x + -1 > x -> x == 0
x + -1 < x -> x != 0
x + 1 < x -> x == -1U
x + 1 > x -> x != -1U
The simplifica
On Wed, Jan 25, 2017 at 6:07 PM, Thomas Schwinge
wrote:
> Hi!
>
> On Wed, 25 Jan 2017 13:21:13 +0100, Jakub Jelinek wrote:
>> On Wed, Jan 25, 2017 at 11:00:50AM +0100, Thomas Schwinge wrote:
>> > On Tue, 24 Jan 2017 13:52:10 +0100, Martin Jambor wrote:
>> > > [BRIG front end]
>
> $ git grep
78 matches
Mail list logo
