Re: dejagnu version update? [CORRECTION: not a regression in DejaGnu; GDB testsuite bug]

Jacob Bachmeyer wrote: Maciej W. Rozycki wrote: [...] I ran a quick bisection and the culprit turned out to be: ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit commit ba60272a5ac6f6a7012acca03f596a6ed003f044 Author: Jacob Bachmeyer Date: Mon May 25 08:40:46 2020 -0600

Re: dejagnu version update?

Maciej W. Rozycki wrote: On Tue, 26 May 2020, Rob Savoye wrote: I'll run some RISC-V remote GCC/GDB testing and compare results for DejaGnu 1.6/1.6.1 vs trunk. It will take several days though, as it takes many hours to go through these testsuite runs. That'd be great. I'd rather

Re: Hello gcc. Why -fvtable-gc was removed from the compiler?

On Tue, 2020-06-09 at 20:35 +, sotrdg sotrdg via Gcc wrote: > What’s wrong with eliminating unused virtual functions in the binary? Nothing inherently wrong with the concept. But the implementation left a lot to be desired and I think it was ultimately scrapped as unmaintainable. jeff

Hello gcc. Why -fvtable-gc was removed from the compiler?

What’s wrong with eliminating unused virtual functions in the binary? Sent from Mail for Windows 10

Re: [haifa-sched][restore_pattern] Can we recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL？

On Thu, 2020-04-23 at 10:40 +, xuemaosheng wrote: > Product: GCC > Component: rtl-optimization > Version: 7.3.0 > > > If we add the flag DO_PREDICATION in scheduling ebb, the compiler will try to > predicate the insn when the producer insn has been issued, > and put the consumer insn into su

Re: [IMPORTANT] ChangeLog related changes

On Tue, 2 Jun 2020 at 15:25, Martin Liška wrote: > > On 6/2/20 4:14 PM, Jonathan Wakely wrote: > > On Tue, 2 Jun 2020 at 14:56, Jonathan Wakely wrote: > >> > >> On Tue, 2 Jun 2020 at 14:16, Martin Liška wrote: > >>> > >>> On 6/2/20 1:48 PM, Martin Liška wrote: > I tend to this approach. Let

Re: dejagnu version update?

On Tue, 26 May 2020, Rob Savoye wrote: > > I'll run some RISC-V remote GCC/GDB testing and compare results for > > DejaGnu 1.6/1.6.1 vs trunk. It will take several days though, as it takes > > many hours to go through these testsuite runs. > > That'd be great. I'd rather push out a stable r

Re: [PATCH 0/5] Improvements of the stackleak gcc plugin

On Thu, Jun 04, 2020 at 04:49:52PM +0300, Alexander Popov wrote: > In this patch series I collected various improvements of the stackleak > gcc plugin. Thanks! > Alexander Popov (5): > gcc-plugins/stackleak: Exclude alloca() from the instrumentation logic > gcc-plugins/stackleak: Use asm inst

Re: [PATCH 5/5] gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO

On Thu, Jun 04, 2020 at 02:58:06PM +0100, Will Deacon wrote: > On Thu, Jun 04, 2020 at 04:49:57PM +0300, Alexander Popov wrote: > > Don't try instrumenting functions in arch/arm64/kernel/vdso/vgettimeofday.c. > > Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin > > is dis

Re: [PATCH 4/5] gcc-plugins/stackleak: Don't instrument itself

On Thu, Jun 04, 2020 at 04:49:56PM +0300, Alexander Popov wrote: > There is no need to try instrumenting functions in kernel/stackleak.c. > Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin > is disabled. > > Signed-off-by: Alexander Popov Acked-by: Kees Cook -- Kees

Re: [PATCH 2/5] gcc-plugins/stackleak: Use asm instrumentation to avoid useless register saving

On Thu, Jun 04, 2020 at 04:49:54PM +0300, Alexander Popov wrote: > Let's improve the instrumentation to avoid this: > > 1. Make stackleak_track_stack() save all register that it works with. > Use no_caller_saved_registers attribute for that function. This attribute > is available for x86_64 and i3

Re: [PATCH 3/5] gcc-plugins/stackleak: Add 'verbose' plugin parameter

On Thu, Jun 04, 2020 at 04:49:55PM +0300, Alexander Popov wrote: > Add 'verbose' plugin parameter for stackleak gcc plugin. > It can be used for printing additional info about the kernel code > instrumentation. > > For using it add the following to scripts/Makefile.gcc-plugins: > gcc-plugin-cfla

Re: [PATCH 1/5] gcc-plugins/stackleak: Exclude alloca() from the instrumentation logic

On Thu, Jun 04, 2020 at 06:23:38PM +0300, Alexander Popov wrote: > On 04.06.2020 17:01, Jann Horn wrote: > > On Thu, Jun 4, 2020 at 3:51 PM Alexander Popov wrote: > >> Some time ago Variable Length Arrays (VLA) were removed from the kernel. > >> The kernel is built with '-Wvla'. Let's exclude allo

Re: 4.2 source

> On Jun 9, 2020, at 10:02 AM, James Dugan > wrote: > > Hello, > This is a long shot, but is there any archive of the 4.2 source code? I need > a build for a rhel5.4 server to support a p2v migration. I checked the > successful builds page and see that this version of rhel was not done for

4.2 source

Hello, This is a long shot, but is there any archive of the 4.2 source code? I need a build for a rhel5.4 server to support a p2v migration. I checked the successful builds page and see that this version of rhel was not done for 32bit. Thanks, Jim Dugan

Ideal Lifestyles you must Know: Finding happiness in relationship

[image: Ideal LIfestyles] Our Latest Posts Relationship matters: be whom you are BE WHOM YOU ARE Relationship gives humanity a chance to fellowship with each other in harmony. In fact, the essence of marriage is to fellowship together harnessing every potential deposits in both partners. True frie

Re: Inquire a potential bug when printing out GIMPLE ASAN statements

OK, I got it. Just a simple gimple_call_internal_p. Shuai On Tue, Jun 9, 2020 at 4:31 PM Shuai Wang wrote: > Hello, > > All right, now I know how to print out GIMPLE internal functions. I do the > following and it won't crash: > > const gcall* a = as_a (stmt); >

Re: Inquire a potential bug when printing out GIMPLE ASAN statements

Hello, All right, now I know how to print out GIMPLE internal functions. I do the following and it won't crash: const gcall* a = as_a (stmt); const char * tt = internal_fn_name(gimple_call_internal_fn(a)); However, just a follow-up question, how can I a

Re: Seeking clarification and way forward on limited scope variables.

On Tue, Jun 9, 2020 at 8:00 AM Tomar, Sourabh Singh wrote: > > [AMD Official Use Only - Internal Distribution Only] > > Hello Everyone, > > I need to have your thoughts on this. > > Consider the following test case -- > --- > 1int main(int Argc, char **

Re: Inquire a potential bug when printing out GIMPLE ASAN statements

Dear Richard, Thank you for the information. Yes, that makes sense to me. Nevertheless, is there any chance that I can still pinpoint this special function call? Currently I can iterate all GIMPLE call statements, but how to exactly figure out ASAN_MARK seems quite obscure. Thank you! Best, Shu

Re: Inquire a potential bug when printing out GIMPLE ASAN statements

On Tue, Jun 9, 2020 at 3:38 AM Shuai Wang via Gcc wrote: > > Hello! > > I am writing to report a potential bug I encountered when playing with the > GIMPLE IR. I enabled the ASan and would like to print out all ASAN_MARK > statements for the following simple code: > > int main(int argc ,char **ar