Hi all,
I was somewhat used to the bounds-checking patches for GCC 3.x from
Herman ten Brugge.
Now that GCC-4.x ships with mudflap, I am a bit confused, since the
bounds-checking patches also exist at least for until GCC-4.0.2.
What is the difference between the two systems?
Thanks,
Chris
Hi all,
I have been look at the Dwarf2 frame info generated by GCC, and how it
works.
From what I can see, only the register saves are recorded, and not the
restores. Why?
I guess it may loose GDB if one sets a breakpoint inside a function
epilogue, right?
I am currently working on the
Daniel Jacobowitz wrote:
I am currently working on the debug_frame info emission in our C/C++
compiler (based on Open64) and I have recently come across optimized
code which I don't know how to handle.
Reposting this question to increasingly unrelated lists is not likely
to help you find an a
Jim Wilson wrote:
Christophe LYON wrote:
I have been look at the Dwarf2 frame info generated by GCC, and how it
works.
From what I can see, only the register saves are recorded, and not
the restores. Why?
The frame info is primarily used for C++ EH stack unwinding. Since you
can't
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+
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 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
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 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
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
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
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,
>
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]] {
&
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
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 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
> > >
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 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 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 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
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 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_
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 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, 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 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 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).
>
> --
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 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-
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 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
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 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
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: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 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 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 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 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 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 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 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 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
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 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
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
Hello,
In a one year old thread, there was a discussion about a patch adding
-fuse-ld=gold and -fuse-ld=bfd options to GCC.
It seems the GCC part of the patch was never actually committed, as there were
some problems with LTO:
http://sourceware.org/ml/binutils/2011-01/msg00287.html
Unfortunat
On 25.01.2012 15:49, Richard Guenther wrote:
You can change the linker used by adjusting your path or giving an
appropriate -B option to the gcc driver.
Richard.
Yes, but part of the thread was precisely to discuss alternatives, more
end-user friendly (for those won't know the full path to a
On 25.01.2012 16:14, Richard Guenther wrote:
On Wed, Jan 25, 2012 at 3:55 PM, Christophe Lyon wrote:
On 25.01.2012 15:49, Richard Guenther wrote:
You can change the linker used by adjusting your path or giving an
appropriate -B option to the gcc driver.
Richard.
Yes, but part of the
Hello,
I have noticed a build failure with GCC-4.5.0, when configuring with:
--build=x86_64-unknown-linux-gnu
--host=arm-none-linux-gnueabi
--target=arm-none-linux-gnueabi
The build fails when compiling gcc/genconstants.c for the build machine:
In file included from ../../gcc/rtl.h:28,
On 06.08.2010 15:53, Joseph S. Myers wrote:
On Fri, 6 Aug 2010, Christophe LYON wrote:
From my brief investigation, I think that the problem is due to the fact that
struct real_value uses the 'long' type for the 'sig' field, while the
computation of REAL_WIDTH relies on HO
Hi all,
While trying to generate a ARM-GCC for Linux with hard and soft FP
multilibs, I have noticed that:
- arm/linux-elf.h says the default float ABI is "hard" and
multilib_defaults includes "mhard-float"
- arm/linux-eabi.h says the default float ABI is "soft" but does not
change the multi
Hi,
I have been investigating a problem I have while building Qt-embedded
with GCC-4.5.0 for ARM/Linux, and managed to produce the reduced test
case as follows.
Consider this shared library (C++):
atomic.cxx
int atomicIncrement(int volatile* addend)
{ return _
Hi,
I have just faced a problem where a C++ program (which I get in binary
form - I can't recompile) crashes when it uses libstdc++.so.6 from
GCC-4.5.1, while it works when using libstdc++.so.6 from GCC-4.4.5.
I am using an x86 machine.
Are there any known incompatibilities between these two lib
Hi all,
I am trying to build/install gcc-4.1.0 on my Linux box (RHEL-3), in a
non-standard prefix.
I use -with-libiconv-prefix the tell configure where to find libiconv,
and the configure step works.
The build step fails in libcpp:
/apa/gnu/Linux-RH-WS-3/gcc/gcc-3.4.4/bin/gcc -O2
-I/apa/gn
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
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
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 have recently added ARM support for builtin_bswap16, which uses the
rev16 instruction when dealing with an unsigned argument.
Considering:
unsigned short myfunc(unsigned short x) {
return __builtin_bswap16(x);
}
gcc -O2 generates:
myfunc:
rev16 r0, r0
uxthr0, r0
Hi,
While debugging a GCC failure on ARM when compiling with
-fprofile-use, I came across a case where if_convert merges 2 blocks
which belong to different partitions (hot/cold).
In turn merge_blocks() (in cfghooks.c) merges the BB flags by ORing
them, resulting in a block belonging to both cold
On 23 October 2012 19:45, Steven Bosscher wrote:
> Christophe wrote:
>> I think merge_blocks() should be modified to handle such cases;
>
> I think can_merge_blocks should be fixed. Blocks from different
> partitions should not be merged. See cfgrtl.c:rtl_can_merge_blocks and
> cfgrtl.c:cfg_layout
On 24 October 2012 00:42, Steven Bosscher wrote:
> On Tue, Oct 23, 2012 at 10:29 PM, Christophe Lyon
> wrote:
>> Well, both of these functions appear to check that the 2 blocks to
>> merge belong to the same partition, so it should be OK.
>
> In your first email, you sai
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 Lyon wrote:
>>>> Well, both of these functions appear
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
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
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 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'
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
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 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
>
Hello,
I have already asked this question on gcc-help (see
http://gcc.gnu.org/ml/gcc-help/2007-09/msg00328.html), but I would like
advice from GCC developers.
Basically, when I compile with -fno-exceptions, I wonder why the G++
compiler still generates calls to the standard new operator (th
Hello,
I have recently reported GCC bug #34030
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34030)
As it might have been fixed in 4.2.3, and as my concern is primarily for
the 4.1.1 branch (we don't want to upgrade now), I am ready to fix it in
my own sources.
However, I am not familiar wi
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 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
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, 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 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?
>
] $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
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
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
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 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 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: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 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 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
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
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
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!
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 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
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 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 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
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 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
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
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 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
1 - 100 of 121 matches
Mail list logo
