Re: [GSoC'19, libgomp work stealing] baseline benchmark results
Hi, On Thu, May 30 2019, 김규래 wrote: > Hi everyone, > Just wanted to share some quick baseline benchmark results [3]. > I ran LU decomposition on a AMD Ryzen Threadripper 1950x 16C/32T system. > LAPACK is currently plain loop parallel BLAS as far I believe. > And the upstream version of PLASMA uses OpenMP tasks [1]. > The colored region is the 95% confidence interval. > Task parallelism seems to scale pretty well on such a small scale benchmark. > I hope work-stealing could improve this even more. > An > > Ray Kim > > [1] YarKhan, Asim, et al. "Porting the PLASMA numerical library to the OpenMP > standard." International Journal of Parallel Programming 45.3 (2017): 612-633. > [2] https://bitbucket.org/icl/plasma/src/default/ > [3] Link to benchmark plot: https://m.imgur.com/ysxs5ol This last link leads to some sort of Error 404 page of imgur, or at least that's how I understand it. Maybe you have not copy'n'pasted the whole address? Thanks, Martin
Question about GCC not warning for some noncompliant SEI CERT C code examples
Hi
When reading the SEI CERT C Coding Standard rules, looking at
"DCL30-C. Declare objects with appropriate storage durations"
it seem like GCC does not warn in compile-time for some noncompliant examples.
I know eg AddressSanitizer and several runtime running tools finds these bugs,
but it would be convenient of GCC could do some basic static analysis already
in compile-time to avoid bad code generation.
Some static analysers finds these bugs, but not all, and GCC does not warn.
Example from DCL30-C, not warned by GCC:
/* NONCOMPLIANT EXAMPLE-1 */
#include
const char *p;
void dont_do_this(void) {
const char c_str[] = "This will change";
p = c_str; /* Dangerous */
}
void innocuous(void) {
printf("%s\n", p);
}
int main(void) {
dont_do_this();
innocuous();
return 0;
}
/* NONCOMPLIANT EXAMPLE-2 */
void squirrel_away(char **ptr_param) {
char local[10];
/* Initialize array */
*ptr_param = local;
}
void rodent(void) {
char *ptr;
squirrel_away(&ptr);
/* ptr is live but invalid here */
}
Question, where in GCC is the most appropriate place to implements such a
checker?
I know there are some warnings for return-local-addr, and
null-pointer-dereference in some different parts, but this seems different?
Can it be found be points-to analysis, or where is it best to put this warning
if being implemented?
Reference:
https://wiki.sei.cmu.edu/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations
Re: [GSoC'19, libgomp work stealing] baseline benchmark results
Hi, My bad. I broke the link capitalization by mistake. This is the correct link: http://imgur.com/YsxS5Ol Ray Kim -Original Message- From: "Martin Jambor" To: "김규래"; ; Cc: ; Sent: 2019-05-30 (목) 18:11:31 (GMT+09:00) Subject: Re: [GSoC'19, libgomp work stealing] baseline benchmark results Hi, On Thu, May 30 2019, 김규래 wrote: > Hi everyone, > Just wanted to share some quick baseline benchmark results [3]. > I ran LU decomposition on a AMD Ryzen Threadripper 1950x 16C/32T system. > LAPACK is currently plain loop parallel BLAS as far I believe. > And the upstream version of PLASMA uses OpenMP tasks [1]. > The colored region is the 95% confidence interval. > Task parallelism seems to scale pretty well on such a small scale benchmark. > I hope work-stealing could improve this even more. > An > > Ray Kim > > [1] YarKhan, Asim, et al. "Porting the PLASMA numerical library to the OpenMP > standard." International Journal of Parallel Programming 45.3 (2017): 612-633. > [2] https://bitbucket.org/icl/plasma/src/default/ > [3] Link to benchmark plot: https://m.imgur.com/ysxs5ol This last link leads to some sort of Error 404 page of imgur, or at least that's how I understand it. Maybe you have not copy'n'pasted the whole address? Thanks, Martin
Re: Question about GCC not warning for some noncompliant SEI CERT C code examples
On 5/30/19 3:12 AM, Fredrik Hederstierna wrote:
Hi
When reading the SEI CERT C Coding Standard rules, looking at
"DCL30-C. Declare objects with appropriate storage durations"
it seem like GCC does not warn in compile-time for some noncompliant examples.
I know eg AddressSanitizer and several runtime running tools finds these bugs,
but it would be convenient of GCC could do some basic static analysis already
in compile-time to avoid bad code generation.
Some static analysers finds these bugs, but not all, and GCC does not warn.
Example from DCL30-C, not warned by GCC:
/* NONCOMPLIANT EXAMPLE-1 */
#include
const char *p;
void dont_do_this(void) {
const char c_str[] = "This will change";
p = c_str; /* Dangerous */
}
void innocuous(void) {
printf("%s\n", p);
}
int main(void) {
dont_do_this();
innocuous();
return 0;
}
/* NONCOMPLIANT EXAMPLE-2 */
void squirrel_away(char **ptr_param) {
char local[10];
/* Initialize array */
*ptr_param = local;
}
void rodent(void) {
char *ptr;
squirrel_away(&ptr);
/* ptr is live but invalid here */
}
Agreed. This (or a subset of the problem) is being tracked in
PR 69433.
Question, where in GCC is the most appropriate place to implements such a
checker?
I know there are some warnings for return-local-addr, and
null-pointer-dereference in some different parts, but this seems different?
Can it be found be points-to analysis, or where is it best to put this warning
if being implemented?
To me it seems close enough to -Wreturn-local-addr to be implemented
in the same place, in gimple-ssa-isolate-paths.c. It's worth noting
that besides warning, the pass also clears the returning address and
isolates the path that returns the null in the CFG.
As it happens, I recently submitted a modest enhancement to
-Wreturn-local-addr to detect returning the addresses of VLAs and
pointers obtained from alloca (PR 71924 and PR 90549). I'm working
on extending the implementation to returning freed pointers (under
a separate warning option).
Besides the problems you mention, there is also a related request
to diagnose dereferencing pointers to compound literals whose
lifetime has ended (PR 89990), or more generally, those to any
such local object.
In the enhancement I submitted I chose not to use the alias oracle
mainly because I didn't want to change the existing design. I'm
not familiar enough with to tell with confidence if it can be used
to obtain the same results. I.e., identify each instance of
a local variable that a pointer may point to, rather than just
answering the broad question: does this pointer point to any
local variables? If it can, using it as Jeff suggests in his
comments, would make sense. I don't think moving it out of
gimple-ssa-isolate-paths.c is necessary (or even a good idea).
Martin
Reference:
https://wiki.sei.cmu.edu/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations
Re: Question about GCC not warning for some noncompliant SEI CERT C code examples
On 5/30/19 8:28 AM, Martin Sebor wrote:
> On 5/30/19 3:12 AM, Fredrik Hederstierna wrote:
>> Hi
>>
>> When reading the SEI CERT C Coding Standard rules, looking at
>> "DCL30-C. Declare objects with appropriate storage durations"
>> it seem like GCC does not warn in compile-time for some noncompliant
>> examples.
>>
>> I know eg AddressSanitizer and several runtime running tools finds
>> these bugs,
>> but it would be convenient of GCC could do some basic static analysis
>> already in compile-time to avoid bad code generation.
>> Some static analysers finds these bugs, but not all, and GCC does not
>> warn.
>>
>> Example from DCL30-C, not warned by GCC:
>>
>>
>> /* NONCOMPLIANT EXAMPLE-1 */
>> #include
>> const char *p;
>> void dont_do_this(void) {
>> const char c_str[] = "This will change";
>> p = c_str; /* Dangerous */
>> }
>> void innocuous(void) {
>> printf("%s\n", p);
>> }
>> int main(void) {
>> dont_do_this();
>> innocuous();
>> return 0;
>> }
>>
>>
>> /* NONCOMPLIANT EXAMPLE-2 */
>> void squirrel_away(char **ptr_param) {
>> char local[10];
>> /* Initialize array */
>> *ptr_param = local;
>> }
>> void rodent(void) {
>> char *ptr;
>> squirrel_away(&ptr);
>> /* ptr is live but invalid here */
>> }
>
> Agreed. This (or a subset of the problem) is being tracked in
> PR 69433.
>
>>
>> Question, where in GCC is the most appropriate place to implements
>> such a checker?
>> I know there are some warnings for return-local-addr, and
>> null-pointer-dereference in some different parts, but this seems
>> different?
>> Can it be found be points-to analysis, or where is it best to put this
>> warning if being implemented?
>
> To me it seems close enough to -Wreturn-local-addr to be implemented
> in the same place, in gimple-ssa-isolate-paths.c. It's worth noting
> that besides warning, the pass also clears the returning address and
> isolates the path that returns the null in the CFG.
>
> As it happens, I recently submitted a modest enhancement to
> -Wreturn-local-addr to detect returning the addresses of VLAs and
> pointers obtained from alloca (PR 71924 and PR 90549). I'm working
> on extending the implementation to returning freed pointers (under
> a separate warning option).
>
> Besides the problems you mention, there is also a related request
> to diagnose dereferencing pointers to compound literals whose
> lifetime has ended (PR 89990), or more generally, those to any
> such local object.
>
> In the enhancement I submitted I chose not to use the alias oracle
> mainly because I didn't want to change the existing design. I'm
> not familiar enough with to tell with confidence if it can be used
> to obtain the same results. I.e., identify each instance of
> a local variable that a pointer may point to, rather than just
> answering the broad question: does this pointer point to any
> local variables? If it can, using it as Jeff suggests in his
> comments, would make sense. I don't think moving it out of
> gimple-ssa-isolate-paths.c is necessary (or even a good idea).
Note that you may also be able to use the alias oracle to detect
escaping locals. That's likely to have a higher false positive rate,
but may still be useful for detecting this kind of stuff.
jeff
unrecognizable insn generated in plugin?
Hi all,
I've been trying to implement an idea Andy suggested recently for
preventing some kinds of ROP attacks. The discussion of the idea is
here:
https://lore.kernel.org/linux-mm/dfa69954-3f0f-4b79-a9b5-893d33d87...@amacapital.net/
Right now I'm struggling to get my plugin to compile without crashing. The
basic idea is to insert some code before every "pop rbp" and "pop rsp"; I've
figured out how to find these instructions, and I'm inserting code using:
emit_insn(gen_rtx_XOR(DImode, gen_rtx_REG(DImode, HARD_FRAME_POINTER_REGNUM),
gen_rtx_MEM(DImode, gen_rtx_REG(DImode,
HARD_FRAME_POINTER_REGNUM;
The plugin completes successfully, but GCC complains later,
kernel/seccomp.c: In function ‘seccomp_check_filter’:
kernel/seccomp.c:242:1: error: unrecognizable insn:
}
^
(insn 698 645 699 17 (xor:DI (reg:DI 6 bp)
(mem:DI (reg:DI 6 bp) [0 S8 A8])) "kernel/seccomp.c":242 -1
(nil))
during RTL pass: shorten
kernel/seccomp.c:242:1: internal compiler error: in insn_min_length, at
config/i386/i386.md:14714
I assume this is because some internal metadata is screwed up, but I have no
clue as to what that is or how to fix it. My gcc version is 8.3.0, and
config/i386/i386.md:14714 of that tag looks mostly unrelated.
I had problems earlier because I was trying to run it after *clean_state which
is the thing that does init_insn_lengths(), but now I'm running it after
*stack_regs, so I thought it should be ok...
Anyway, the full plugin draft is below. You can run it by adding
CONFIG_GCC_PLUGIN_HEAPLEAP=y to your kernel config.
Thanks!
Tycho
>From 83b0631f14784ce11362ebd64e40c8d25c0decee Mon Sep 17 00:00:00 2001
From: Tycho Andersen
Date: Fri, 19 Apr 2019 19:24:58 -0600
Subject: [PATCH] heapleap
Signed-off-by: Tycho Andersen
---
scripts/Makefile.gcc-plugins | 8 ++
scripts/gcc-plugins/Kconfig | 4 +
scripts/gcc-plugins/heapleap_plugin.c | 189 ++
3 files changed, 201 insertions(+)
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 5f7df50cfe7a..283b81dc5742 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -44,6 +44,14 @@ ifdef CONFIG_GCC_PLUGIN_ARM_SSP_PER_TASK
endif
export DISABLE_ARM_SSP_PER_TASK_PLUGIN
+gcc-plugin-$(CONFIG_GCC_PLUGIN_HEAPLEAP) += heapleap_plugin.so
+gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_HEAPLEAP)\
+ += -DHEAPLEAP_PLUGIN
+ifdef CONFIG_GCC_PLUGIN_HEAPLEAP
+DISABLE_HEAPLEAP_PLUGIN += -fplugin-arg-heapleap_plugin-disable
+endif
+export DISABLE_HEAPLEAP_PLUGIN
+
# All the plugin CFLAGS are collected here in case a build target needs to
# filter them out of the KBUILD_CFLAGS.
GCC_PLUGINS_CFLAGS := $(strip $(addprefix
-fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y))
$(gcc-plugin-cflags-y))
diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig
index 74271dba4f94..491b9cd5df1a 100644
--- a/scripts/gcc-plugins/Kconfig
+++ b/scripts/gcc-plugins/Kconfig
@@ -226,4 +226,8 @@ config GCC_PLUGIN_ARM_SSP_PER_TASK
bool
depends on GCC_PLUGINS && ARM
+config GCC_PLUGIN_HEAPLEAP
+ bool "Prevent 'pop esp' type instructions from loading an address in
the heap"
+ depends on GCC_PLUGINS
+
endif
diff --git a/scripts/gcc-plugins/heapleap_plugin.c
b/scripts/gcc-plugins/heapleap_plugin.c
new file mode 100644
index ..5051b96d79f4
--- /dev/null
+++ b/scripts/gcc-plugins/heapleap_plugin.c
@@ -0,0 +1,189 @@
+/*
+ * This is based on an idea from Andy Lutomirski described here:
+ *
https://lore.kernel.org/linux-mm/dfa69954-3f0f-4b79-a9b5-893d33d87...@amacapital.net/
+ *
+ * unsigned long offset = *rsp - rsp;
+ * offset >>= THREAD_SHIFT;
+ * if (unlikely(offset))
+ * BUG();
+ * POP RSP;
+ */
+
+#include "gcc-common.h"
+
+__visible int plugin_is_GPL_compatible;
+static bool disable = false;
+
+static struct plugin_info heapleap_plugin_info = {
+ .version = "1",
+ .help = "disable\t\tdo not activate the plugin\n"
+};
+
+static bool heapleap_gate(void)
+{
+ tree section;
+
+ /*
+* Similar to stackleak, we only do this for user code for now.
+*/
+ section = lookup_attribute("section",
+ DECL_ATTRIBUTES(current_function_decl));
+ if (section && TREE_VALUE(section)) {
+ section = TREE_VALUE(TREE_VALUE(section));
+
+ if (!strncmp(TREE_STRING_POINTER(section), ".init.text", 10))
+ return false;
+ if (!strncmp(TREE_STRING_POINTER(section), ".devinit.text", 13))
+ return false;
+ if (!strncmp(TREE_STRING_POINTER(section), ".cpuinit.text", 13))
+ return false;
+ if (!strncmp(TREE_STRING_POINTER(section), ".meminit.text", 13))
+ return false;
+ }
+
+ return !disable;
+}
+
+/*
+ * Check that:
+ *
+ * unsigned lo
Re: About GSOC.
Hi,
On Thu, May 30 2019, Tejas Joshi wrote:
> Hello.
> I tried to check the values for significand words using _Float128
> using a test program with value larger than 64 bit.
> Test program :
>
> int main ()
> {
> _Float128 x = 18446744073709551617.5; (i.e. 2^64 + 1.5 which is
> certainly longer than 64-bit)
> _Float128 y = __builtin_roundf128 (x);
> }
Interesting, I was also puzzled for a moment. But notice that:
int main ()
{
_Float128 x = 18446744073709551617.5f128;
_Float128 y = __builtin_roundf128 (x);
}
behaves as expected... the difference is of course the suffix pegged to
the literal constant (see
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
I would also expect GCC to use a larger type if a constant does not fit
into a double, but apparently that does not happen. I would have to
check but it is probably the right behavior according to the standard.
>
> The lower words of significand (sig[1] and sig[0] for 64-bit system)
> are still being zero. I haven't included the roundevenf128 yet but
> inspecting this on real_round function.
I figured out what was going on when I realized that in your testcase,
sig[0] was equal to 0x8000 and so some precision has been
lost. Then it was easy to guess that it was because it was represented
in a narrower type.
Hope this helps,
Martin
Re: unrecognizable insn generated in plugin?
On Thu, May 30, 2019 at 10:01 AM Tycho Andersen wrote:
>
> Hi all,
>
> I've been trying to implement an idea Andy suggested recently for
> preventing some kinds of ROP attacks. The discussion of the idea is
> here:
> https://lore.kernel.org/linux-mm/dfa69954-3f0f-4b79-a9b5-893d33d87...@amacapital.net/
>
> Right now I'm struggling to get my plugin to compile without crashing. The
> basic idea is to insert some code before every "pop rbp" and "pop rsp"; I've
> figured out how to find these instructions, and I'm inserting code using:
>
> emit_insn(gen_rtx_XOR(DImode, gen_rtx_REG(DImode, HARD_FRAME_POINTER_REGNUM),
> gen_rtx_MEM(DImode, gen_rtx_REG(DImode,
> HARD_FRAME_POINTER_REGNUM;
Simplely this xor does not set anything.
I think you want something like:
emit_insn(gen_rtx_SET(gen_rtx_REG(DImode, HARD_FRAME_POINTER_REGNUM),
gen_rtx_XOR(DImode, gen_rtx_REG(DImode, HARD_FRAME_POINTER_REGNUM),
gen_rtx_MEM(DImode, gen_rtx_REG(DImode, HARD_FRAME_POINTER_REGNUM);
But that might not work either, you might need some thing more.
Thanks,
Andrew Pinski
>
> The plugin completes successfully, but GCC complains later,
>
> kernel/seccomp.c: In function ‘seccomp_check_filter’:
> kernel/seccomp.c:242:1: error: unrecognizable insn:
> }
> ^
> (insn 698 645 699 17 (xor:DI (reg:DI 6 bp)
> (mem:DI (reg:DI 6 bp) [0 S8 A8])) "kernel/seccomp.c":242 -1
> (nil))
> during RTL pass: shorten
> kernel/seccomp.c:242:1: internal compiler error: in insn_min_length, at
> config/i386/i386.md:14714
>
> I assume this is because some internal metadata is screwed up, but I have no
> clue as to what that is or how to fix it. My gcc version is 8.3.0, and
> config/i386/i386.md:14714 of that tag looks mostly unrelated.
>
> I had problems earlier because I was trying to run it after *clean_state which
> is the thing that does init_insn_lengths(), but now I'm running it after
> *stack_regs, so I thought it should be ok...
>
> Anyway, the full plugin draft is below. You can run it by adding
> CONFIG_GCC_PLUGIN_HEAPLEAP=y to your kernel config.
>
> Thanks!
>
> Tycho
>
>
> From 83b0631f14784ce11362ebd64e40c8d25c0decee Mon Sep 17 00:00:00 2001
> From: Tycho Andersen
> Date: Fri, 19 Apr 2019 19:24:58 -0600
> Subject: [PATCH] heapleap
>
> Signed-off-by: Tycho Andersen
> ---
> scripts/Makefile.gcc-plugins | 8 ++
> scripts/gcc-plugins/Kconfig | 4 +
> scripts/gcc-plugins/heapleap_plugin.c | 189 ++
> 3 files changed, 201 insertions(+)
>
> diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
> index 5f7df50cfe7a..283b81dc5742 100644
> --- a/scripts/Makefile.gcc-plugins
> +++ b/scripts/Makefile.gcc-plugins
> @@ -44,6 +44,14 @@ ifdef CONFIG_GCC_PLUGIN_ARM_SSP_PER_TASK
> endif
> export DISABLE_ARM_SSP_PER_TASK_PLUGIN
>
> +gcc-plugin-$(CONFIG_GCC_PLUGIN_HEAPLEAP) += heapleap_plugin.so
> +gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_HEAPLEAP)\
> + += -DHEAPLEAP_PLUGIN
> +ifdef CONFIG_GCC_PLUGIN_HEAPLEAP
> +DISABLE_HEAPLEAP_PLUGIN += -fplugin-arg-heapleap_plugin-disable
> +endif
> +export DISABLE_HEAPLEAP_PLUGIN
> +
> # All the plugin CFLAGS are collected here in case a build target needs to
> # filter them out of the KBUILD_CFLAGS.
> GCC_PLUGINS_CFLAGS := $(strip $(addprefix
> -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y))
> $(gcc-plugin-cflags-y))
> diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig
> index 74271dba4f94..491b9cd5df1a 100644
> --- a/scripts/gcc-plugins/Kconfig
> +++ b/scripts/gcc-plugins/Kconfig
> @@ -226,4 +226,8 @@ config GCC_PLUGIN_ARM_SSP_PER_TASK
> bool
> depends on GCC_PLUGINS && ARM
>
> +config GCC_PLUGIN_HEAPLEAP
> + bool "Prevent 'pop esp' type instructions from loading an address in
> the heap"
> + depends on GCC_PLUGINS
> +
> endif
> diff --git a/scripts/gcc-plugins/heapleap_plugin.c
> b/scripts/gcc-plugins/heapleap_plugin.c
> new file mode 100644
> index ..5051b96d79f4
> --- /dev/null
> +++ b/scripts/gcc-plugins/heapleap_plugin.c
> @@ -0,0 +1,189 @@
> +/*
> + * This is based on an idea from Andy Lutomirski described here:
> + *
> https://lore.kernel.org/linux-mm/dfa69954-3f0f-4b79-a9b5-893d33d87...@amacapital.net/
> + *
> + * unsigned long offset = *rsp - rsp;
> + * offset >>= THREAD_SHIFT;
> + * if (unlikely(offset))
> + * BUG();
> + * POP RSP;
> + */
> +
> +#include "gcc-common.h"
> +
> +__visible int plugin_is_GPL_compatible;
> +static bool disable = false;
> +
> +static struct plugin_info heapleap_plugin_info = {
> + .version = "1",
> + .help = "disable\t\tdo not activate the plugin\n"
> +};
> +
> +static bool heapleap_gate(void)
> +{
> + tree section;
> +
> + /*
> +* Similar to stackleak, we only do this for user code for now.
> +*/
> + section = lookup_attribute("section",
> + DECL_ATTRIBUTES(current
Prof Laurie Hendren passed away
Dear community, Although I have not been involved with GCC for a number of years, I would like to share with the whole community the sad news that Prof Laurie Hendren passed away recently. Her work on SIMPLE was a key inspiration for the Tree SSA work in the early 2000s ( https://www.gnu.org/software/gcc/projects/tree-ssa/). I briefly interacted with Laurie when she agreed to be an external reviewer for my PhD thesis and, later on, when we started working on GIMPLE. She taught me a lot and was always ready to help and offer guidance, with a smile and keen insight. I will always be grateful for that. Here is the announcement from McGill: https://www.cs.mcgill.ca/news/105/ Laurie's wikipedia page: https://en.wikipedia.org/wiki/Laurie_Hendren Albert Cohen tells me that SIGPLAN is preparing a formal post, and a statement at PLDI next month. Probably more. Diego.
Re: unrecognizable insn generated in plugin?
Hi Andrew, On Thu, May 30, 2019 at 10:09:44AM -0700, Andrew Pinski wrote: > On Thu, May 30, 2019 at 10:01 AM Tycho Andersen wrote: > > > > Hi all, > > > > I've been trying to implement an idea Andy suggested recently for > > preventing some kinds of ROP attacks. The discussion of the idea is > > here: > > https://lore.kernel.org/linux-mm/dfa69954-3f0f-4b79-a9b5-893d33d87...@amacapital.net/ > > > > Right now I'm struggling to get my plugin to compile without crashing. The > > basic idea is to insert some code before every "pop rbp" and "pop rsp"; I've > > figured out how to find these instructions, and I'm inserting code using: > > > > emit_insn(gen_rtx_XOR(DImode, gen_rtx_REG(DImode, > > HARD_FRAME_POINTER_REGNUM), > > gen_rtx_MEM(DImode, gen_rtx_REG(DImode, > > HARD_FRAME_POINTER_REGNUM; > > Simplely this xor does not set anything. > I think you want something like: > emit_insn(gen_rtx_SET(gen_rtx_REG(DImode, HARD_FRAME_POINTER_REGNUM), > gen_rtx_XOR(DImode, gen_rtx_REG(DImode, HARD_FRAME_POINTER_REGNUM), > gen_rtx_MEM(DImode, gen_rtx_REG(DImode, HARD_FRAME_POINTER_REGNUM); > > But that might not work either, you might need some thing more. Yes, thanks. You're also right that I still see the same problem: kernel/seccomp.c: In function ‘seccomp_check_filter’: kernel/seccomp.c:242:1: error: unrecognizable insn: } ^ (insn 698 645 699 17 (set (reg:DI 6 bp) (xor:DI (reg:DI 6 bp) (mem:DI (reg:DI 6 bp) [0 S8 A8]))) "kernel/seccomp.c":242 -1 (nil)) during RTL pass: shorten kernel/seccomp.c:242:1: internal compiler error: in insn_min_length, at config/i386/i386.md:14714 Thanks, Tycho
Re: About GSOC.
On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
> Interesting, I was also puzzled for a moment. But notice that:
>
> int main ()
> {
> _Float128 x = 18446744073709551617.5f128;
> _Float128 y = __builtin_roundf128 (x);
> }
>
> behaves as expected... the difference is of course the suffix pegged to
> the literal constant (see
> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
>
> I would also expect GCC to use a larger type if a constant does not fit
> into a double, but apparently that does not happen. I would have to
> check but it is probably the right behavior according to the standard.
6.4.4.2/4: "An unsuffixed floating constant has type double." I don't
think your suggestion would be okay?
Segher
gcc-7-20190530 is now available
Snapshot gcc-7-20190530 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190530/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 271791 You'll find: gcc-7-20190530.tar.xzComplete GCC SHA256=b6e401cde73624b5b240ca2add4dc54805151cd55529315c256c79a36d877214 SHA1=097673a4c901cb08cb2c78f4c7ead9ed8a2e1c57 Diffs from 7-20190523 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
