ping
On Fri, 14 Jul 2023 at 09:05, Costas Argyris
wrote:
> Pinging to try and get this bug in gcc-ar fixed.
>
> Note that the patch posted as an attachment in
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623400.html
>
> is exactly the same as the patch embedded in
>
>
Pinging to try and get this bug in gcc-ar fixed.
Note that the patch posted as an attachment in
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623400.html
is exactly the same as the patch embedded in
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623855.html
and the one posted in
Bootstrapped successfully on x86_64-pc-linux-gnu
On Fri, 7 Jul 2023 at 11:33, Costas Argyris
wrote:
> Problem: gcc-ar fails when a @file is passed to it:
>
> $ cat rsp
> --version
> $ gcc-ar @rsp
> /usr/bin/ar: invalid option -- '@'
>
> This is because a dash '-' is prepended to the first
>
Problem: gcc-ar fails when a @file is passed to it:
$ cat rsp
--version
$ gcc-ar @rsp
/usr/bin/ar: invalid option -- '@'
This is because a dash '-' is prepended to the first
argument if it doesn't start with one, resulting in
the wrong call 'ar -@rsp'.
Fix: Expand argv to get rid of any @files
I should also add that for a rsp file that contains just "--version":
gcc-ar @rsp
fails without the patch (current problem) and successfully prints
the version info with it.
On Sat, 1 Jul 2023 at 22:45, Costas Argyris
wrote:
> Basically implementing what Andrew said in the PR:
>
>
Basically implementing what Andrew said in the PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
If @file has been passed to gcc-ar, do the following:
1) Expand it to get an argv without any @files.
2) Then apply the plugin modifications to argv.
3) Create temporary response file.
4) Put
Some refactoring I thought would be useful while looking at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
I think some duplicated code can go away by doing this,
while also saving a bit of memory.
From c3f3b2fd53291805b5d0be19df6d1a348c5889ec Mon Sep 17 00:00:00 2001
From: Costas Argyris
Oh OK, thanks for the clarification.
Costas
On Wed, 7 Jun 2023 at 13:59, Jeff Law wrote:
>
>
> On 6/7/23 04:21, Costas Argyris via Gcc-patches wrote:
> > I saw this while working on something else:
> >
> > pex_unix_cleanup signature doesn't always match the
> &
I saw this while working on something else:
pex_unix_cleanup signature doesn't always match the
body of the function in terms of ATTRIBUTE_UNUSED.
If the conditional code in the body is compiled, then
ATTRIBUTE_UNUSED isn't correct.
This change makes it always match, thereby making it
a bit
You are right, this is also a remnant of the old function design
that I completely missed.Here is the follow-up patch for that.
Thanks for pointing it out.
Costas
On Tue, 6 Jun 2023 at 04:12, Jeff Law wrote:
>
>
> On 6/5/23 08:37, Costas Argyris via Gcc-patches wrote:
> >
writeargv can be simplified by getting rid of the error exit mode
that was only relevant many years ago when the function used
to open the file descriptor internally.
From 1271552baee5561fa61652f4ca7673c9667e4f8f Mon Sep 17 00:00:00 2001
From: Costas Argyris
Date: Mon, 5 Jun 2023 15:02:06 +0100
Thanks, here is the follow up patch for a couple typos in the same file.
On Mon, 5 Jun 2023 at 09:12, Jonathan Yong <10wa...@gmail.com> wrote:
> On 5/23/23 08:21, Jonathan Yong wrote:
> > On 5/22/23 13:25, Costas Argyris wrote:
> >> Currently on Windows, when CreateProcess is called with a
Currently on Windows, when CreateProcess is called with a command-line
that exceeds the 32k Windows limit, we get a very bad error:
"CreateProcess: No such file or directory"
This patch detects the case where this would happen and writes the
long command-line to a temporary response file and
This is proposed to fix PR109460 where an older version of
gcc (7.3) was used to build for windows (mingw) host.
From e5b608072f80a83cca65e88bb75ecc62ab0bbb87 Mon Sep 17 00:00:00 2001
From: Costas Argyris
Date: Wed, 12 Apr 2023 08:48:18 +0100
Subject: [PATCH] mingw: Support building with older
I forgot to update the relevant comments with the previous patch.
This is a comment-only patch that brings them up-to-date.
On Tue, 28 Mar 2023 at 09:05, Jonathan Yong <10wa...@gmail.com> wrote:
> On 3/27/23 17:17, Costas Argyris wrote:
> > The patch attached to this email extends the UTF-8
The patch attached to this email extends the UTF-8 support of the
driver and compiler processes to the 32-bit mingw host.Initially,
only the 64-bit host got it.
About the changes in sym-mingw32.cc:
Even though the 64-bit host was building fine with the symbol being
simply declared as a char,
could make it conditional on
the version then even those with earlier version wouldn't break,
they would just get the current behavior.
On Mon, 27 Mar 2023 at 11:00, Xi Ruoyao wrote:
> On Mon, 2023-03-27 at 10:36 +0100, Costas Argyris via Gcc-patches wrote:
> > [ping^3]
> >
>
[ping^3]
This looks like it fixes the bug and also unifies the way include paths are
passed from the driver to the compiler and assembler (when a @file has
been passed to the driver in the first place).
That is, when @file has been passed to the driver, put the include paths
in a temp @file and
Patch to fix native Windows MSYS2 package build failures.
The patch has been confirmed by both original reporters in the
PRs, and myself.
cc'd mingw-w64 maintainer for mingw-w64-specific issue.
0001-Fix-native-MSYS2-build-failure-PR108865-PR109188.patch
Description: Binary data
ping
On Thu, 9 Mar 2023 at 13:39, Costas Argyris
wrote:
> Pinging list and driver reviewer.
>
> Details here:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
>
> On Thu, 2 Mar 2023 at 19:25, Costas Argyris
> wrote:
>
>> This is a proposal to fix PR71850 by applying the existing logic
Pinging list and driver reviewer.
Details here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
On Thu, 2 Mar 2023 at 19:25, Costas Argyris
wrote:
> This is a proposal to fix PR71850 by applying the existing logic for
> passing include paths to cc1 to as.
>
> Thanks,
> Costas
>
From
Pinging the list and mingw maintainer.
Analysis and pre-approval here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
On Wed, 8 Mar 2023 at 10:52, Costas Argyris
wrote:
> Added .manifest file to the make rule for utf8rc-mingw32.o, latest patch
> attached.
>
> On Tue, 7 Mar 2023 at 15:27,
Added .manifest file to the make rule for utf8rc-mingw32.o, latest patch
attached.
On Tue, 7 Mar 2023 at 15:27, Costas Argyris
wrote:
> Hi Jacek,
>
> "but I think it should work just fine if you didn't explicitly limit the
> patch to x86_64."
>
> I would think so too.
>
> Actually, even cygwin
Hi Jacek,
"but I think it should work just fine if you didn't explicitly limit the
patch to x86_64."
I would think so too.
Actually, even cygwin might benefit from this, assuming it has the same
problem, which I don't know if it's the case.
But I'm not experienced with that so I would like to
wrote:
> Hi Costas,
>
> On 3/7/23 01:52, Costas Argyris via Gcc-patches wrote:
>
> This is a proposal for addressing
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
>
> by integrating the UTF-8 manifest file into gcc's build process for the
> 64-bit mingw host.
>
&
Hi
This is a proposal for addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
by integrating the UTF-8 manifest file into gcc's build process for the
64-bit mingw host.
The analysis and discussion leading up to the latest patch are written in
the bug report.
The patch attached in
This is a proposal to fix PR71850 by applying the existing logic for
passing include paths to cc1 to as.
Thanks,
Costas
From 393aff0d006ee9372cc8b9321c612c2dfb4b0a31 Mon Sep 17 00:00:00 2001
From: Costas Argyris
Date: Thu, 2 Mar 2023 18:27:22 +
Subject: [PATCH] driver: Treat include path
nd-line from ARGV. It is the caller's
> >responsibility to free the string returned. */
> >
> > Thanks,
> > Costas
> >
> > On Thu, 2 Mar 2023 at 07:32, Richard Biener
> wrote:
> >>
> >> On Wed, Mar 1, 2023 at 7:14 PM Costas Argyris via Gcc
at 07:32, Richard Biener
wrote:
> On Wed, Mar 1, 2023 at 7:14 PM Costas Argyris via Gcc-patches
> wrote:
> >
> > Hi
> >
> > It seems that the win32_spawn function in libiberty/pex-win32.c is
> leaking
> > the cmdline buffer in 2/3 exit scenarios (it is only
Hi
It seems that the win32_spawn function in libiberty/pex-win32.c is leaking
the cmdline buffer in 2/3 exit scenarios (it is only free'd in 1/3).The
problem here is that the cleanup code is written 3 times, one at each exit
scenario.
The proposed attached refactoring has the cleanup code
30 matches
Mail list logo
