https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115044
Bug ID: 115044
Summary: -Wanalyzer-malloc-leak diagnostic in terminal path
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #15 from Andrew Cooper ---
Wow that's a lot of junk getting included for the minimal include set I could
easily make.
It occurs to me only after posting that you're liable to fail at:
asm ( ".include \"arch/x86/include/asm/asm-ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #14 from Andrew Cooper ---
Created attachment 54572
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54572&action=edit
Preprocessed example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #13 from Andrew Cooper ---
I've constructed an example which might be the knockon effect you were worried
about?
void foo(char *other)
{
char *ptr = NULL;
if ( current->domain )
ptr = other;
asm volatile ("cmc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #10 from Andrew Cooper ---
>From trying this out, a const attribute doesn't alter the code generation in
the slightest, so I presume GCC has already figured the const-ness out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #9 from Andrew Cooper ---
Thank-you for the fix.
I've recompiled master and this uninitialised warning has gone.
Unfortunately, Xen isn't GCC-13 clean (seems like a real bug in Xen), and the
analyser has pointed out various other t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #6 from Andrew Cooper ---
(In reply to David Malcolm from comment #5)
> Minimal reproducer: https://godbolt.org/z/E6EEY1WT6
>
> Am I right in understanding that:
> register unsigned long sp asm("rsp");
> is intended as a way to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
Andrew Cooper changed:
What|Removed |Added
Component|analyzer|c
--- Comment #4 from Andrew Cooper --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #2 from Andrew Cooper ---
__builtin_frame_address() does appear to resolve the warning, but the knock-on
effect for code generation is even worse than the asm() block.
It forces a frame-pointer setup in all functions that use it (wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
Bug ID: 108968
Summary: fanalyzer false positive with the uninitalised-ness of
the stack pointer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799
--- Comment #2 from Andrew Cooper ---
Adding a memory clobber doesn't make any difference that I can see, and I'm not
aware of any reason why it ought to make a difference.
I suppose that my real request here is to figure out what is the correc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799
Bug ID: 108799
Summary: Improper deprecation diagnostic for rsp clobber
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971
--- Comment #3 from Andrew Cooper ---
So yes - my experimentation did start from investigating the memory ordering
behaviour of these builtins, based on a thread on LKML.
The pushf in readflags and popf in writeflags have wildly different order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971
Bug ID: 104971
Summary: Optimisation for __builtin_ia32_readeflags corrupts
the stack
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816
--- Comment #7 from Andrew Cooper ---
(In reply to H.J. Lu from comment #5)
> Are you suggesting to add an option to generate jump table with ENDBR?
Jump tables are a legitimate optimisation. NOTRACK is a weakness in CET
protections, and fully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816
--- Comment #4 from Andrew Cooper ---
I've worked around this in Xen with:
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9d4a44380d273de22d5753883cbf5581795ff24d
and
https://lore.kernel.org/lkml/yixpv0q88paph...@hirez.programming.kic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #25 from Andrew Cooper ---
(In reply to H.J. Lu from comment #24)
> (In reply to Andrew Cooper from comment #23)
> > Apologies for the delay, but I do now have a working prototype of Xen with
> > CET-IBT active, using the current ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #40 from Andrew Cooper ---
I've given the GCC-11 branch a test and everything appears to be in order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #33 from Andrew Cooper ---
Looks good to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #30 from Andrew Cooper ---
(In reply to CVS Commits from comment #27)
>
> x86: Add -mharden-sls=[none|all|return|indirect-branch]
>
It occurs to me that `indirect-branch` needs renaming to be `indirect-jmp` as
the logic specifi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #23 from Andrew Cooper ---
Apologies for the delay, but I do now have a working prototype of Xen with
CET-IBT active, using the current version of these patches.
The result actually builds back to older versions of GCCs, but the lac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #21 from Andrew Cooper ---
Another possibly-bug, but possibly mis-expectations on my behalf.
I've found some code in the depths of Xen which is causing a failure on final
link due to a missing `__x86_indirect_thunk_nt_rax` symbol.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #20 from Andrew Cooper ---
(In reply to H.J. Lu from comment #19)
> (In reply to Andrew Cooper from comment #17)
> > I think I've found a bug in the -fcf-check-attribute implementation.
>
> Please try the v5 patch.
Thanks. That do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #17 from Andrew Cooper ---
I think I've found a bug in the -fcf-check-attribute implementation.
$ cat fnptr-array-arg.c
static int __attribute__((cf_check)) foo(char a[], int b)
{
return 0;
}
int (*ptr)(char[], int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #22 from Andrew Cooper ---
One curious thing I have discovered. While auditing the -mharden-sls=all code
generation in Xen, I found examples where I got "ret int3 ret int3" with no
intervening instructions.
It turns out this is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #14 from Andrew Cooper ---
(In reply to H.J. Lu from comment #13)
> (In reply to Andrew Cooper from comment #11)
> >
> > There should be a diagnostic, but it ought to include cf_check in the type
> > it prints.
>
> Try the v3 patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #11 from Andrew Cooper ---
(In reply to H.J. Lu from comment #10)
> (In reply to Andrew Cooper from comment #8)
> > Actually, there is a (possibly pre-existing) diagnostics issue:
> >
> > $ cat proto.c
> > static void __attribute__(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #8 from Andrew Cooper ---
Actually, there is a (possibly pre-existing) diagnostics issue:
$ cat proto.c
static void __attribute__((cf_check)) foo(void);
static void __attribute__((unused)) foo(void)
{
}
void (*ptr)(void) = foo;
$ g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #18 from Andrew Cooper ---
Yes to both.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #15 from Andrew Cooper ---
So this is the irritating corner case where the two options are linked.
*If* we are using -mindirect-branch-cs-prefix, then we intend to rewrite `jmp
__x86_indirect_thunk_*` to `jmp *%reg` or `lfence; jmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #2 from Andrew Cooper ---
(In reply to Martin Sebor from comment #1)
> The warning is intended: it points out that the second operand of the
> conditional expression is necessarily true:
>
> if ( !(pa ? &pa->c : NULL) )
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #7 from Andrew Cooper ---
Thankyou. I've tried these two patches and they do appear to be behaving as
intended.
I've put together a slightly extended version of the original test. Compile
with gcc -Wall -fno-pic -Os -fcf-protectio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
Bug ID: 102967
Summary: -Waddress with nested structures: Incorrect "the
comparison will always evaluate as 'true'"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #2 from Andrew Cooper ---
PeterZ has suggested that the straight line speculation case can be
dis-entangled with the thunk inlining case.
If an `int3` is emitted following any `jmp __x86_indirect_thunk_*` instruction
(i.e. treated a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
Bug ID: 102953
Summary: Improvements to CET-IBT and ENDBR generation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
--- Comment #1 from Andrew Cooper ---
https://bugs.llvm.org/show_bug.cgi?id=52323 for Clang cross-request.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
Bug ID: 102952
Summary: New code-gen options for retpolines and straight line
speculation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #15 from Andrew Cooper ---
(In reply to Martin Sebor from comment #1)
> For now, I recommend suppressing the warning either by #pragma GCC
> diagnostic or by making the pointer volatile.
Trying this with the code sample from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Andrew Cooper changed:
What|Removed |Added
CC||andrew.cooper3 at citrix dot
com
--- Co
39 matches
Mail list logo
