Hello,
I am new to the GCC code. I want to make a simple modification to the
back end. I want to add a debug exception (int3) to be generated
before any instance of certain x86 instructions.
I tried to modify gcc/config/i386/i386.md by adding a "int3" to the
define_insn for instructions of intere
On Thu, 22 Oct 2015, Martin Sebor wrote:
> > Again, LC_CTYPE does *not* affect source file interpretation.
>
> I understand what you're saying. What I am saying is that if this
> is how c99 behaves it's in conflict with POSIX because LC_CTYPE
> is exactly how source file interpretation is specifi
Again, LC_CTYPE does *not* affect source file interpretation.
I understand what you're saying. What I am saying is that if this
is how c99 behaves it's in conflict with POSIX because LC_CTYPE
is exactly how source file interpretation is specified to be
controlled:
LC_CTYPE
Determine the
Hi -
At the request of tbsaunders, we're experimenting with
provinding http[s] access to parts of the ftp://gcc.gnu.org/
contents. Please see http://gcc.gnu.org/ftp/ .
- FChE
On 10/22/2015 02:10 PM, Jeff Law wrote:
As for when the shift occurs to bugfixing, it's usually in early/mid
November each year. That also happens the be the deadline for
development patches to have been posted for review, hence most folks are
busy trying to wrap up their development work.
I'
On Thu, 22 Oct 2015, Joseph Myers wrote:
> multibyte characters in that output). (If an explicit character set is
> specified for LC_MESSAGES that's different from that in LC_CTYPE, you
> probably have a broken environment - multibyte characters need to have a
The specific wording in POSIX th
On Thu, 22 Oct 2015, Martin Sebor wrote:
> > LC_MESSAGES determines "the language and cultural conventions in which
> > messages should be written" (not necessarily the interpretation of
> > multibyte characters in that output).
>
> Yes, but setting LC_CTYPE shouldn't affect the format, language,
On 10/22/2015 01:38 AM, David Wohlferd wrote:
An updated Local Register Variables patch is attached with the changes
discussed. It also includes removing the extra space after '.' that
Segher has been giving me grief about and Jeff's request re Globals:
> Signaling that this stuff may change
On 10/22/2015 10:53 AM, Joseph Myers wrote:
On Wed, 21 Oct 2015, Martin Sebor wrote:
That would go against the usual (i.e., POSIX) expected effect
of the environment variable. Specifically for GCC (or the c99
utility), POSIX requires LC_CTYPE to determine the locale used
to parse the input, an
On Wed, 21 Oct 2015, Martin Sebor wrote:
> That would go against the usual (i.e., POSIX) expected effect
> of the environment variable. Specifically for GCC (or the c99
> utility), POSIX requires LC_CTYPE to determine the locale used
> to parse the input, and LC_MESSAGE to determine the locale of
On Wed, Sep 9, 2015 at 6:36 PM, Zack Weinberg wrote:
> The first, simpler problem is strictly optimization. explicit_bzero
> can be optimized to memset followed by a vacuous use of the memory
> region (generating no machine instructions, but preventing the stores
> from being deleted as dead); th
On Wed, Sep 9, 2015 at 10:26 PM, Szabolcs Nagy wrote:
> * Zack Weinberg [2015-09-09 15:03:50 -0400]:
>> On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote:
>> >> On Sep 9, 2015, at 1:54 PM, David Edelsohn
>> >> wrote:
>> >>
>> >> What level of erasure of sensitive data are you trying to ensure?
On 10/22/2015 09:08 AM, Vladimir Makarov wrote:
On 10/22/2015 06:05 AM, Dominik Vogt wrote:
On Tue, Oct 13, 2015 at 05:03:36PM -0400, Vladimir Makarov wrote:
[snip]
I checked my article
ftp://ftp.uvsq.fr/pub/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
and GVN gave mostly 0.2% on eon on
On 10/22/2015 06:05 AM, Dominik Vogt wrote:
On Tue, Oct 13, 2015 at 05:03:36PM -0400, Vladimir Makarov wrote:
[snip]
I checked my article
ftp://ftp.uvsq.fr/pub/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
and GVN gave mostly 0.2% on eon only. The current environment is
quite different (
On Thu, Oct 22, 2015 at 12:38:16AM -0700, David Wohlferd wrote:
> An updated Local Register Variables patch is attached with the changes
> discussed. It also includes removing the extra space after '.' that
> Segher has been giving me grief about and Jeff's request re Globals:
You must have und
在 2015/10/22 18:16, Szabolcs Nagy 写道:
> On 22/10/15 10:23, libin wrote:
>> From: Jiangjiji
>> Date: Sat, 10 Oct 2015 15:29:57 +0800
>> Subject: [PATCH] * gcc/config/aarch64/aarch64.opt: Add a new option.
>> * gcc/config/aarch64/aarch64.c: Add some new functions and Macros.
>> * gcc/config/aa
On 22/10/15 11:14, AKASHI Takahiro wrote:
On 10/22/2015 06:07 PM, libin wrote:
在 2015/5/28 16:39, Maxim Kuvyrkov 写道:
Our proposal is that instead of adding -mfentry/-mnop-count/-mrecord-mcount
options to other architectures,
we should
implement a target-independent option -fprolog-pad=N, which
On 22/10/15 10:23, libin wrote:
From: Jiangjiji
Date: Sat, 10 Oct 2015 15:29:57 +0800
Subject: [PATCH] * gcc/config/aarch64/aarch64.opt: Add a new option.
* gcc/config/aarch64/aarch64.c: Add some new functions and Macros.
* gcc/config/aarch64/aarch64.h: Modify PROFILE_HOOK and FUNCTION_PROFI
Li,
(added linux-arm-kernel to Cc.)
On 10/22/2015 06:07 PM, libin wrote:
在 2015/5/28 16:39, Maxim Kuvyrkov 写道:
Hi,
Akashi-san and I have been discussing required GCC changes to make kernel's
livepatching work for AArch64 and other
architectures. At the moment livepatching is supported for
On Tue, Oct 13, 2015 at 05:03:36PM -0400, Vladimir Makarov wrote:
[snip]
> I checked my article
>
> ftp://ftp.uvsq.fr/pub/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
>
> and GVN gave mostly 0.2% on eon only. The current environment is
> quite different (IRA, LRA) so the results might be d
Hi,
Sorry, forget to add mail list on last reply.
> However, looking more closely at the code, particularly delete_dep_node, it
> explicitly assumes that it won't be called with a node that is on another
> list. So it would indeed seem like the shallow copy is expected by design
> and other mech
From: Jiangjiji
Date: Sat, 10 Oct 2015 15:29:57 +0800
Subject: [PATCH] * gcc/config/aarch64/aarch64.opt: Add a new option.
* gcc/config/aarch64/aarch64.c: Add some new functions and Macros.
* gcc/config/aarch64/aarch64.h: Modify PROFILE_HOOK and FUNCTION_PROFILER.
Signed-off-by: Jiangjiji
Sign
在 2015/5/28 16:39, Maxim Kuvyrkov 写道:
Hi,
Akashi-san and I have been discussing required GCC changes to make kernel's livepatching work for
AArch64 and other architectures. At the moment livepatching is supported for x86[_64] using the
following options: "-pg -mfentry -mrecord-mcount -mnop-
Given this, I'm going to go ahead and re-work the local register
variables page (probably tomorrow) stating extended asm is the only
supported usage. Although I also think it's important to mention
Andrew's point. If someone sees it in code somewhere, at least the docs
will give them some idea
24 matches
Mail list logo