public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
@ 2022-01-21 9:53 jakub at gcc dot gnu.org
2022-01-21 9:53 ` [Bug sanitizer/104158] " jakub at gcc dot gnu.org
` (11 more replies)
0 siblings, 12 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-21 9:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
Bug ID: 104158
Summary: [12 Regression] gcc no longer accepts
-fsanitize-coverage=trace-pc,trace-cmp since r12-1177
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
Since r12-1177-gc1681f22b4b44096f7bd8 gcc no longer accepts
-fsanitize-coverage=trace-pc,trace-cmp
We need -fconvert=swap,r16_ieee support for Fortran and
-Wbidi-chars=bidirectional,ucn too, so I'm going to look at adding either just
a helper or EnumSet *.opt handling.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
@ 2022-01-21 9:53 ` jakub at gcc dot gnu.org
2022-01-21 9:56 ` pinskia at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-21 9:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |12.0
Priority|P3 |P1
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
2022-01-21 9:53 ` [Bug sanitizer/104158] " jakub at gcc dot gnu.org
@ 2022-01-21 9:56 ` pinskia at gcc dot gnu.org
2022-01-21 10:29 ` rjones at redhat dot com
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-01-21 9:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu.org
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Having this will simplify some of the aarch64 options handling too.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
2022-01-21 9:53 ` [Bug sanitizer/104158] " jakub at gcc dot gnu.org
2022-01-21 9:56 ` pinskia at gcc dot gnu.org
@ 2022-01-21 10:29 ` rjones at redhat dot com
2022-01-21 12:03 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rjones at redhat dot com @ 2022-01-21 10:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
Richard W.M. Jones <rjones at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rjones at redhat dot com
--- Comment #2 from Richard W.M. Jones <rjones at redhat dot com> ---
Used by honggfuzz here:
https://github.com/google/honggfuzz/blob/master/hfuzz_cc/hfuzz-cc.c#L375
(Worked in GCC up to 11)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
` (2 preceding siblings ...)
2022-01-21 10:29 ` rjones at redhat dot com
@ 2022-01-21 12:03 ` jakub at gcc dot gnu.org
2022-01-21 12:51 ` marxin at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-21 12:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The commit also regressed -fno-sanitize-coverage=trace-pc etc. and the opt*.awk
extension I'm working will not be able to handled that.
What improvements the r12-1177 change brought?
-f{,no-}sanitize-coverage= should work like the -f{,no-}sanitize= and
-f{,no-}sanitize-recover= options, so it seems correct it was handled by the
same infrastructure.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
` (3 preceding siblings ...)
2022-01-21 12:03 ` jakub at gcc dot gnu.org
@ 2022-01-21 12:51 ` marxin at gcc dot gnu.org
2022-01-21 19:31 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-01-21 12:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
I was motivated by what the current master provides:
$ gcc -fsanitize-coverage=tracecmp a.c
gcc: error: unrecognized argument in option ‘-fsanitize-coverage=tracecmp’
gcc: note: valid arguments to ‘-fsanitize-coverage=’ are: trace-cmp trace-pc;
did you mean ‘trace-cmp’?
So providing a valid argument of the option.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
` (4 preceding siblings ...)
2022-01-21 12:51 ` marxin at gcc dot gnu.org
@ 2022-01-21 19:31 ` jakub at gcc dot gnu.org
2022-01-21 19:33 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-21 19:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-01-21
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52259&action=edit
gcc12-pr104158-1.patch
Untested patch for the option handling changes.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
` (5 preceding siblings ...)
2022-01-21 19:31 ` jakub at gcc dot gnu.org
@ 2022-01-21 19:33 ` jakub at gcc dot gnu.org
2022-01-21 19:33 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-21 19:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52260
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52260&action=edit
gcc12-pr104158-2.patch
Untested patch for this PR proper. The only behavior change is that
-fsanitize-coverage=trace-cmp,trace-cmp is no longer supported.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
` (6 preceding siblings ...)
2022-01-21 19:33 ` jakub at gcc dot gnu.org
@ 2022-01-21 19:33 ` jakub at gcc dot gnu.org
2022-01-24 10:53 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-21 19:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52261
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52261&action=edit
gcc12-pr104158-3.patch
Untested patch for Fortran -fconvert= extensions using this patch.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
` (7 preceding siblings ...)
2022-01-21 19:33 ` jakub at gcc dot gnu.org
@ 2022-01-24 10:53 ` cvs-commit at gcc dot gnu.org
2022-01-24 10:53 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-01-24 10:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:385196adb52d854ebf4f9237e8a521a17c5524c5
commit r12-6839-g385196adb52d854ebf4f9237e8a521a17c5524c5
Author: Jakub Jelinek <jakub@redhat.com>
Date: Mon Jan 24 11:50:15 2022 +0100
options: Add EnumSet and Set property support [PR104158]
The following patch is infrastructure support for at least 3 different
options that need changes:
1) PR104158 talks about a regression with the -fsanitizer-coverage=
option; in GCC 11 and older and on trunk prior to r12-1177, this
option behaved similarly to -f{,no-}sanitizer{,-recover}= options,
namely that the option allows negative and argument of the option
is a list of strings, each of them has some enumerator and
-fsanitize-coverage= enabled those bits in the underlying
flag_sanitize_coverage, while -fno-sanitize-coverage= disabled them.
So, -fsanitize-coverage=trace-pc,trace-cmp was equivalent to
-fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp and both
set flag_sanitize_coverage to
(SANITIZE_COV_TRACE_PC | SANITIZE_COV_TRACE_CMP)
Also, e.g.
-fsanitize-coverage=trace-pc,trace-cmp -fno-sanitize-coverage=trace-pc
would in the end set flag_sanitize_coverage to
SANITIZE_COV_TRACE_CMP (first set both bits, then subtract one)
The r12-1177 change, I think done to improve argument misspelling
diagnostic, changed the option incompatibly in multiple ways,
-fno-sanitize-coverage= is now rejected, only a single argument
is allowed, not multiple and
-fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp
enables just SANITIZE_COV_TRACE_CMP and not both (each option
overrides the previous value)
2) Thomas Koenig wants to extend Fortran -fconvert= option for the
ppc64le real(kind=16) swapping support; currently the option
accepts -fconvert={native,swap,big-endian,little-endian} and the
intent is to add support for -fconvert=r16_ibm and -fconvert=r16_ieee
(that alone is just normal Enum), but also to handle
-fconvert=swap,r16_ieee or -fconvert=r16_ieee,big-endian but not
-fconvert=big-endian,little-endian - the
native/swap/big-endian/little-endian are one mutually exclusive set
and r16_ieee/r16_ibm another one.
See https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587943.html
and thread around that.
3) Similarly Marek Polacek wants to extend the -Wbidi-chars= option,
such that it will handle not just the current
-Wbidi-chars={none,bidirectional,any}, but also -Wbidi-chars=ucn
and bidirectional,ucn and ucn,any etc. Again two separate sets,
one none/bidirectional/any and another one ucn.
See https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588960.html
The following patch adds framework for this and I'll post incremental
patches for 1) and 2).
As I've tried to document, such options are marked by additional
EnumSet property on the option and in that case all the EnumValues
in the Enum referenced from it must use a new Set property with set
number (initially I wanted just mark last enumerator in each mutually
exclusive set, but optionlist is sorted and so it doesn't really work
well). So e.g. for the Fortran -fconvert=, one specifies:
fconvert=
Fortran RejectNegative Joined Enum(gfc_convert) EnumSet Var(flag_convert)
Init(GFC_FLAG_CONVERT_NATIVE)
-fconvert=<big-endian|little-endian|native|swap|r16_ieee|r16_ibm> The
endianness used for unformatted files.
Enum
Name(gfc_convert) Type(enum gfc_convert) UnknownError(Unrecognized option
to endianness value: %qs)
EnumValue
Enum(gfc_convert) String(big-endian) Value(GFC_FLAG_CONVERT_BIG) Set(1)
EnumValue
Enum(gfc_convert) String(little-endian) Value(GFC_FLAG_CONVERT_LITTLE)
Set(1)
EnumValue
Enum(gfc_convert) String(native) Value(GFC_FLAG_CONVERT_NATIVE) Set(1)
EnumValue
Enum(gfc_convert) String(swap) Value(GFC_FLAG_CONVERT_SWAP) Set(1)
EnumValue
Enum(gfc_convert) String(r16_ieee) Value(GFC_FLAG_CONVERT_R16_IEEE) Set(2)
EnumValue
Enum(gfc_convert) String(r16_ibm) Value(GFC_FLAG_CONVERT_R16_IBM) Set(2)
and this says to the option handling code that
1) if only one arg is specified to one instance of the option, it can be
any
of those 6
2) if two args are specified, one has to be from the first 4 and another
from the last 2, in any order
3) at most 2 args may be specified (there are just 2 sets)
There is a requirement on the Value values checked in self-test, the
values from one set ored together must be disjunct from values from
another set ored together. In the Fortran case, the first 4 are 0-3
so mask is 3, and the last 2 are 4 and 8, so mask is 12.
When say -fconvert=big-endian is specified, it sets the first set
to GFC_FLAG_CONVERT_BIG (2) but doesn't modify whatever value the
other set had, so e.g.
-fconvert=big-endian -fconvert=r16_ieee
-fconvert=r16_ieee -fconvert=big-endian
-fconvert=r16_ieee,big_endian
-fconvert=big_endian,r16_ieee
all behave the same.
Also, with the EnumSet support, it is now possible to allow
not specifying RejectNegative - we can set some set's value and
then clear it and set it again to some other value etc.
I think with the 2) patch I achieve what we want for Fortran, for 1)
the only behavior from gcc 11 is that
-fsanitize-coverage=trace-cmp,trace-cmp is now rejected.
This is mainly from the desire to disallow
-fconvert=big-endian,little-endian or -Wbidi-chars=bidirectional,any
etc. where it would be confusing to users what exactly it means.
But it is the only from these options that actually acts as an Enum
bit set, each enumerator can be specified with all the others.
So one option would be stop requiring the EnumSet implies Set properties
must be specified and just require that either they are specified on all
EnumValues, or on none of them; the latter case would be for
-fsanitize-coverage= and the non-Set case would mean that all the
EnumValues need to have disjoint Value bitmasks and that they can
be all specified and unlike the Set case also repeated.
Thoughts on this?
2022-01-24 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/104158
* opt-functions.awk (var_set): Handle EnumSet property.
* optc-gen.awk: Don't disallow RejectNegative if EnumSet is
specified.
* opt-read.awk: Handle Set property.
* opts.h (CL_ENUM_SET_SHIFT, CL_ERR_ENUM_SET_ARG): Define.
(struct cl_decoded_option): Mention enum in value description.
Add mask member.
(set_option): Add mask argument defaulted to 0.
* opts.cc (test_enum_sets): New function.
(opts_cc_tests): Call it.
* opts-common.cc (enum_arg_to_value): Change return argument
from bool to int, on success return index into the cl_enum_arg
array, on failure -1. Add len argument, if non-0, use strncmp
instead of strcmp.
(opt_enum_arg_to_value): Adjust caller.
(decode_cmdline_option): Handle EnumSet represented as
CLVC_ENUM with non-zero var_value. Initialize decoded->mask.
(decode_cmdline_options_to_array): CLear opt_array[0].mask.
(handle_option): Pass decoded->mask to set_options last argument.
(generate_option): Clear decoded->mask.
(generate_option_input_file): Likewise.
(cmdline_handle_error): Handle CL_ERR_ENUM_SET_ARG.
(set_option): Add mask argument, use it for CLVC_ENUM.
(control_warning_option): Adjust enum_arg_to_value caller.
* doc/options.texi: Document Set and EnumSet properties.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
` (8 preceding siblings ...)
2022-01-24 10:53 ` cvs-commit at gcc dot gnu.org
@ 2022-01-24 10:53 ` cvs-commit at gcc dot gnu.org
2022-01-24 10:54 ` cvs-commit at gcc dot gnu.org
2022-01-24 11:02 ` jakub at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-01-24 10:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:cd0377a460db9d8b286e03a701227ebd62132c89
commit r12-6840-gcd0377a460db9d8b286e03a701227ebd62132c89
Author: Jakub Jelinek <jakub@redhat.com>
Date: Mon Jan 24 11:51:49 2022 +0100
options: Fix up -fsanitize-coverage= [PR104158]
This is incremental patch to fix up -fsanitize-coverage= option
handling, allow -fno-sanitize-coverage= again, allow both
options together in one option or make
-fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp
actually enable both suboptions rather than the last one.
2022-01-24 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/104158
* common.opt (flag_sanitize_coverage): Remove Variable entry.
(fsanitize-coverage=): Remove RejectNegative property, add
Var(flag_sanitize_coverage) and EnumSet properties.
(trace-pc): Add Set(1) property.
(trace-cmp): Add Set(2) property.
* opts.cc (common_handle_option): Don't handle
OPT_fsanitize_coverage_.
* gcc.dg/spellcheck-options-24.c: New test.
* gcc.dg/sancov/pr104158-1.c: New test.
* gcc.dg/sancov/pr104158-2.c: New test.
* gcc.dg/sancov/pr104158-3.c: New test.
* gcc.dg/sancov/pr104158-4.c: New test.
* gcc.dg/sancov/pr104158-5.c: New test.
* gcc.dg/sancov/pr104158-6.c: New test.
* gcc.dg/sancov/pr104158-7.c: New test.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
` (9 preceding siblings ...)
2022-01-24 10:53 ` cvs-commit at gcc dot gnu.org
@ 2022-01-24 10:54 ` cvs-commit at gcc dot gnu.org
2022-01-24 11:02 ` jakub at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-01-24 10:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:0ebb09f5e49c8ca06728bb791415d985df01f6d8
commit r12-6842-g0ebb09f5e49c8ca06728bb791415d985df01f6d8
Author: Jakub Jelinek <jakub@redhat.com>
Date: Mon Jan 24 11:53:08 2022 +0100
options: Add EnumBitSet property support [PR104158]
On Sat, Jan 22, 2022 at 01:47:08AM +0100, Jakub Jelinek via Gcc-patches
wrote:
> I think with the 2) patch I achieve what we want for Fortran, for 1)
> the only behavior from gcc 11 is that
> -fsanitize-coverage=trace-cmp,trace-cmp is now rejected.
> This is mainly from the desire to disallow
> -fconvert=big-endian,little-endian or -Wbidi-chars=bidirectional,any
> etc. where it would be confusing to users what exactly it means.
> But it is the only from these options that actually acts as an Enum
> bit set, each enumerator can be specified with all the others.
> So one option would be stop requiring the EnumSet implies Set properties
> must be specified and just require that either they are specified on all
> EnumValues, or on none of them; the latter case would be for
> -fsanitize-coverage= and the non-Set case would mean that all the
> EnumValues need to have disjoint Value bitmasks and that they can
> be all specified and unlike the Set case also repeated.
> Thoughts on this?
Here is an incremental patch to the first two patches of the series
that implements EnumBitSet that fully restores the -fsanitize-coverage
GCC 11 behavior.
2022-01-24 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/104158
* opt-functions.awk (var_set): Handle EnumBitSet property.
* optc-gen.awk: Don't disallow RejectNegative if EnumBitSet is
specified.
* opts.h (enum cl_enum_var_value): New type.
* opts-common.cc (decode_cmdline_option): Use CLEV_* values.
Handle CLEV_BITSET.
(cmdline_handle_error): Handle CLEV_BITSET.
* opts.cc (test_enum_sets): Also test EnumBitSet requirements.
* doc/options.texi (EnumBitSet): Document.
* common.opt (fsanitize-coverage=): Use EnumBitSet instead of
EnumSet.
(trace-pc, trace-cmp): Drop Set properties.
* gcc.dg/sancov/pr104158-7.c: Adjust for repeating of arguments
being allowed.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
` (10 preceding siblings ...)
2022-01-24 10:54 ` cvs-commit at gcc dot gnu.org
@ 2022-01-24 11:02 ` jakub at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-24 11:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-01-24 11:02 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-21 9:53 [Bug sanitizer/104158] New: [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177 jakub at gcc dot gnu.org
2022-01-21 9:53 ` [Bug sanitizer/104158] " jakub at gcc dot gnu.org
2022-01-21 9:56 ` pinskia at gcc dot gnu.org
2022-01-21 10:29 ` rjones at redhat dot com
2022-01-21 12:03 ` jakub at gcc dot gnu.org
2022-01-21 12:51 ` marxin at gcc dot gnu.org
2022-01-21 19:31 ` jakub at gcc dot gnu.org
2022-01-21 19:33 ` jakub at gcc dot gnu.org
2022-01-21 19:33 ` jakub at gcc dot gnu.org
2022-01-24 10:53 ` cvs-commit at gcc dot gnu.org
2022-01-24 10:53 ` cvs-commit at gcc dot gnu.org
2022-01-24 10:54 ` cvs-commit at gcc dot gnu.org
2022-01-24 11:02 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).