[Bug c/114447] New: -fstack-protector-explicit ignored

[Bug c/114447] New: -fstack-protector-explicit ignored

[joakim.rosqvist at gmail dot com]

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

            Bug ID: 114447
           Summary: -fstack-protector-explicit ignored
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joakim.rosqvist at gmail dot com
  Target Milestone: ---

When I compile (gcc -v says 13.2.0-4ubuntu3)  this minimal C program to
assembly:

int main(int, char *[])
{
    return 0;
}

>gcc -fverbose-asm -S -o foo.s foo.c

I can see in the generated foo.s file that a few extra options were given to
the compiler:

# options passed: -mtune=generic -march=x86-64 -fasynchronous-unwind-tables
-fstack-protector-strong -fstack-clash-protection -fcf-protection

Presumably, these are wisely chosen built-in defaults in gcc.

Now let's add another option to the command line:

>gcc -fno-stack-protector -fverbose-asm -S -o foo.s foo.c

In the generated assembly we now get:

# options passed: -mtune=generic -march=x86-64 -fno-stack-protector
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

I.e. -fno-stack-protector  was added  and -fstack-protector-strong was removed
as the compiler correctly deduced that these conflict with each other and so
let the user-supplied option "win".  Everything is fine so far.

Now, let's compile like so:

>gcc -fstack-protector-explicit -fverbose-asm -S -o foo.s foo.c

The relevant resulting line is:

# options passed: -mtune=generic -march=x86-64 -fstack-protector-explicit
-fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection
-fcf-protection

I.e. this time the compiler did NOT understand that there is a conflict between
-fstack-protector-explicit  and builtin -fstack-protector-strong.
The first one should generate stack protection code only for functions with the
stack-protector attribute, while the second one should generate stack
protection code for all functions when possible.
Here -fstack-protector-strong wins and all functions get stack protection
regardless of whether they have the attribute.   So the user-supplied option is
effectively ignored.

[Bug c/114447] -fstack-protector-explicit ignored

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm common.opt has:
```
fstack-protector
Common Var(flag_stack_protect, 1) Init(-1) Optimization
Use propolice as a stack protection method.

fstack-protector-all
Common RejectNegative Var(flag_stack_protect, 2) Init(-1) Optimization
Use a stack protection method for every function.

fstack-protector-strong
Common RejectNegative Var(flag_stack_protect, 3) Init(-1) Optimization
Use a smart stack protection method for certain functions.

fstack-protector-explicit
Common RejectNegative Var(flag_stack_protect, 4) Optimization
Use stack protection method only for functions with the stack_protect
attribute.
```

Maybe fstack-protector-explicit is missing `Init(-1)`.

[Bug driver/114447] -fstack-protector-explicit ignored

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at gcc dot gnu.org
          Component|middle-end                  |driver

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's probably a specs issue instead (all the options should probably be aliases
to a new one with a ENUM specifier).

Note I guess that it's Ubuntu patching GCCs specs here (CCing maintainer).

[Bug driver/114447] -fstack-protector-explicit ignored

[doko at gcc dot gnu.org]

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Matthias Klose <doko at gcc dot gnu.org> ---
committed for the distro packages. it will take a while until these reach the
archives. closing the issue here, not an upstream issue.