Hi,
Following "popular request", we are happy to announce that users can
now request to skip Linaro CI precommit testing for some patches.
The current implementation skips testing in two cases:
1- there is [RFC] or [RFC v[0-9]] in the patch subject
2- the commit message contains a line starting w
Hi Ramana,
On 9/26/24 19:22, Ramana Radhakrishnan wrote:
I am pleased to announce that the GCC Steering Committee has appointed
Christophe Lyon as a MVE Reviewer for the AArch32 port.
Please join me in congratulating Christophe on his new role.
Christophe, please update your listings in the
Hi,
On Thu, 18 Apr 2024 at 10:15, FX Coudert wrote:
>
> > I regenerate auto* files from time to time for libgfortran. Regenerating
> > them has always been very fragile (using --enable-maintainer-mode),
> > and difficult to get right.
>
> I have never found them difficult to regenerate, but if yo
Hi,
On Mon, 25 Mar 2024 at 15:19, Christophe Lyon
wrote:
>
> On Thu, 21 Mar 2024 at 15:32, Christophe Lyon
> wrote:
> >
> > On Wed, 20 Mar 2024 at 16:34, Simon Marchi wrote:
> > >
> > > On 3/18/24 13:25, Christophe Lyon wrote:
> > > > Well t
On Thu, 4 Apr 2024 at 10:12, Jan Beulich wrote:
>
> On 03.04.2024 15:11, Christophe Lyon wrote:
> > On Wed, 3 Apr 2024 at 10:30, Jan Beulich wrote:
> >>
> >> On 03.04.2024 10:22, Christophe Lyon wrote:
> >>> Dear release managers and developers,
&g
Hi Mark,
On 4/4/24 23:35, Mark Wielaard wrote:
Hi Christophe,
On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon via Gdb wrote:
TL;DR: For the sake of improving precommit CI coverage and simplifying
workflows, I’d like to request a patch submission policy change, so
that we now
er wrote:
>> > On Wed, 3 Apr 2024, Jan Beulich wrote:
>> >> On 03.04.2024 10:45, Jakub Jelinek wrote:
>> >>> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote:
>> >>>> Any concerns/objections?
>> >>>
>> &
On Wed, 3 Apr 2024 at 12:21, Jan Beulich wrote:
>
> On 03.04.2024 10:57, Richard Biener wrote:
> > On Wed, 3 Apr 2024, Jan Beulich wrote:
> >> On 03.04.2024 10:45, Jakub Jelinek wrote:
> >>> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrot
On Wed, 3 Apr 2024 at 10:30, Jan Beulich wrote:
>
> On 03.04.2024 10:22, Christophe Lyon wrote:
> > Dear release managers and developers,
> >
> > TL;DR: For the sake of improving precommit CI coverage and simplifying
> > workflows, I’d like to request a patch submiss
Dear release managers and developers,
TL;DR: For the sake of improving precommit CI coverage and simplifying
workflows, I’d like to request a patch submission policy change, so
that we now include regenerated files. This was discussed during the
last GNU toolchain office hours meeting [1] (2024-03
On 3/27/24 20:07, Joel Sherrill wrote:
On Wed, Mar 27, 2024 at 3:53 AM Christophe Lyon via Gcc <mailto:gcc@gcc.gnu.org>> wrote:
Hi!
On 3/26/24 22:52, Joel Sherrill via Gcc wrote:
> Hi
>
> For RTEMS, we normally build a multilib'ed gcc+newlib
Hi!
On Mon, 25 Mar 2024 at 15:19, Christophe Lyon
wrote:
>
> On Thu, 21 Mar 2024 at 15:32, Christophe Lyon
> wrote:
> >
> > On Wed, 20 Mar 2024 at 16:34, Simon Marchi wrote:
> > >
> > > On 3/18/24 13:25, Christophe Lyon wrote:
> > > > Well t
On Tue, 26 Mar 2024 at 16:42, Jens Remus wrote:
>
> Am 15.03.2024 um 09:50 schrieb Christophe Lyon:
> > On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote:
> >> On 2024-03-13 04:02, Christophe Lyon via Gdb wrote:
> ...
> >> There's just the issue of files t
Hi!
On 3/26/24 22:52, Joel Sherrill via Gcc wrote:
Hi
For RTEMS, we normally build a multilib'ed gcc+newlib, but I have a case
where the CPU model is something not covered by our multilibs and not one
we are keen to add. I've looked around but not found anything that makes me
feel confident.
W
On Thu, 21 Mar 2024 at 15:32, Christophe Lyon
wrote:
>
> On Wed, 20 Mar 2024 at 16:34, Simon Marchi wrote:
> >
> > On 3/18/24 13:25, Christophe Lyon wrote:
> > > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit
> > > more complex
>
On Wed, 20 Mar 2024 at 16:34, Simon Marchi wrote:
>
> On 3/18/24 13:25, Christophe Lyon wrote:
> > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit
> > more complex
> > than just calling automake. IIUC it calls automake --foreign it a
Hi,
On Mon, 18 Mar 2024 at 18:25, Christophe Lyon
wrote:
>
> On Sat, 16 Mar 2024 at 18:16, Simon Marchi wrote:
> >
> >
> >
> > On 2024-03-15 04:50, Christophe Lyon via Gdb wrote:
> > > On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote:
> > >&g
On Fri, 15 Mar 2024 at 15:25, Tom Tromey wrote:
>
> > "Eric" == Eric Gallager writes:
>
> Eric> Also there are the files generated by cgen, too, which no one seems to
> Eric> know how to regenerate, either.
>
> I thought I sent out some info on this a while ago.
>
> Anyway what I do is make a
On Sat, 16 Mar 2024 at 18:16, Simon Marchi wrote:
>
>
>
> On 2024-03-15 04:50, Christophe Lyon via Gdb wrote:
> > On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote:
> >> My first thought it: why is it a Makefile target, instead of some script
> >> on the si
On Fri, 15 Mar 2024 at 15:13, Eric Gallager wrote:
>
> On Fri, Mar 15, 2024 at 4:53 AM Christophe Lyon via Gcc
> wrote:
> >
> > On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote:
> > >
> > >
> > >
> > > On 2024-03-13 04:02, Christophe Lyo
On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote:
>
>
>
> On 2024-03-13 04:02, Christophe Lyon via Gdb wrote:
> > Hi!
> >
> > After recent discussions on IRC and on the lists about maintainer-mode
> > and various problems with auto-generated source files, I
Hi!
After recent discussions on IRC and on the lists about maintainer-mode
and various problems with auto-generated source files, I've written
this small prototype.
Based on those discussions, I assumed that people generally want to
update autotools files using a script similar to autoregen.py, w
On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw wrote:
>
>
>
> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
> >> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
> >>>
> >>> O
On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
>
> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote:
> >
> > Hi!
> >
> > On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
> > >
> > > Hi!
> > >
> > > On 2024-03
Hi!
On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
>
> Hi!
>
> On 2024-03-04T00:30:05+, Sam James wrote:
> > Mark Wielaard writes:
> >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> >>> [...], I read
> >>> http
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote:
>
> Hi Christophe,
>
> On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote:
> > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> > > That python script works across gcc/binutils/gdb:
> > > https://sour
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote:
>
> Hi Christophe,
>
> On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote:
> > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> > > That python script works across gcc/binutils/gdb:
> > > https://sour
On Thu, 29 Feb 2024 at 20:49, Thiago Jung Bauermann
wrote:
>
>
> Hello,
>
> Christophe Lyon writes:
>
> > I hoped improving this would be as simple as adding
> > --enable-maintainer-mode when configuring, after making sure
> > autoconf-2.69 and automake-1.15.
On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
>
> Hi Christophe,
>
> On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
> > I've noticed that sourceware's buildbot has a small script
> > "autoregen.py" which does not use the
On Thu, 29 Feb 2024 at 11:41, Richard Earnshaw (lists)
wrote:
>
> On 29/02/2024 10:22, Christophe Lyon via Gcc wrote:
> > Hi!
> >
> > Sorry for cross-posting, but I'm not sure the rules/guidelines are the
> > same in gcc vs binutils/gdb.
> >
> > TL
Hi!
Sorry for cross-posting, but I'm not sure the rules/guidelines are the
same in gcc vs binutils/gdb.
TL;DR: are there some guidelines about how to use/enable maintainer-mode?
In the context of the Linaro CI, I've been looking at enabling
maintainer-mode at configure time in our configurations
On Tue, 7 Nov 2023 at 15:36, Martin Jambor wrote:
>
> Hello,
>
> On Tue, Nov 07 2023, Maxim Kuvyrkov wrote:
> n>> On Nov 6, 2023, at 21:19, Christophe Lyon
> wrote:
> >>
> >> Hi!
> >>
> >> On Mon, 6 Nov 2023 at 18:05, Martin Jambor w
Hi!
On Mon, 6 Nov 2023 at 18:05, Martin Jambor wrote:
>
> Hello,
>
> I have inherited Martin Liška's buildbot script that checks that all
> sorts of autotools generated files, mainly configure scripts, were
> re-generated correctly when appropriate. While the checks are hopefully
> useful, they
Hi!
The config/dfp.m4 file does not have a license header. Several other .m4
files in the same directory have a GPL header, many others do not.
Can someone confirm the license of dfp.m4 and add the missing header if
applicable?
Thanks!
Christophe
On Thu, 1 Apr 2021 at 14:35, Richard Biener wrote:
>
>
> The first release candidate for GCC 10.3 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/
> ftp://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/
>
> and shortly its mirrors. It has been generated from git
On Thu, 24 Sep 2020 at 14:12, Christophe Lyon
wrote:
>
> On Wed, 23 Sep 2020 at 17:50, Christophe Lyon
> wrote:
> >
> > On Wed, 23 Sep 2020 at 17:33, Martin Sebor wrote:
> > >
> > > On 9/23/20 2:54 AM, Christophe Lyon wrote:
> > > >
On Wed, 23 Sep 2020 at 17:50, Christophe Lyon
wrote:
>
> On Wed, 23 Sep 2020 at 17:33, Martin Sebor wrote:
> >
> > On 9/23/20 2:54 AM, Christophe Lyon wrote:
> > > On Wed, 23 Sep 2020 at 01:47, Martin Sebor wrote:
> > >>
> > >> On 9/22/20 9:1
On Wed, 23 Sep 2020 at 14:33, David Edelsohn wrote:
>
> On Wed, Sep 23, 2020 at 8:26 AM Christophe Lyon via Gcc
> wrote:
> >
> > On Wed, 23 Sep 2020 at 12:26, Richard Earnshaw
> > wrote:
> > >
> > > On 23/09/2020 11:20, Jakub Jelinek via Gcc wrot
On Wed, 23 Sep 2020 at 17:33, Martin Sebor wrote:
>
> On 9/23/20 2:54 AM, Christophe Lyon wrote:
> > On Wed, 23 Sep 2020 at 01:47, Martin Sebor wrote:
> >>
> >> On 9/22/20 9:15 AM, Christophe Lyon wrote:
> >>> On Tue, 22 Sep 2020 at 17:02, Martin
On Wed, 23 Sep 2020 at 12:26, Richard Earnshaw
wrote:
>
> On 23/09/2020 11:20, Jakub Jelinek via Gcc wrote:
> > On Wed, Sep 23, 2020 at 10:22:52AM +0100, Richard Sandiford wrote:
> >> So that would give:
> >>
> >> Results for 8.4.1 20200918 [r8-10517] on arm-none-linux-gnueabihf
> >>
> >> and ho
On Wed, 23 Sep 2020 at 01:47, Martin Sebor wrote:
>
> On 9/22/20 9:15 AM, Christophe Lyon wrote:
> > On Tue, 22 Sep 2020 at 17:02, Martin Sebor wrote:
> >>
> >> Hi Christophe,
> >>
> >> While checking recent test results I noticed many posts with
compute farm I have access to.
Christophe
> Thanks
> Martin
>
> Results for 11.0.0 20200922 (experimental) [master revision
> r11-3343-g44135373fcdbe4019c5524ec3dff8e93d9ef113c] (GCC) testsuite on
> arm-none-eabi Christophe LYON
>
> Results for 11.0.0 20200922 (exp
] $remotefile"
+ } else {
+ set remotecmd "$remotefile"
+ }
+
set status [remote_exec $dest $remotefile $parg $inp]
remote_file $dest delete $remotefile.o $remotefile
if { [lindex $status 0] < 0 } {
--
2.7.4
From b6a3e52aec69146e930d85b84a81b1e059f2ffe5 Mon Sep 17 00
On Wed, 27 May 2020 at 22:40, Alexandre Oliva wrote:
>
> On May 27, 2020, Christophe Lyon via Gcc wrote:
>
> > On Wed, 27 May 2020 at 16:26, Jeff Law via Gcc wrote:
>
> >> Any thoughts on the massive breakage on the embedded ports in the
> >> testsuite?
>
On Wed, 27 May 2020 at 16:26, Jeff Law via Gcc wrote:
>
> On Wed, 2020-05-27 at 11:16 -0300, Alexandre Oliva wrote:
> > Hello, David,
> >
> > On May 26, 2020, David Edelsohn wrote:
> >
> > > Complaints about -dA, -dD, -dumpbase, etc.
> >
> > This was the main symptom of the problem fixed in the f
On Tue, 19 May 2020 at 13:28, Richard Earnshaw
wrote:
>
> On 11/05/2020 17:43, Christophe Lyon via Gcc wrote:
> > Hi,
> >
> >
> > As you may know, I've been running validations of GCC trunk in many
> > configurations for Arm and Aarch64.
> >
> &
On Wed, 13 May 2020 at 19:44, Jonathan Wakely via Gcc wrote:
>
> On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc wrote:
> >
> > I've changed the subject to match the 2015, 2017 and 2018 email threads.
> >
> > On May 13, 2020, at 3:26 AM, Thomas Schwinge
> > wrote:
> > >
> > > Comparing DejaGnu
Hi,
As you may know, I've been running validations of GCC trunk in many
configurations for Arm and Aarch64.
I was recently trying to make some cleanup in the new Bfloat16, MVE, CDE, and
ACLE tests because in several configurations I see 300-400 FAILs
mainly in these areas, because of “testisms”
On Tue, 7 Jan 2020 at 17:33, Christophe Lyon wrote:
>
> On Tue, 7 Jan 2020 at 17:18, Marc Glisse wrote:
> >
> > On Tue, 7 Jan 2020, Christophe Lyon wrote:
> >
> > > I've received a support request where GCC generates strd/ldrd which
> > > requir
On Tue, 7 Jan 2020 at 17:18, Marc Glisse wrote:
>
> On Tue, 7 Jan 2020, Christophe Lyon wrote:
>
> > I've received a support request where GCC generates strd/ldrd which
> > require aligned memory addresses, while the user code actually
> > provides sub-aligned poin
On Tue, 7 Jan 2020 at 17:06, Richard Earnshaw (lists)
wrote:
>
> On 07/01/2020 15:57, Christophe Lyon wrote:
> > Hi,
> >
> > I've received a support request where GCC generates strd/ldrd which
> > require aligned memory addresses, while the user code actuall
Hi,
I've received a support request where GCC generates strd/ldrd which
require aligned memory addresses, while the user code actually
provides sub-aligned pointers.
The sample code is derived from CMSIS:
#define __SIMD32_TYPE int
#define __SIMD32(addr) (*(__SIMD32_TYPE **) & (addr))
void foo(sh
On Mon, 25 Nov 2019 at 20:17, Andrew Dean via gcc wrote:
>
> Based on https://www.gnu.org/software/hurd/hurd/glibc.html, I'm using
> glibc/scripts/build-many-glibcs.py targeting aarch64-linux-gnu as so:
>
> build-many-glibcs.py build_dir checkout --keep all
>
> build-many-glibcs.py build_dir host
On Wed, 11 Sep 2019 at 14:21, Christophe Lyon
wrote:
>
> On Wed, 11 Sep 2019 at 11:56, Richard Sandiford
> wrote:
> >
> > Christophe Lyon writes:
> > > Hi,
> > >
> > > While looking at GCC validation results when configured for ARM
> &
On Wed, 11 Sep 2019 at 11:56, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > Hi,
> >
> > While looking at GCC validation results when configured for ARM
> > cortex-m33 by default, I noticed that
> > FAIL: gcc.target/arm/cmse/mainline/soft/cmse-
Hi,
While looking at GCC validation results when configured for ARM
cortex-m33 by default, I noticed that
FAIL: gcc.target/arm/cmse/mainline/soft/cmse-5.c -march=armv8-m.main
-mthumb -mfloat-abi=soft -O0 scan-assembler msr\tAPSR_nzcvqg, lr
The corresponding line in the testcase is (are):
/* {
On Fri, 21 Jun 2019 at 16:28, Iain Sandoe wrote:
>
> Hi Christophe,
>
> we’ve been looking at some cases where Darwin tests fail or pass unexpectedly
> depending on
> options. It came as a surprise to see it failing a test for shared support
> (since it’s always
> supported shared libs).
>
> --
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
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:1
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 Wed, 10 Apr 2019 at 11:42, Richard Earnshaw (lists)
wrote:
>
> On 10/04/2019 10:16, Christophe Lyon wrote:
> > On Wed, 10 Apr 2019 at 00:30, Richard Earnshaw
> > wrote:
> >>
> >> On 09/04/2019 13:26, Christophe Lyon wrote:
> >>> Hi,
> >>
On Wed, 10 Apr 2019 at 00:30, Richard Earnshaw
wrote:
>
> On 09/04/2019 13:26, Christophe Lyon wrote:
> > Hi,
> >
> > While building a newlib-based arm-eabi toolchain with
> > --with-multilib-list=rmprofile, I faced a linker assertion failure in
> > elf32_
Hi,
While building a newlib-based arm-eabi toolchain with
--with-multilib-list=rmprofile, I faced a linker assertion failure in
elf32_arm_merge_eabi_attributes (bfd/elf32-arm.c):
BFD_ASSERT (in_attr[Tag_ABI_HardFP_use].i == 0)
I traced this down to newlib's impure.o containing only data, and thus
On 20/03/2019 15:08, Moritz Strübe wrote:
Hey.
Am 11.03.2019 um 12:17 schrieb Jakub Jelinek:
On Mon, Mar 11, 2019 at 11:06:37AM +, Moritz Strübe wrote:
On 11.03.2019 at 10:14 Jakub Jelinek wrote:
You could build with -fsanitize=undefined, that would tell you at runtime you
have undefine
On Mon, 5 Nov 2018 at 21:49, Max Filippov wrote:
>
> On Fri, Nov 2, 2018 at 3:29 AM Christophe Lyon
> wrote:
> > I re-ran the wiki instructions with --target=xtensa-buildroot-uclinux-uclibc
> > and while gcc/g++ results looks mostly OK, the libstdc++ ones only show:
&
On Wed, 31 Oct 2018 at 16:43, Christophe Lyon
wrote:
>
> On Fri, 26 Oct 2018 at 19:54, Max Filippov wrote:
> >
> > On Fri, Oct 26, 2018 at 6:51 AM Christophe Lyon
> > wrote:
> > > On Sun, 21 Oct 2018 at 04:06, Max Filippov wrote:
> > > > Probabl
On Fri, 26 Oct 2018 at 19:54, Max Filippov wrote:
>
> On Fri, Oct 26, 2018 at 6:51 AM Christophe Lyon
> wrote:
> > On Sun, 21 Oct 2018 at 04:06, Max Filippov wrote:
> > > Probably the easiest way to get all xtensa toolchain parts correctly it
> > > by using exis
On Sun, 21 Oct 2018 at 04:06, Max Filippov wrote:
>
> Hello,
>
> On Tue, Oct 16, 2018 at 1:54 PM Jim Wilson wrote:
> >
> > On 10/16/18 7:19 AM, Christophe Lyon wrote:
> > > While reviewing one of my patches about FDPIC support for ARM, Richard
> > >
Hi,
While reviewing one of my patches about FDPIC support for ARM, Richard
raised the concern of testing the patch on other uClinux targets [1].
I looked at uclinux.org and at the GCC maintainers file, but it's
still not obvious to me which uClinux targets are currently supported?
I'd like to do
On Thu, 28 Jun 2018 at 17:23, Steve Ellcey wrote:
>
> Does anyone know anything about these failures that I see on my aarch64
> build & test?
>
> FAIL: gcc.dg/tree-ssa/pr77445-2.c scan-tree-dump-not thread3 "not considered"
> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump-not vrp2 "Jumps
On 8 June 2018 at 16:41, Jonathan Wakely wrote:
> On 8 June 2018 at 14:22, Christophe Lyon wrote:
>> Hi,
>>
>> As I reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
>> GCC for aarch64*-none-elf fails when configuring libst
Hi,
As I reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
GCC for aarch64*-none-elf fails when configuring libstdc++ since
r261034 (a week ago).
The root cause is PR66203 which I reported quite some time ago, which
points to a newlib problem: on aarch64 there is no
On 20 December 2017 at 11:02, Paulo Matos wrote:
>
>
> On 20/12/17 10:51, Christophe Lyon wrote:
>>
>> The recent fix changed the Makefile and configure script in libatomic.
>> I guess that if your incremental builds does not run configure, it's
>> stil
On 20 December 2017 at 09:31, Paulo Matos wrote:
>
>
> On 15/12/17 10:21, Christophe Lyon wrote:
>> On 15 December 2017 at 10:19, Paulo Matos wrote:
>>>
>>>
>>> On 14/12/17 21:32, Christophe Lyon wrote:
>>>> Great, I thought the CF machines w
On 15 December 2017 at 10:19, Paulo Matos wrote:
>
>
> On 14/12/17 21:32, Christophe Lyon wrote:
>> Great, I thought the CF machines were reserved for developpers.
>> Good news you could add builders on them.
>>
>
> Oh. I have seen similar things happening on CF m
On 14 December 2017 at 09:56, Paulo Matos wrote:
> Hello,
>
> Apologies for the delay on the update. It was my plan to do an update on
> a monthly basis but it slipped by a couple of weeks.
>
Hi,
Thanks for the update!
> The current status is:
>
> *Workers:*
>
> - x86_64
>
> 2 workers from CF (
On 11 October 2017 at 11:03, Paulo Matos wrote:
>
>
> On 11/10/17 10:35, Christophe Lyon wrote:
>>
>> FWIW, we consider regressions:
>> * any->FAIL because we don't want such a regression at the whole testsuite
>> level
>> * any->UNRESOLVED f
On 11 October 2017 at 08:34, Paulo Matos wrote:
>
>
> On 10/10/17 23:25, Joseph Myers wrote:
>> On Tue, 10 Oct 2017, Paulo Matos wrote:
>>
>>> new test -> FAIL; New test starts as fail
>>
>> No, that's not a regression, but you might want to treat it as one (in the
>> sense that it's a
On 20 September 2017 at 17:01, Paulo Matos wrote:
> Hi all,
>
> I am internally running buildbot for a few projects, including one for a
> simple gcc setup for a private port. After some discussions with David
> Edelsohn at the last couple of Cauldrons, who told me this might be
> interesting for
On 8 June 2017 at 11:57, Georg-Johann Lay wrote:
> On 05.06.2017 18:25, Jim Wilson wrote:
>>
>> On 06/01/2017 05:59 AM, Georg-Johann Lay wrote:
>>>
>>> Hi, when I am running the gcc testsuite in $builddir/gcc then
>>> $ make check-gcc RUNTESTFLAGS='ubsan.exp'
>>> comes up with spurious fails.
>>
>
On 13 October 2016 at 20:30, Prathamesh Kulkarni
wrote:
> On 13 October 2016 at 23:12, Prathamesh Kulkarni
> wrote:
>> Hi,
>> I am getting the following error when bootstrapping trunk (tried with
>> r241108)
>> on x86_64-unknown-linux-gnu during stage-1:
>>
>> ../../../../gcc/libstdc++-v3/src/c+
9:47 AM, Yury Gribov wrote:
>> On 09/30/2014 07:15 PM, Christophe Lyon wrote:
>>>
>>> Hello,
>>>
>>> After I've recently enabled Address Sanitizer for AArch64 in GCC, I'd
>>> like to enable Leak Sanitizer.
>>>
>>> I&#x
On 10 October 2014 16:19, Jakub Jelinek wrote:
> On Fri, Oct 10, 2014 at 04:09:39PM +0200, Christophe Lyon wrote:
>> my.exp contains the following construct which is often used in the testsuite:
>> ==
>> foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.c]] {
&
Hi Jakub,
On 15 September 2014 18:05, Jakub Jelinek wrote:
[...]
> # For parallelized check-% targets, this decides whether parallelization
> # is desirable (if -jN is used and RUNTESTFLAGS doesn't contain anything
> # but optional --target_board or --extra_opts arguments). If desirable,
>
Hi,
When Jason recently committed his fix for PR58678, I noticed that the
newly introduced test was failing on arm-linux target.
This is because testglue.o contains relocations incompatible with
-shared which is used in the testcase.
I am preparing a testsuite patch to fix that, but I am wonderi
Hello,
After I've recently enabled Address Sanitizer for AArch64 in GCC, I'd
like to enable Leak Sanitizer.
I'd like to know what are the requirements wrt testing it? IIUC there
are no lsan tests in the GCC testsuite so far.
Should I just test a few sample programs to check if basic functionalit
On 3 June 2014 14:46, Christophe Lyon wrote:
> On 3 June 2014 12:16, Yury Gribov wrote:
>>>> Is this 8G of RAM? If yes - I'd be curious to know which part of
>>>> libsanitizer needs so much memory.
>>>
>>>
>>> Here is what I have
On 3 June 2014 12:16, Yury Gribov wrote:
>>> Is this 8G of RAM? If yes - I'd be curious to know which part of
>>> libsanitizer needs so much memory.
>>
>>
>> Here is what I have in gcc.log:
>> ==12356==ERROR: AddressSanitizer failed to allocate 0x21000
>> (8589938688) bytes at address ff00
On 3 June 2014 08:39, Yury Gribov wrote:
> Christophe,
>
>
>> Indeed, when testing on my laptop, execution tests fail because
>> libsanitizer wants to allocated 8GB of memory (I am using qemu as
>> execution engine).
>
> Is this 8G of RAM? If yes - I'd be curious to know which part of
> libsanitiz
Hi,
I am updating my (small) patch to enable libsanitizer on AArch64, but
I am wondering about the testing.
Indeed, when testing on my laptop, execution tests fail because
libsanitizer wants to allocated 8GB of memory (I am using qemu as
execution engine).
When running on servers with more RAM, t
On 01/10/14 10:11, Richard Sandiford wrote:
Hi,
Philippe Baril Lecavalier writes:
I have been experimenting with buildbot lately, and I would be glad to
help in providing it. If there is interest, I could have a prototype and
a detailed proposal ready in a few days. It could serve GCC, binutil
Hi,
I am resuming investigations about disabling peeling for
alignment (see thread at
http://gcc.gnu.org/ml/gcc/2012-12/msg00036.html).
As a reminder, I have a simple patch which disables peeling
unconditionally and gives some improvement in benchmarks.
However, I've noticed a regression where a
Hi,
I have been looking at enabling libsanitizer for aarch64 GCC compilers.
To make the build succeed, I had to modify libsanitizer code:
- some syscalls are not available on aarch64 (libsanitizer uses some
legacy ones such as open, readlink, stat, ...)
- unwinding code needs to be added.
What's
On 14 February 2013 05:24, Konstantin Serebryany
wrote:
> Hi Christophe,
>
> Are you talking about ARM Linux?
Yes.
> It will be easier for us (asan developers) to fix this upstream first.
> Could you please file a bug at https://code.google.com/p/address-sanitizer/ ?
OK, just entered as #160
>
Hi,
I am working on enabing libsanitizer on ARM.
I have a very simple patch to enable it, and a sample program seems to
work on board.
However, I would like to use qemu as an execution engine, but I get
error messages from libsanitizer at startup:==30022== Shadow memory
range interleaves with an
On 11 December 2012 13:26, Tim Prince wrote:
> On 12/11/2012 5:14 AM, Richard Earnshaw wrote:
>>
>> On 11/12/12 09:56, Richard Biener wrote:
>>>
>>> On Tue, Dec 11, 2012 at 10:48 AM, Richard Earnshaw
>>> wrote:
On 11/12/12 09:45, Richard Biener wrote:
>
>
> On Mon, Dec 10, 2
On 10 December 2012 10:02, Richard Biener wrote:
> On Fri, Dec 7, 2012 at 6:30 PM, Richard Earnshaw wrote:
>> On 07/12/12 15:13, Christophe Lyon wrote:
>>>
>>> Hi,
>>>
>>> As ARM supports unaligned vector accesses for almost no penalty, I'
g or not, and
updated all the affected tests accordingly.
As there are quite a few tests to update, I'd like opinions first.
Thanks,
Christophe.
2012-12-07 Christophe Lyon
gcc/
* config/arm/arm.c (arm_vector_worth_peeling): New function.
(TARGET_VECTORIZE_VEC
On 26 October 2012 00:47, Steven Bosscher wrote:
> On Fri, Oct 26, 2012 at 12:26 AM, Andrew Pinski wrote:
>> The official wording from SPEC is that the sources are under the same
>> license as they are provided to them. It is the data files which are
>> under the SPEC license.
>
> Good. So the on
On 25 October 2012 16:10, Christophe Lyon wrote:
> On 24 October 2012 22:07, Steven Bosscher wrote:
>> On Wed, Oct 24, 2012 at 6:11 PM, Christophe Lyon wrote:
>>> On 24 October 2012 00:42, Steven Bosscher wrote:
>>>> On Tue, Oct 23, 2012 at 10:29 PM, Christophe L
1 - 100 of 120 matches
Mail list logo
