From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id ACF713858D1E; Mon, 20 Feb 2023 21:41:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ACF713858D1E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1676929283;
	bh=7LVWM8SHE1KzaamFP62lblTxNKazx+bWrHu3e7T4XLM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=vS00GGo0ifYytriteQ4TesxqziXg5+Grysx6suop3nxdC5KBCsLWOcslWuolH2lUf
	 561DfnetTYNR635cJ+6AfAWFVNvzJO8rbjC3eNXcR0Fq83dGZfhHuXr5uXLb9dSceu
	 cbIyqwZAXFXc1oEiyuOWHOCXNmmaaGZ97gsddXxI=
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/108865] gcc on Windows fails with Unicode path to source
 file
Date: Mon, 20 Feb 2023 21:41:23 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108865-4-X395UBdcve@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108865-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108865-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108865

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Costas Argyris from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Utf8 is the best generic solution really.
> > Using wmain is not very portable and the rest of gcc's sources can't use
> > wchar_t as that would break unix/Linux handling.
>=20
> Yes, on that, I was thinking to only use wchar_t in wmain just to get the
> arguments properly (not destroyed), and immediately convert to UTF-8 char
> arrays to pass to the rest of the program (starting with the call to
> driver.main which main wraps).    That way, all sources would stay the sa=
me
> working with char arrays, only this time it would be UTF-8 char arrays th=
at
> properly carry the Unicode args.    This would allow only selected parts =
of
> the Windows-specific code (possibly only in libiberty/pex-win32.c) to opt=
-in
> for the necessary conversion back to wchar_t UTF-16 arrays in order to ca=
ll
> the Unicode versions of Win32 APIs like CreateProcessW etc., and get
> end-to-end Unicode support on Windows.

I think that is bad solution in general.
Just use utf8 like every other target would.=