Bug 92860 - [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute
Summary: [9/10/11/12 regression] Global flags affected by -O settings are clobbered by...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 10.0
: P2 normal
Target Milestone: 12.0
Assignee: Not yet assigned to anyone
URL:
Keywords: deferred, opt-attribute
: 85961 (view as bug list)
Depends on: 99592 103905
Blocks:
  Show dependency treegraph
 
Reported: 2019-12-08 13:48 UTC by Jan Hubicka
Modified: 2024-03-27 00:54 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2019-12-08 00:00:00


Attachments
C source code (67.14 KB, text/plain)
2021-07-01 19:34 UTC, David Binderman
Details
C source code (70.07 KB, text/x-csrc)
2021-12-09 18:48 UTC, David Binderman
Details
preprocessed source code (68.53 KB, text/plain)
2022-01-04 11:14 UTC, David Binderman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Hubicka 2019-12-08 13:48:47 UTC
Hi,
the following testcase:
void linker_error();
__attribute__ ((optimize("-O0")))
int a ()
{
}
static int remove_me ()
{
  linker_error ();
}
void
main()
{
}

builds with GCC6 but not with GCC8, GCC9 and GCC10:
hubicka@lomikamen-jh:/aux/hubicka/trunk4/gcc$ gcc -O2 t.c
hubicka@lomikamen-jh:/aux/hubicka/trunk4/gcc$ /aux/hubicka/trunk-install/bin/gcc -O2 t.c
/usr/local/bin/ld: /tmp/cckSFE5R.o: in function `remove_me':
t.c:(.text+0x17): undefined reference to `linker_error'
collect2: error: ld returned 1 exit status

The problem is that while processing the optimize attribute for a we overwritte flag_toplevel_reorder that is affected by optimization flag but not marked as Optimization.  I suppose there are other cases like this.
Comment 1 Jan Hubicka 2019-12-08 13:51:03 UTC
Author: hubicka
Date: Sun Dec  8 13:50:32 2019
New Revision: 279089

URL: https://gcc.gnu.org/viewcvs?rev=279089&root=gcc&view=rev
Log:
	PR tree-optimization/92860
	* common.opt (fprofile-reorder-functions, ftoplevel-reorder): Add
	Optimization flag.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/common.opt
Comment 2 Jan Hubicka 2019-12-08 13:54:37 UTC
Partly fixed on trunk - I think we have other flags/params missing Optimization attribute that behaves same way.
Comment 3 Martin Liška 2019-12-11 14:18:18 UTC
Ok, I've prepared a debugging patch that can be probably added in next stage1:
https://github.com/marxin/gcc/tree/global-options-checking

Using the patch I see a violation of the following options:

     12 global_options difference in flag_omit_frame_pointer (1/0)
    141 global_options difference in warn_inline (1/0)
    695 global_options difference in param_min_crossjump_insns (5/1)
    718 global_options difference in param_max_combine_insns (4/2)
   1284 global_options difference in flag_merge_constants (1/0)
   1396 global_options difference in flag_ree (1/0)
   1601 global_options difference in param_max_fields_for_field_sensitive (0/100)

I'll prepare a test-cases for that.
Comment 4 Martin Liška 2019-12-11 14:45:02 UTC
Example 1:

$ cat tc.c
void linker_error();
__attribute__ ((optimize("-O0")))
int a ()
{
}

static int remove_me ()
{
  linker_error ();
}

void
main()
{
}

$ ./xgcc -B. -Os tc.c -c -momit-leaf-frame-pointer -m32
global_options difference in flag_merge_constants (1/0)
global_options difference in flag_merge_constants (1/0)
global_options difference in flag_omit_frame_pointer (1/0)
global_options difference in flag_ree (1/0)
tc.c:4:1: internal compiler error: in handle_optimize_attribute, at c-family/c-attribs.c:4505
    4 | {
      | ^
0x925d14 handle_optimize_attribute
	/home/marxin/Programming/gcc/gcc/c-family/c-attribs.c:4505
0x81fa2e decl_attributes(tree_node**, tree_node*, int, tree_node*)
	/home/marxin/Programming/gcc/gcc/attribs.c:713
0x83ab20 start_function(c_declspecs*, c_declarator*, tree_node*)
	/home/marxin/Programming/gcc/gcc/c/c-decl.c:9110
0x892c57 c_parser_declaration_or_fndef
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:2403
0x89af13 c_parser_external_declaration
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:1742
0x89b961 c_parser_translation_unit
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:1615
0x89b961 c_parse_file()
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:21653
0x8f213b c_common_parse_file()
	/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1186

Where flag_omit_frame_pointer is overwritten here based on USE_IX86_FRAME_POINTER aka -momit-leaf-frame-pointer:

   │1624              if (opts->x_optimize >= 1)│
   │1625                  SET_OPTION_IF_UNSET (opts, opts_set, flag_omit_frame_pointer,│
   │1626                                       !(USE_IX86_FRAME_POINTER || opts->x_optimize_size));│
  >│1627              if (opts->x_flag_asynchronous_unwind_tables == 2)│
   │1628                opts->x_flag_asynchronous_unwind_tables = !USE_IX86_FRAME_POINTER;│

flag_merge_constants is not optimization and is changed due to when we switch optimization level:
gcc/opts.c:    { OPT_LEVELS_1_PLUS, OPT_fmerge_constants, NULL, 1 },

I do not know why -free is changed:
gcc/common.opt:Common Report Var(flag_ree) Init(0)
Comment 5 Martin Liška 2019-12-11 14:47:16 UTC
param_min_crossjump_insns is changed here when we switch optimization level:

  if (opts->x_optimize_size)
    /* We want to crossjump as much as possible.  */
    SET_OPTION_IF_UNSET (opts, opts_set, param_min_crossjump_insns, 1);

Similarly for param_max_combine_insns:

  /* Restrict the amount of work combine does at -Og while retaining
     most of its useful transforms.  */
  if (opts->x_optimize_debug)
    SET_OPTION_IF_UNSET (opts, opts_set, param_max_combine_insns, 2);

likely here:

  /* -O2 param settings.  */
  opt2 = (opts->x_optimize >= 2);
...

  /* Track fields in field-sensitive alias analysis.  */
  if (opt2)
    SET_OPTION_IF_UNSET (opts, opts_set, param_max_fields_for_field_sensitive,
			 100);
Comment 6 Martin Liška 2019-12-11 14:49:46 UTC
And the last piece is this one:

  if (opts->x_optimize == 0)
    {
      /* Inlining does not work if not optimizing,
	 so force it not to be done.  */
      opts->x_warn_inline = 0;
      opts->x_flag_no_inline = 1;
    }

where warn_inline is not Optimization.
Comment 7 Martin Liška 2020-01-02 10:21:49 UTC
@Richi:

About the param_max_fields_for_field_sensitive:
Do I understand it correctly that the param is used in IPA PTA for global variables? If so, we can't easily use Optimization keyword as the param value will not make sense to be different for different functions.
Comment 8 Jan Hubicka 2020-01-02 14:04:24 UTC
> @Richi:
> 
> About the param_max_fields_for_field_sensitive:
> Do I understand it correctly that the param is used in IPA PTA for global
> variables? If so, we can't easily use Optimization keyword as the param value
> will not make sense to be different for different functions.
There is global var use_field_sensitive which IMO needs to go but
otherwise I think PTA should always analyze an assignment that is
withing some function. So it can always query the OPTIMIZATION node of
the function the statement lives in.

Honza
Comment 9 Martin Liška 2020-01-06 09:13:46 UTC
Author: marxin
Date: Mon Jan  6 09:13:15 2020
New Revision: 279895

URL: https://gcc.gnu.org/viewcvs?rev=279895&root=gcc&view=rev
Log:
Mark param_max_combine_insns with Optimization keyword.

    PR tree-optimization/92860
    * params.opt: Mark param_max_combine_insns with Optimization
    keyword. 


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/params.opt
Comment 10 Richard Biener 2020-01-07 08:17:11 UTC
(In reply to Jan Hubicka from comment #8)
> > @Richi:
> > 
> > About the param_max_fields_for_field_sensitive:
> > Do I understand it correctly that the param is used in IPA PTA for global
> > variables? If so, we can't easily use Optimization keyword as the param value
> > will not make sense to be different for different functions.
> There is global var use_field_sensitive which IMO needs to go but
> otherwise I think PTA should always analyze an assignment that is
> withing some function. So it can always query the OPTIMIZATION node of
> the function the statement lives in.

But it also affects global variables in IPA mode, and no, the effect doesn't
only materialize at stmts.  So for IPA the only thing we could do is
always use subfields for globals (but what max-fields-for-field-sensitive?)
and when analyzing stmts "pun" the fields.  And get rid of the
global use_field_sensitive flag and it's "optimization".  Ah, there's a FIXME
for globals with IPA PTA there.

That said, --param max-fields-for-field-sensitive is far from obvious to
make it per function (for IPA).  But mostly because of the effect for
'use_field_sensitive' which cannot be simply changed on/off if we actually
did end up with subfields for a variable.

I'd fear we introduce hard to track down correctness issues with "just"
flipping it to per-function.  Maybe splitting the param to a IPA and
non-IPA param works?  How do we handle other "true" IPA params considering
different TUs might be built with different settings of those as well?

> Honza
Comment 11 Martin Liška 2020-01-07 09:11:08 UTC
Author: marxin
Date: Tue Jan  7 09:10:37 2020
New Revision: 279945

URL: https://gcc.gnu.org/viewcvs?rev=279945&root=gcc&view=rev
Log:
Mark param_min_crossjump_insns with Optimization keyword.

2020-01-07  Martin Liska  <mliska@suse.cz>

    PR optimization/92860
    * params.opt: Mark param_min_crossjump_insns with Optimization
    keyword.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/params.opt
Comment 12 Martin Liška 2020-01-07 09:16:10 UTC
Author: marxin
Date: Tue Jan  7 09:15:38 2020
New Revision: 279947

URL: https://gcc.gnu.org/viewcvs?rev=279947&root=gcc&view=rev
Log:
Make warn_inline Optimization option.

2020-01-07  Martin Liska  <mliska@suse.cz>

	PR tree-optimization/92860
	* common.opt: Make in Optimization option
	as it is affected by -O0, which is an Optimization
	option.
	* tree-inline.c (tree_inlinable_function_p):
	Use opt_for_fn for warn_inline.
	(expand_call_inline): Likewise.
2020-01-07  Martin Liska  <mliska@suse.cz>

	PR tree-optimization/92860
	* gcc.dg/pr92860-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr92860-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/common.opt
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-inline.c
Comment 13 Jakub Jelinek 2020-03-04 09:34:40 UTC
GCC 8.4.0 has been released, adjusting target milestone.
Comment 14 Martin Liška 2020-03-17 17:06:39 UTC
There's another issue for ppc64le:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/attributes-3.c
Error: global_options are modified in local context:
  unroll_only_small_loops (0/1)
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/attributes-3.c:9:1: internal compiler error: in handle_optimize_attribute, at c-family/c-attribs.c:4464
    9 | extern void __attribute__((optimize ("O2"))) fn0 (void); /* { dg-warning "optimization attribute" } */
      | ^~~~~~
0xa98687 handle_optimize_attribute
	/home/marxin/Programming/gcc/gcc/c-family/c-attribs.c:4464
0x8e6dba decl_attributes(tree_node**, tree_node*, int, tree_node*)
	/home/marxin/Programming/gcc/gcc/attribs.c:713
0x8fc617 c_decl_attributes
	/home/marxin/Programming/gcc/gcc/c/c-decl.c:4977
0x8fcb61 start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
	/home/marxin/Programming/gcc/gcc/c/c-decl.c:5116
0x96c7d4 c_parser_declaration_or_fndef
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:2272
0x96b434 c_parser_external_declaration
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:1746
0x96af96 c_parser_translation_unit
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:1619
0x9a8e51 c_parse_file()
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:21710
0xa262f8 c_common_parse_file()
	/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1186
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Comment 15 Martin Liška 2020-03-18 10:57:59 UTC
(In reply to Martin Liška from comment #14)
> There's another issue for ppc64le:
> 
> $ ./xgcc -B.
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/attributes-3.c
> Error: global_options are modified in local context:
>   unroll_only_small_loops (0/1)
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/attributes-3.c:9:1:
> internal compiler error: in handle_optimize_attribute, at
> c-family/c-attribs.c:4464
>     9 | extern void __attribute__((optimize ("O2"))) fn0 (void); /* {
> dg-warning "optimization attribute" } */
>       | ^~~~~~
> 0xa98687 handle_optimize_attribute
> 	/home/marxin/Programming/gcc/gcc/c-family/c-attribs.c:4464
> 0x8e6dba decl_attributes(tree_node**, tree_node*, int, tree_node*)
> 	/home/marxin/Programming/gcc/gcc/attribs.c:713
> 0x8fc617 c_decl_attributes
> 	/home/marxin/Programming/gcc/gcc/c/c-decl.c:4977
> 0x8fcb61 start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
> 	/home/marxin/Programming/gcc/gcc/c/c-decl.c:5116
> 0x96c7d4 c_parser_declaration_or_fndef
> 	/home/marxin/Programming/gcc/gcc/c/c-parser.c:2272
> 0x96b434 c_parser_external_declaration
> 	/home/marxin/Programming/gcc/gcc/c/c-parser.c:1746
> 0x96af96 c_parser_translation_unit
> 	/home/marxin/Programming/gcc/gcc/c/c-parser.c:1619
> 0x9a8e51 c_parse_file()
> 	/home/marxin/Programming/gcc/gcc/c/c-parser.c:21710
> 0xa262f8 c_common_parse_file()
> 	/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1186
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

I've got a patch candidate for this particular issue. It can be fixed in a reasonable way.
Comment 16 Richard Biener 2020-04-01 08:08:30 UTC
Re-target to GCC 10, definitely not material for backporting unless we discover critical issues (that should be individually backported).  Eventually fully fixed only for GCC 11.
Comment 17 Jakub Jelinek 2020-05-07 11:56:22 UTC
GCC 10.1 has been released.
Comment 18 Martin Liška 2020-05-25 17:30:56 UTC
@egallager: Why did you add 'deferred' keyword? I sent a patch for it to GCC patches mailing list.
Comment 19 Eric Gallager 2020-05-29 18:27:10 UTC
(In reply to Martin Liška from comment #18)
> @egallager: Why did you add 'deferred' keyword? I sent a patch for it to GCC
> patches mailing list.

because:

(In reply to Richard Biener from comment #16)
> Re-target to GCC 10, definitely not material for backporting unless we
> discover critical issues (that should be individually backported). 
> Eventually fully fixed only for GCC 11.
Comment 20 Segher Boessenkool 2020-05-29 19:30:43 UTC
We are in stage 1 now (for GCC 11), so nothing should be deferred now.
Comment 21 Eric Gallager 2020-05-29 21:36:43 UTC
(In reply to Segher Boessenkool from comment #20)
> We are in stage 1 now (for GCC 11), so nothing should be deferred now.

I thought the "deferred" keyword was a backward-looking one, meant to mark bugs that had been deferred from previous releases and thus deserve a higher priority now, not ones that are currently being deferred to something in the future (that's what the SUSPENDED status is for). cc-ing David Malcolm who originally came up with the keyword
Comment 22 GCC Commits 2020-06-10 08:07:23 UTC
The master branch has been updated by Martin Liska <marxin@gcc.gnu.org>:

https://gcc.gnu.org/g:dc6d15eaa23cbae1468a6ef92371b1c856c14819

commit r11-1141-gdc6d15eaa23cbae1468a6ef92371b1c856c14819
Author: Martin Liska <mliska@suse.cz>
Date:   Tue Dec 10 19:41:08 2019 +0100

    Add gcc_assert that &global_options are not dirty modified.
    
    gcc/ChangeLog:
    
    2020-03-20  Martin Liska  <mliska@suse.cz>
    
            PR tree-optimization/92860
            * optc-save-gen.awk: Generate new function cl_optimization_compare.
            * opth-gen.awk: Generate declaration of the function.
    
    gcc/c-family/ChangeLog:
    
    2020-03-20  Martin Liska  <mliska@suse.cz>
    
            PR tree-optimization/92860
            * c-attribs.c (handle_optimize_attribute):
            Save global options and compare it after parsing of function
            attribute.
            * c-pragma.c (opt_stack::saved_global_options): New field.
            (handle_pragma_push_options): Save global_options.
            (handle_pragma_pop_options): Compare them after pop.
Comment 23 Martin Liška 2020-06-10 08:24:10 UTC
We've mitigated the majority of the collisions and I've added a sanitization checking. I'll keep the issue opened and I'm unassigning.
Comment 24 David Binderman 2020-06-11 10:19:45 UTC
Is this error message related ?

/home/dcb/gcc/results.20200611/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/xsaveoptintrin.h:55:9: internal compiler error: Error: global_options are modified in local context

   55 | #pragma GCC pop_options
      |         ^~~
0xe6fefe cl_optimization_compare(gcc_options*, gcc_options*)
	/home/dcb/gcc/working/gcc/options-save.c:0
0x97c7b9 handle_pragma_pop_options(cpp_reader*)
	../../trunk.git/gcc/c-family/c-pragma.c:1090
0x7a0565 cp_parser_pragma(cp_parser*, pragma_context, bool*)
	../../trunk.git/gcc/cp/parser.c:43983
0x79d432 cp_parser_toplevel_declaration(cp_parser*)
	../../trunk.git/gcc/cp/parser.c:13502

It seems to be a preprocessor crash, so I don't know how to reduce
the test case.
Comment 25 Martin Liška 2020-06-24 07:33:02 UTC
(In reply to David Binderman from comment #24)
> Is this error message related ?
> 
> /home/dcb/gcc/results.20200611/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/
> xsaveoptintrin.h:55:9: internal compiler error: Error: global_options are
> modified in local context
> 
>    55 | #pragma GCC pop_options
>       |         ^~~
> 0xe6fefe cl_optimization_compare(gcc_options*, gcc_options*)
> 	/home/dcb/gcc/working/gcc/options-save.c:0
> 0x97c7b9 handle_pragma_pop_options(cpp_reader*)
> 	../../trunk.git/gcc/c-family/c-pragma.c:1090
> 0x7a0565 cp_parser_pragma(cp_parser*, pragma_context, bool*)
> 	../../trunk.git/gcc/cp/parser.c:43983
> 0x79d432 cp_parser_toplevel_declaration(cp_parser*)
> 	../../trunk.git/gcc/cp/parser.c:13502
> 
> It seems to be a preprocessor crash, so I don't know how to reduce
> the test case.

Yes, it's definitely related.
Please attach -E file and a command line.
Comment 26 Martin Liška 2020-06-24 07:41:15 UTC
One more arc-linux case:

    { OPT_LEVELS_SIZE, OPT_mcase_vector_pcrel, NULL, 1 },
    { OPT_LEVELS_SIZE, OPT_msize_level_, NULL, 3 },
    { OPT_LEVELS_SIZE, OPT_mmillicode, NULL, 1 },
    { OPT_LEVELS_3_PLUS_SPEED_ONLY, OPT_msize_level_, NULL, 0 },
    { OPT_LEVELS_3_PLUS_SPEED_ONLY, OPT_malign_call, NULL, 1 },
Comment 27 David Binderman 2020-06-24 08:39:51 UTC
(In reply to Martin Liška from comment #25)
> Yes, it's definitely related.
> Please attach -E file and a command line.

Problem stills exists in the g++ compiler dated 20200623, but anything 
I do to reduce the problem makes it go away ;-<

Confirmation sought that the stack backtrace I provided shows
that the problem is a bug in the pre-processor. 

If so, -E isn't going to help.
Comment 28 Martin Liška 2020-06-24 08:42:58 UTC
> Confirmation sought that the stack backtrace I provided shows
> that the problem is a bug in the pre-processor.

No, the problem is in C parser.

> 
> If so, -E isn't going to help.

Please attach it.
Comment 29 David Binderman 2020-06-24 08:53:14 UTC
Maybe I've been slightly less than clear, but to quote myself:
>anything I do to reduce the problem makes it go away

So I can't provide a small test case, or output from -E, for this.

I suggest I wait until the rest of the bug is solved, retest
and go from there.

My apologies for the lack of clarity.
Comment 30 Martin Liška 2020-06-24 08:56:48 UTC
(In reply to David Binderman from comment #29)
> Maybe I've been slightly less than clear, but to quote myself:
> >anything I do to reduce the problem makes it go away

Ah, ok!

> 
> So I can't provide a small test case, or output from -E, for this.
> 
> I suggest I wait until the rest of the bug is solved, retest
> and go from there.
> 
> My apologies for the lack of clarity.

What's the project where you see the issue?
Comment 31 David Binderman 2020-06-24 09:27:47 UTC
(In reply to Martin Liška from comment #30)
> What's the project where you see the issue?

Chatterino2, in fedora rawhide.

Be warned, you will need my environment for gcc to see the problem.

More thought suggests that in a usual crash, I get a preprocessed
file, because I have -freport-bug switched on.

In this case, source code file gcc/options-save.c
explicitly calls routine internal_error, which doesn't produce a 
preprocessed file and so I cannot make progress.

I am busy with other stuff right now, but by the weekend, I should be
able to enhance routine internal_error to produce a preprocessed source
code file and so we can make progress.
Comment 32 Martin Liška 2020-06-24 09:29:05 UTC
> I am busy with other stuff right now, but by the weekend, I should be
> able to enhance routine internal_error to produce a preprocessed source
> code file and so we can make progress.

Thank you very much. I'll wait for a test-case by you ;)
Comment 33 David Binderman 2020-06-24 20:54:57 UTC
(In reply to Martin Liška from comment #32)
> Thank you very much. I'll wait for a test-case by you ;)

I have had a go, but I cannot generate an intermediate file.

I've tried various ways to get options-save.c to crash.
This is my most recent effort:

struct S {
    int a;
    int b;
};

void
cl_optimization_compare (gcc_options *ptr1, gcc_options *ptr2)
{
  if (ptr1->x_help_flag != ptr2->x_help_flag) {
    S * p = 0;
    fprintf( stderr, "%d\n", p->a);
    internal_error ("%<global_options%> are modified in local context");
  }

I also tried integer division by zero, which didn't seem to work.

If anyone has any better ideas on generating a crash, I would be glad 
to hear about them.
Comment 34 Martin Liška 2020-06-25 06:31:52 UTC
I don't have to do anything special in order to get pre-processed source file:

$ gcc pr88876.c -freport-bug 
pr88876.c:10:1: internal compiler error: ‘global_options’ are modified in local context
   10 | int c() {return 0;}
      | ^~~
0xce038b cl_optimization_compare(gcc_options*, gcc_options*)
	/dev/shm/objdir/gcc/options-save.c:9822
0x8c4f88 handle_optimize_attribute
	/home/marxin/Programming/gcc/gcc/c-family/c-attribs.c:4475
0x7d4ee7 decl_attributes(tree_node**, tree_node*, int, tree_node*)
	/home/marxin/Programming/gcc/gcc/attribs.c:714
0x7f1625 start_function(c_declspecs*, c_declarator*, tree_node*)
	/home/marxin/Programming/gcc/gcc/c/c-decl.c:9177
0x84bdb7 c_parser_declaration_or_fndef
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:2434
0x855453 c_parser_external_declaration
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:1773
0x855f51 c_parser_translation_unit
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:1646
0x855f51 c_parse_file()
	/home/marxin/Programming/gcc/gcc/c/c-parser.c:21822
0x8ae88b c_common_parse_file()
	/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Preprocessed source stored into /tmp/cc8jx9U7.out file, please attach this to your bugreport.
Comment 35 Martin Liška 2020-06-25 06:32:41 UTC
Btw. can you run the failing compilation in gdb and list where exactly it fails (which option name is different)?
Comment 36 David Binderman 2020-06-25 06:54:10 UTC
(In reply to Martin Liška from comment #35)
> Btw. can you run the failing compilation in gdb and list where exactly it
> fails (which option name is different)?

Shown previous runs indicate the first test in routine cl_optimization_compare.
So field x_help_flag.
Comment 37 Martin Liška 2020-06-25 06:59:50 UTC
Which is quite strange difference.
Comment 38 Arseny Solokha 2020-07-06 04:09:54 UTC
JFTR I can easily reproduce it e.g. in the following setup:

% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mcpu=power9 -c gcc/testsuite/gcc.target/s390/target-attribute/tpragma-struct-vx-1.c
gcc/testsuite/gcc.target/s390/target-attribute/tpragma-struct-vx-1.c:10:9: error: #pragma GCC target 'arch=z13' is invalid
   10 | #pragma GCC target ("arch=z13,vx")
      |         ^~~
gcc/testsuite/gcc.target/s390/target-attribute/tpragma-struct-vx-1.c:10:9: error: #pragma GCC target 'vx' is invalid
gcc/testsuite/gcc.target/s390/target-attribute/tpragma-struct-vx-1.c:23:9: internal compiler error: 'global_options' are modified in local context
   23 | #pragma GCC pop_options
      |         ^~~
0xd89fc5 cl_optimization_compare(gcc_options*, gcc_options*)
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/build/gcc/options-save.c:10459
0x9196b6 handle_pragma_pop_options
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/c-family/c-pragma.c:1090
0x895510 c_parser_pragma
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/c/c-parser.c:12544
0x8b7c75 c_parser_external_declaration
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/c/c-parser.c:1754
0x8b82b1 c_parser_translation_unit
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/c/c-parser.c:1646
0x8b82b1 c_parse_file()
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/c/c-parser.c:21822
0x916cb7 c_common_parse_file()
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/c-family/c-opts.c:1190
Comment 39 Martin Liška 2020-07-07 07:21:14 UTC
(In reply to Arseny Solokha from comment #38)
> JFTR I can easily reproduce it e.g. in the following setup:
> 
> % powerpc-e300c3-linux-gnu-gcc-11.0.0 -mcpu=power9 -c
> gcc/testsuite/gcc.target/s390/target-attribute/tpragma-struct-vx-1.c
> gcc/testsuite/gcc.target/s390/target-attribute/tpragma-struct-vx-1.c:10:9:
> error: #pragma GCC target 'arch=z13' is invalid
>    10 | #pragma GCC target ("arch=z13,vx")
>       |         ^~~
> gcc/testsuite/gcc.target/s390/target-attribute/tpragma-struct-vx-1.c:10:9:
> error: #pragma GCC target 'vx' is invalid
> gcc/testsuite/gcc.target/s390/target-attribute/tpragma-struct-vx-1.c:23:9:
> internal compiler error: 'global_options' are modified in local context
>    23 | #pragma GCC pop_options
>       |         ^~~
> 0xd89fc5 cl_optimization_compare(gcc_options*, gcc_options*)
> 	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/
> work/build/gcc/options-save.c:10459
> 0x9196b6 handle_pragma_pop_options
> 	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/
> work/gcc-11-20200705/gcc/c-family/c-pragma.c:1090
> 0x895510 c_parser_pragma
> 	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/
> work/gcc-11-20200705/gcc/c/c-parser.c:12544
> 0x8b7c75 c_parser_external_declaration
> 	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/
> work/gcc-11-20200705/gcc/c/c-parser.c:1754
> 0x8b82b1 c_parser_translation_unit
> 	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/
> work/gcc-11-20200705/gcc/c/c-parser.c:1646
> 0x8b82b1 c_parse_file()
> 	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/
> work/gcc-11-20200705/gcc/c/c-parser.c:21822
> 0x916cb7 c_common_parse_file()
> 	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/
> work/gcc-11-20200705/gcc/c-family/c-opts.c:1190

Thank you for the test-case, but it's not much useful, it's an ice-on-invalid code.

Fails due to:
(gdb) p ptr1->x_rs6000_cpu_index
$1 = 51
(gdb) p ptr2->x_rs6000_cpu_index
$2 = -1
Comment 40 Richard Biener 2020-07-23 06:51:56 UTC
GCC 10.2 is released, adjusting target milestone.
Comment 41 Martin Liška 2020-12-11 10:30:33 UTC
I'm planning to work on that for GCC 12.
Comment 42 GCC Commits 2021-05-25 12:57:20 UTC
The master branch has been updated by Martin Liska <marxin@gcc.gnu.org>:

https://gcc.gnu.org/g:ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e

commit r12-1039-gebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e
Author: Martin Liska <mliska@suse.cz>
Date:   Wed Mar 10 15:12:31 2021 +0100

    Improve global state for options.
    
    gcc/c-family/ChangeLog:
    
            PR tree-optimization/92860
            PR target/99592
            * c-attribs.c (handle_optimize_attribute): Save target node
            before calling parse_optimize_options and save it in case
            it changes.
            * c-pragma.c (handle_pragma_target): Similarly for pragma.
            (handle_pragma_pop_options): Likewise here.
    
    gcc/ChangeLog:
    
            PR tree-optimization/92860
            PR target/99592
            * optc-save-gen.awk: Remove exceptions.
Comment 43 David Binderman 2021-07-01 08:54:15 UTC
Rebroken, this time during bootstrap, so much more serious.

/home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/ -B/home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/bin/ -B/home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/lib/ -isystem /home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/include -isystem /home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -g -O3 -march=native -O2  -g -O3 -march=native -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../trunk.git/libgcc -I../../../trunk.git/libgcc/. -I../../../trunk.git/libgcc/../gcc -I../../../trunk.git/libgcc/../include -I../../../trunk.git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o _cmpdi2_s.o -MT _cmpdi2_s.o -MD -MP -MF _cmpdi2_s.dep -DSHARED -DL_cmpdi2 -c ../../../trunk.git/libgcc/libgcc2.c
In file included from /home/dcb/gcc/working/gcc/include/x86gprintrin.h:37,
                 from ../../../trunk.git/libgcc/config/i386/shadow-stack-unwind.h:25,
                 from ./md-unwind-support.h:27,
                 from ../../../trunk.git/libgcc/unwind-dw2.c:412:
/home/dcb/gcc/working/gcc/include/bmi2intrin.h:106:9: internal compiler error: ‘global_options’ are modified in local context
  106 | #pragma GCC pop_options
      |         ^~~

Configure lines are:

../trunk.git/configure --prefix=/home/dcb/gcc/$PREFIX \
	--disable-multilib \
	--disable-werror \
	--with-pkgversion=$HASH \
	--enable-checking=df,extra,fold,rtl,yes \
 	--enable-languages=c,c++,fortran,d,go

sed 's/-O2/-O3 -march=native/' < Makefile > Makefile.tmp
diff Makefile Makefile.tmp
mv Makefile.tmp Makefile

I'll have a go at dropping the -O3 -march=native back downto
-O2 and see what happens.
Comment 44 Martin Liška 2021-07-01 09:11:44 UTC
(In reply to David Binderman from comment #43)
> Rebroken, this time during bootstrap, so much more serious.
> 
> /home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/
> -B/home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/bin/
> -B/home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/lib/ -isystem
> /home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/include -isystem
> /home/dcb/gcc/results.20210701/x86_64-pc-linux-gnu/sys-include  
> -fchecking=1 -g -O3 -march=native -O2  -g -O3 -march=native -DIN_GCC    -W
> -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
> -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag
> -Wold-style-definition  -isystem ./include  -fpic -mlong-double-80
> -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc
> -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
> -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../trunk.git/libgcc
> -I../../../trunk.git/libgcc/. -I../../../trunk.git/libgcc/../gcc
> -I../../../trunk.git/libgcc/../include
> -I../../../trunk.git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
> -DHAVE_CC_TLS  -DUSE_TLS -o _cmpdi2_s.o -MT _cmpdi2_s.o -MD -MP -MF
> _cmpdi2_s.dep -DSHARED -DL_cmpdi2 -c ../../../trunk.git/libgcc/libgcc2.c
> In file included from /home/dcb/gcc/working/gcc/include/x86gprintrin.h:37,
>                  from
> ../../../trunk.git/libgcc/config/i386/shadow-stack-unwind.h:25,
>                  from ./md-unwind-support.h:27,
>                  from ../../../trunk.git/libgcc/unwind-dw2.c:412:
> /home/dcb/gcc/working/gcc/include/bmi2intrin.h:106:9: internal compiler
> error: ‘global_options’ are modified in local context
>   106 | #pragma GCC pop_options
>       |         ^~~
> 
> Configure lines are:
> 
> ../trunk.git/configure --prefix=/home/dcb/gcc/$PREFIX \
> 	--disable-multilib \
> 	--disable-werror \
> 	--with-pkgversion=$HASH \
> 	--enable-checking=df,extra,fold,rtl,yes \
>  	--enable-languages=c,c++,fortran,d,go
> 
> sed 's/-O2/-O3 -march=native/' < Makefile > Makefile.tmp
> diff Makefile Makefile.tmp
> mv Makefile.tmp Makefile
> 
> I'll have a go at dropping the -O3 -march=native back downto
> -O2 and see what happens.

What CPU do you have? What -march=native expands to (-v argument). Can you please attach the pre-processed source file.
Comment 45 David Binderman 2021-07-01 14:11:03 UTC
(In reply to Martin Liška from comment #44)
> What CPU do you have? 

AMD FX-8350. 

> What -march=native expands to (-v argument). 

bdver2

> Can you please attach the pre-processed source file.

 I'll let you know when I have it again.
Comment 46 David Binderman 2021-07-01 15:38:32 UTC
(In reply to David Binderman from comment #43)
> Rebroken, this time during bootstrap, so much more serious.

> I'll have a go at dropping the -O3 -march=native back downto
> -O2 and see what happens.

-O2 fine. I'll try -O3 without the -march=native.
Comment 47 David Binderman 2021-07-01 17:45:23 UTC
(In reply to David Binderman from comment #46)
> (In reply to David Binderman from comment #43)
> > Rebroken, this time during bootstrap, so much more serious.
> 
> > I'll have a go at dropping the -O3 -march=native back downto
> > -O2 and see what happens.
> 
> -O2 fine. I'll try -O3 without the -march=native.

-O3 fine. Looks like an march=bdver2 issue.
Comment 48 Martin Liška 2021-07-01 18:51:23 UTC
> -O3 fine. Looks like an march=bdver2 issue.

All right, so please attach me here the pre-processed source file. I tried doing that myself (using -O3 -march=bdver2), but it was fine (for some reason).
Comment 49 David Binderman 2021-07-01 19:34:27 UTC
Created attachment 51095 [details]
C source code

Command line is

/home/dcb/gcc/working/./gcc/xgcc  -B/home/dcb/gcc/working/./gcc/  -g -O3 -march
=bdver2 -c bug734.c

and the reduced version of the code is

$ more bug734.c
#pragma GCC push_options
#pragma GCC pop_options
$
Comment 50 Martin Liška 2021-07-02 04:16:39 UTC
(In reply to David Binderman from comment #49)
> Created attachment 51095 [details]
> C source code
> 
> Command line is
> 
> /home/dcb/gcc/working/./gcc/xgcc  -B/home/dcb/gcc/working/./gcc/  -g -O3
> -march
> =bdver2 -c bug734.c
> 
> and the reduced version of the code is
> 
> $ more bug734.c
> #pragma GCC push_options
> #pragma GCC pop_options
> $

Thanks for it. For some reason, I can't still reproduce it. Please provide the output of -v option here.
Comment 51 David Binderman 2021-07-02 06:30:44 UTC
(In reply to Martin Liška from comment #50)
> Thanks for it. For some reason, I can't still reproduce it. Please provide
> the output of -v option here.

Reading specs from /home/dcb/gcc/working/./gcc/specs
COLLECT_GCC=/home/dcb/gcc/working/./gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.git/configure --prefix=/home/dcb/gcc/results.20210701 --disable-multilib --disable-werror --with-pkgversion=91c771ec8a3b6497 --enable-checking=df,extra,fold,rtl,yes --enabl
e-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210701 (experimental) (91c771ec8a3b6497) 
COLLECT_GCC_OPTIONS='-B' '/home/dcb/gcc/working/./gcc/' '-g' '-O3' '-march=bdver2' '-c' '-v'
 /home/dcb/gcc/working/./gcc/cc1 -quiet -v -iprefix /home/dcb/gcc/working/gcc/../lib/gcc/x86_64-pc-linux-gnu/12.0.0/ -isystem /home/dcb/gcc/working/./gcc/include -isystem /home/dcb/gcc/working/./gcc
/include-fixed bug734.c -quiet -dumpbase bug734.c -dumpbase-ext .c -march=bdver2 -g -O3 -version -o /tmp/ccfZi8wx.s
GNU C17 (91c771ec8a3b6497) version 12.0.0 20210701 (experimental) (x86_64-pc-linux-gnu)
	compiled by GNU C version 12.0.0 20210701 (experimental), GMP version 6.2.0, MPFR version 4.1.0-p11, MPC version 1.2.1, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/home/dcb/gcc/working/gcc/../lib/gcc/x86_64-pc-linux-gnu/12.0.0/include"
ignoring nonexistent directory "/home/dcb/gcc/working/gcc/../lib/gcc/x86_64-pc-linux-gnu/12.0.0/include-fixed"
ignoring nonexistent directory "/home/dcb/gcc/working/gcc/../lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../x86_64-pc-linux-gnu/include"
ignoring nonexistent directory "/home/dcb/gcc/working/gcc/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.0.0/include"
ignoring nonexistent directory "/home/dcb/gcc/working/gcc/../lib/gcc/../../include"
ignoring nonexistent directory "/home/dcb/gcc/working/gcc/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.0.0/include-fixed"
ignoring nonexistent directory "/home/dcb/gcc/working/gcc/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/dcb/gcc/working/./gcc/include
 /home/dcb/gcc/working/./gcc/include-fixed
 /usr/local/include
 /usr/include
End of search list.
GNU C17 (91c771ec8a3b6497) version 12.0.0 20210701 (experimental) (x86_64-pc-linux-gnu)
	compiled by GNU C version 12.0.0 20210701 (experimental), GMP version 6.2.0, MPFR version 4.1.0-p11, MPC version 1.2.1, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 9c0329e4bed137a737d23c2332823956
bug734.c:2:9: internal compiler error: ‘global_options’ are modified in local context
    2 | #pragma GCC pop_options
      |         ^~~
0xe8f7c3 cl_optimization_compare(gcc_options*, gcc_options*)
	/home/dcb/gcc/working/gcc/options-save.c:13033
0x9b0ebd handle_pragma_pop_options
	../../trunk.git/gcc/c-family/c-pragma.c:1102
Comment 52 Martin Liška 2021-07-02 07:04:09 UTC
>     2 | #pragma GCC pop_options
>       |         ^~~
> 0xe8f7c3 cl_optimization_compare(gcc_options*, gcc_options*)
> 	/home/dcb/gcc/working/gcc/options-save.c:13033
> 0x9b0ebd handle_pragma_pop_options
> 	../../trunk.git/gcc/c-family/c-pragma.c:1102

Thanks. Hm, still can't reproduce. Can please show me content at gcc/options-save.c:13033 and lines around it?
Comment 53 David Binderman 2021-07-02 07:12:14 UTC
(In reply to Martin Liška from comment #52)
> >     2 | #pragma GCC pop_options
> >       |         ^~~
> > 0xe8f7c3 cl_optimization_compare(gcc_options*, gcc_options*)
> > 	/home/dcb/gcc/working/gcc/options-save.c:13033
> > 0x9b0ebd handle_pragma_pop_options
> > 	../../trunk.git/gcc/c-family/c-pragma.c:1102
> 
> Thanks. Hm, still can't reproduce. Can please show me content at
> gcc/options-save.c:13033 and lines around it?

void
cl_optimization_compare (gcc_options *ptr1, gcc_options *ptr2)
{
  if (ptr1->x_help_flag != ptr2->x_help_flag)
    internal_error ("%<global_options%> are modified in local context");
  if (ptr1->x_no_sysroot_suffix != ptr2->x_no_sysroot_suffix)
    internal_error ("%<global_options%> are modified in local context");
  if (ptr1->x_param_align_loop_iterations != ptr2->x_param_align_loop_iterations)
    internal_error ("%<global_options%> are modified in local context");
  if (ptr1->x_param_align_threshold != ptr2->x_param_align_threshold)
    internal_error ("%<global_options%> are modified in local context");
Comment 54 Martin Liška 2021-07-02 07:18:21 UTC
(In reply to David Binderman from comment #53)
> (In reply to Martin Liška from comment #52)
> > >     2 | #pragma GCC pop_options
> > >       |         ^~~
> > > 0xe8f7c3 cl_optimization_compare(gcc_options*, gcc_options*)
> > > 	/home/dcb/gcc/working/gcc/options-save.c:13033
> > > 0x9b0ebd handle_pragma_pop_options
> > > 	../../trunk.git/gcc/c-family/c-pragma.c:1102
> > 
> > Thanks. Hm, still can't reproduce. Can please show me content at
> > gcc/options-save.c:13033 and lines around it?
> 
> void
> cl_optimization_compare (gcc_options *ptr1, gcc_options *ptr2)
> {
>   if (ptr1->x_help_flag != ptr2->x_help_flag)
>     internal_error ("%<global_options%> are modified in local context");
>   if (ptr1->x_no_sysroot_suffix != ptr2->x_no_sysroot_suffix)
>     internal_error ("%<global_options%> are modified in local context");
>   if (ptr1->x_param_align_loop_iterations !=
> ptr2->x_param_align_loop_iterations)
>     internal_error ("%<global_options%> are modified in local context");
>   if (ptr1->x_param_align_threshold != ptr2->x_param_align_threshold)
>     internal_error ("%<global_options%> are modified in local context");

with line numbers please :)
Comment 55 Martin Liška 2021-07-02 07:20:39 UTC
> 
> with line numbers please :)

cat -n can do that
Comment 56 David Binderman 2021-07-02 07:35:23 UTC
(In reply to Martin Liška from comment #55)
> > 
> > with line numbers please :)
> 
> cat -n can do that

Sorry, I went a bit hard-of-thinking there. 

 13029  void
 13030  cl_optimization_compare (gcc_options *ptr1, gcc_options *ptr2)
 13031  {
 13032    if (ptr1->x_help_flag != ptr2->x_help_flag)
 13033      internal_error ("%<global_options%> are modified in local context");
 13034    if (ptr1->x_no_sysroot_suffix != ptr2->x_no_sysroot_suffix)
 13035      internal_error ("%<global_options%> are modified in local context");
 13036    if (ptr1->x_param_align_loop_iterations != ptr2->x_param_align_loop_iterations)
 13037      internal_error ("%<global_options%> are modified in local context");
 13038    if (ptr1->x_param_align_threshold != ptr2->x_param_align_threshold)
 13039      internal_error ("%<global_options%> are modified in local context");
 13040    if (ptr1->x_param_analyzer_bb_explosion_factor != ptr2->x_param_analyzer_bb_explosion_factor)
 13041      internal_error ("%<global_options%> are modified in local context");
 13042    if (ptr1->x_param_analyzer_max_constraints != ptr2->x_param_analyzer_max_constraints)
 13043      internal_error ("%<global_options%> are modified in local context");

So the first test is failing.
Comment 57 Martin Liška 2021-07-02 07:48:30 UTC
(In reply to David Binderman from comment #56)
> (In reply to Martin Liška from comment #55)
> > > 
> > > with line numbers please :)
> > 
> > cat -n can do that
> 
> Sorry, I went a bit hard-of-thinking there. 
> 
>  13029  void
>  13030  cl_optimization_compare (gcc_options *ptr1, gcc_options *ptr2)
>  13031  {
>  13032    if (ptr1->x_help_flag != ptr2->x_help_flag)
>  13033      internal_error ("%<global_options%> are modified in local
> context");
>  13034    if (ptr1->x_no_sysroot_suffix != ptr2->x_no_sysroot_suffix)
>  13035      internal_error ("%<global_options%> are modified in local
> context");
>  13036    if (ptr1->x_param_align_loop_iterations !=
> ptr2->x_param_align_loop_iterations)
>  13037      internal_error ("%<global_options%> are modified in local
> context");
>  13038    if (ptr1->x_param_align_threshold != ptr2->x_param_align_threshold)
>  13039      internal_error ("%<global_options%> are modified in local
> context");
>  13040    if (ptr1->x_param_analyzer_bb_explosion_factor !=
> ptr2->x_param_analyzer_bb_explosion_factor)
>  13041      internal_error ("%<global_options%> are modified in local
> context");
>  13042    if (ptr1->x_param_analyzer_max_constraints !=
> ptr2->x_param_analyzer_max_constraints)
>  13043      internal_error ("%<global_options%> are modified in local
> context");
> 
> So the first test is failing.

Hm, that's super-weird. It should be 0 for both of them. Can you please build options-save.c with -O0 and debug it:

(gdb) b cl_optimization_compare
(gdb) p ptr1->x_help_flag
$1 = 0
(gdb) p ptr2->x_help_flag
$2 = 0

and then put a watch for the value that is non-zero:
(gdb) p &ptr1->x_help_flag
$3 = (int *) 0x26c87d0
(gdb) watch *$3
Hardware watchpoint 4: *$3
(gdb) r
Old value = <unreadable>
New value = 0
handle_pragma_push_options (dummy=<optimized out>) at /home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:1041
1041	      *p->saved_global_options = global_options;
(gdb) c
Comment 58 David Binderman 2021-07-02 20:16:33 UTC
(In reply to Martin Liška from comment #57)
> Can you please build options-save.c with -O0 and debug it:

Good idea, but I have run out of time on this issue. 
Another 40 or so interesting commits have appeared
in gcc trunk.

It only seems to affect bdver2 and you've had multiple failures
to reproduce, so I am happy to put this one on hold for a week.

I plan to do another full -O3 -march=native bootstrap in a week.
I will look into this problem then.

I am happy for someone else to pick this one up. Sorry I can't do more,
but then that's the nature of volunteer work.
Comment 59 Martin Liška 2021-12-09 14:02:51 UTC
Most of the issues were fixed in GCC 12 stage1.
There are still corner cases, but the current situation should be much better.
Comment 60 David Binderman 2021-12-09 18:46:15 UTC
(In reply to Martin Liška from comment #59)
> Most of the issues were fixed in GCC 12 stage1.
> There are still corner cases, but the current situation should be much
> better.

Not for me, they aren't. 

I can reproduce it on today's trunk, but any *.i file I produce seems to 
compile fine ;-<

I will attach the *.i file and the command line.
Comment 61 David Binderman 2021-12-09 18:48:23 UTC
Created attachment 51964 [details]
C source code

Command line used to compile file:

/home/dcb/gcc/working.2/./gcc/xgcc -B/home/dcb/gcc/working.2/./gcc/ -B/home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/bin/ -B/home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/lib/ -isystem /home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/include -isystem /home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -g -O3 -march=native -O2  -g -O3 -march=native -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../trunk.git/libgcc -I../../../trunk.git/libgcc/. -I../../../trunk.git/libgcc/../gcc -I../../../trunk.git/libgcc/../include -I../../../trunk.git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS  -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c ../../../trunk.git/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS
Comment 62 Martin Liška 2021-12-10 09:09:09 UTC
(In reply to David Binderman from comment #61)
> Created attachment 51964 [details]
> C source code
> 
> Command line used to compile file:
> 
> /home/dcb/gcc/working.2/./gcc/xgcc -B/home/dcb/gcc/working.2/./gcc/
> -B/home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/bin/
> -B/home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/lib/ -isystem
> /home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/include -isystem
> /home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/sys-include  
> -fchecking=1 -g -O3 -march=native -O2  -g -O3 -march=native -DIN_GCC    -W
> -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
> -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag
> -Wold-style-definition  -isystem ./include  -fpic -mlong-double-80
> -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc
> -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
> -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../trunk.git/libgcc
> -I../../../trunk.git/libgcc/. -I../../../trunk.git/libgcc/../gcc
> -I../../../trunk.git/libgcc/../include
> -I../../../trunk.git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
> -DHAVE_CC_TLS  -DUSE_TLS  -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF
> unwind-dw2.dep -fexceptions -c ../../../trunk.git/libgcc/unwind-dw2.c
> -fvisibility=hidden -DHIDE_EXPORTS

Can't reproduce with the current master:

./xgcc -B. /home/marxin/Programming/testcases/pr92860.c -g -O3 -march=bdver2 -fchecking=1 -g -O3 -march=native -O2  -g -O3 -march=native -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../trunk.git/libgcc -I../../../trunk.git/libgcc/. -I../../../trunk.git/libgcc/../gcc -I../../../trunk.git/libgcc/../include -I../../../trunk.git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS  -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c
Comment 63 David Binderman 2021-12-11 21:15:58 UTC
(In reply to Martin Liška from comment #62)
> Can't reproduce with the current master:

Righto. This is proving unexpectedly hard to reproduce.

EITHER: I search various values of march= to find out which
ones work and which ones don't.

OR: I do a fishing trip for revisions some unknown time before
2020-06-11 (the known bad date), to find a known good date, then
run git bisect from there.

In furtherance of option 2 and given that Jun 2020 is long enough
ago that the git rev-list will have expired (it is only valid for 90 days),
am I correct in thinking that something like

git rev-list -n 1 --first-parent --before="2020-01-01" master

will give me a git hash of a revision of the first day of year 2020
and so

git checkout `that git hash`

will get me to that date, so I can run a build ?
Comment 64 David Binderman 2021-12-11 22:24:34 UTC
(In reply to David Binderman from comment #63)
> (In reply to Martin Liška from comment #62)
> > Can't reproduce with the current master:
> 
> Righto. This is proving unexpectedly hard to reproduce.
> 
> EITHER: I search various values of march= to find out which
> ones work and which ones don't.

Works fine with -march=amdfam10, broken with -march=bdver2.

I have no idea how to work out the halfway point between these two architectures.
Comment 65 David Binderman 2021-12-12 12:52:11 UTC
(In reply to David Binderman from comment #63)
> OR: I do a fishing trip for revisions some unknown time before
> 2020-06-11 (the known bad date), to find a known good date, then
> run git bisect from there.
> 
> In furtherance of option 2 and given that Jun 2020 is long enough
> ago that the git rev-list will have expired (it is only valid for 90 days),
> am I correct in thinking that something like
> 
> git rev-list -n 1 --first-parent --before="2020-01-01" master
> 
> will give me a git hash of a revision of the first day of year 2020
> and so
> 
> git checkout `that git hash`
> 
> will get me to that date, so I can run a build ?

Yes, those git commands seem to successfully get me backwards
and forwards on the git timeline, but I am struggling to get anything
to build. I've tried:

2020-04-11 : f883c46b4877f637e0fa5025b4d6b5c9040ec566 good ? cyclades problems
2020-05-11 : dbeaa7ab81a37acadc9af6e7990332604252de20 failed to build
2020-06-11 : 419c355c7a871513e1065b7cec32dd456eb4a0e5 failed to build
2020-07-11 : c19f95fb1b8f15090eb1d1682e86de425fbd3c78 failed to build
2020-08-11 : 1118a3ff9d3ad6a64bba25dc01e7703325e23d92 failed to build
2020-09-11 : 8d3767c30240c901a493d82d9d20f306b2f0152d failed to build

where column 1 is a date, column 3 is the git hash and column 4
indicates that I could only build one of the versions I tried,
from Apr 2021, and that was questionable, because of problems
with cyclades header files. I had to use make -k in the end.

Most of the rest stopped with this error message:

/usr/include/stdio.h:183:3: error: wrong number of arguments specified for ‘malloc’ attribute
/usr/include/stdio.h:183:3: error: wrong number of arguments specified for ‘malloc’ attribute
/usr/include/stdio.h:183:3: error: wrong number of arguments specified for ‘malloc’ attribute
/usr/include/stdio.h:195:4: error: wrong number of arguments specified for ‘malloc’ attribute

I don't know how to fix that.

Given the copious activity and lack of progress on this bug report, I would
be happy for it to be closed down as "cannot reproduce".
Comment 66 Arseny Solokha 2021-12-13 06:28:48 UTC
Should I file my commend 38 as a separate PR, then?
Comment 67 Martin Liška 2021-12-13 10:04:43 UTC
(In reply to Arseny Solokha from comment #66)
> Should I file my commend 38 as a separate PR, then?

Yes, please.
Comment 68 Martin Liška 2021-12-13 10:05:11 UTC
> Righto. This is proving unexpectedly hard to reproduce.

Ok, so please tell me exact steps how to reproduce it.
Comment 69 David Binderman 2021-12-13 10:14:13 UTC
(In reply to Martin Liška from comment #68)
> > Righto. This is proving unexpectedly hard to reproduce.
> 
> Ok, so please tell me exact steps how to reproduce it.

First of all, get a -march=bdver2 machine. Install Fedora Linux.
Get recent gcc trunk.

Use this configure command:

../trunk.git/configure \
        --disable-multilib \
        --disable-werror \
        --enable-checking=df,extra,fold,rtl,yes \
        --enable-languages=c,c++

sed 's/-O2/-O3 -march=native/' < Makefile > Makefile.tmp
diff Makefile Makefile.tmp
mv Makefile.tmp Makefile

Build it and see what happens. I suspect that you won't need all the checking
flags I use. 

I also suspect that the recent fix for bug # 103515 might affect the
results, but let's see.
Comment 70 Martin Liška 2021-12-13 12:52:49 UTC
I'm sorry, but I don't have an access to a bdver2 machine.
Anyway, can you please debug what I asked in #c57?
Comment 71 David Binderman 2021-12-14 09:35:29 UTC
(In reply to Martin Liška from comment #57)
> (In reply to David Binderman from comment #56)
> > (In reply to Martin Liška from comment #55)
> > > > 
> > > > with line numbers please :)
> > > 
> > > cat -n can do that
> > 
> > Sorry, I went a bit hard-of-thinking there. 
> > 
> >  13029  void
> >  13030  cl_optimization_compare (gcc_options *ptr1, gcc_options *ptr2)
> >  13031  {
> >  13032    if (ptr1->x_help_flag != ptr2->x_help_flag)
> >  13033      internal_error ("%<global_options%> are modified in local
> > context");
> >  13034    if (ptr1->x_no_sysroot_suffix != ptr2->x_no_sysroot_suffix)
> >  13035      internal_error ("%<global_options%> are modified in local
> > context");
> >  13036    if (ptr1->x_param_align_loop_iterations !=
> > ptr2->x_param_align_loop_iterations)
> >  13037      internal_error ("%<global_options%> are modified in local
> > context");
> >  13038    if (ptr1->x_param_align_threshold != ptr2->x_param_align_threshold)
> >  13039      internal_error ("%<global_options%> are modified in local
> > context");
> >  13040    if (ptr1->x_param_analyzer_bb_explosion_factor !=
> > ptr2->x_param_analyzer_bb_explosion_factor)
> >  13041      internal_error ("%<global_options%> are modified in local
> > context");
> >  13042    if (ptr1->x_param_analyzer_max_constraints !=
> > ptr2->x_param_analyzer_max_constraints)
> >  13043      internal_error ("%<global_options%> are modified in local
> > context");
> > 
> > So the first test is failing.
> 
> Hm, that's super-weird. It should be 0 for both of them. Can you please
> build options-save.c with -O0 and debug it:
> 
> (gdb) b cl_optimization_compare
> (gdb) p ptr1->x_help_flag
> $1 = 0
> (gdb) p ptr2->x_help_flag
> $2 = 0
> 
> and then put a watch for the value that is non-zero:
> (gdb) p &ptr1->x_help_flag
> $3 = (int *) 0x26c87d0
> (gdb) watch *$3
> Hardware watchpoint 4: *$3
> (gdb) r
> Old value = <unreadable>
> New value = 0
> handle_pragma_push_options (dummy=<optimized out>) at
> /home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:1041
> 1041	      *p->saved_global_options = global_options;
> (gdb) c

I think I understand most of your instructions, although it's decades
since I played with gdb.

Stack backtrace gives me:

(gdb) bt
#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:262
#1  0x00007ffff76d815b in _int_realloc (
    av=av@entry=0x7ffff7835aa0 <main_arena>, oldp=oldp@entry=0x2e75f10, 
    oldsize=14624, nb=nb@entry=21920) at malloc.c:4786
#2  0x00007ffff76d8f49 in __GI___libc_realloc (oldmem=0x2e75f20, bytes=21912)
    at malloc.c:3372
#3  0x0000000001e09e0e in xrealloc (oldmem=0x2e7bc70, size=21912)
    at ../../trunk.git/libiberty/xmalloc.c:181
#4  0x00000000007b91dd in va_heap::reserve<finalizer> (v=<optimized out>, 
    reserve=<optimized out>, exact=<optimized out>)
    at ../../trunk.git/gcc/vec.h:290
#5  vec<finalizer, va_heap, vl_ptr>::reserve (this=0x2df6ca8, nelems=1, 
    exact=false) at ../../trunk.git/gcc/vec.h:1858
#6  vec<finalizer, va_heap, vl_ptr>::safe_push (this=0x2df6ca8, obj=...)
    at ../../trunk.git/gcc/vec.h:1967
#7  0x00000000007b65a4 in add_finalizer (result=0x7fffe9f75270, 
    f=0x691dc0 <finalize<c_binding>(void*)>, s=0, n=1)
    at ../../trunk.git/gcc/ggc-page.c:1264
#8  ggc_internal_alloc (size=<optimized out>, size@entry=48, 
    f=0x691dc0 <finalize<c_binding>(void*)>, s=s@entry=0, n=n@entry=1)
    at ../../trunk.git/gcc/ggc-page.c:1421
#9  0x000000000066f18d in ggc_alloc<c_binding> ()
    at ../../trunk.git/gcc/ggc.h:185
#10 bind (name=name@entry=0x7fffe9f71b40, decl=decl@entry=0x7fffe9f76000, 
    scope=0x7fffe9f07300, invisible=true, nested=false, locus=locus@entry=0)
    at ../../trunk.git/gcc/c/c-decl.c:738
#11 0x00000000006774d4 in c_builtin_function (decl=0x7fffe9f76000)
    at ../../trunk.git/gcc/c/c-decl.c:4585
#12 0x0000000000750d62 in def_builtin_1 (fncode=BUILT_IN_GAMMAF_R, 
    name=0x1e3d121 "__builtin_gammaf_r", fnclass=BUILT_IN_NORMAL, 
    fntype=0x7fffe9f3e930, libtype=0x7fffe9f3e930, both_p=true, 
    fallback_p=<optimized out>, nonansi_p=true, fnattrs=0x7fffe9f50398, 
    implicit_p=false) at ../../trunk.git/gcc/c-family/c-common.c:4923
#13 0x000000000072b118 in c_define_builtins (
Comment 72 Martin Liška 2021-12-14 10:01:40 UTC
You will manage, it's not rocket science.

So please, add break point at the place it triggers the ICE and do:

(gdb) p &ptr1->x_help_flag
(gdb) p &ptr2->x_help_flag

and then watch for the addresses it prints:

watch *$number

where $number is returned from the 'p &' command. And then re-run the program and you should see the:


Old value=...
New value=...

and you can print bt.
Comment 73 Arseny Solokha 2021-12-14 11:11:48 UTC
(In reply to Martin Liška from comment #67)
> (In reply to Arseny Solokha from comment #66)
> > Should I file my commend 38 as a separate PR, then?
> 
> Yes, please.

Filed as PR103709.
Comment 74 David Binderman 2021-12-14 14:12:40 UTC
(In reply to Martin Liška from comment #72)
> You will manage, it's not rocket science.
> 
> So please, add break point at the place it triggers the ICE and do:
> 
> (gdb) p &ptr1->x_help_flag
> (gdb) p &ptr2->x_help_flag

For this to work, I had to replace the options-save.o with a version
compiled by -O0 and that made the problem go away ;-<

I am still happy to walk away from this bug report. It is known
to occur on only one variant of one architecture and it is hard
to reproduce. I can think of better things to work on in gcc.

As far as finding a machine with a bdver2 architecture, I suspect
any more recent AMD machine would be fine. 

Has no one checked the compile farm ?
Comment 75 Martin Liška 2021-12-14 15:34:46 UTC
(In reply to David Binderman from comment #74)
> (In reply to Martin Liška from comment #72)
> > You will manage, it's not rocket science.
> > 
> > So please, add break point at the place it triggers the ICE and do:
> > 
> > (gdb) p &ptr1->x_help_flag
> > (gdb) p &ptr2->x_help_flag
> 
> For this to work, I had to replace the options-save.o with a version
> compiled by -O0 and that made the problem go away ;-<

Or you would have to print &ptr1->x_help_flag with a printf and then
use gdb for the memory.

> 
> I am still happy to walk away from this bug report. It is known
> to occur on only one variant of one architecture and it is hard
> to reproduce. I can think of better things to work on in gcc.

Ok...

> 
> As far as finding a machine with a bdver2 architecture, I suspect
> any more recent AMD machine would be fine. 
> 
> Has no one checked the compile farm ?

No, there's not a bdver2 machine.
Comment 76 rguenther@suse.de 2022-01-03 10:26:29 UTC
On Tue, 14 Dec 2021, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
> 
> --- Comment #75 from Martin Liška <marxin at gcc dot gnu.org> ---
> (In reply to David Binderman from comment #74)
> > (In reply to Martin Liška from comment #72)
> > > You will manage, it's not rocket science.
> > > 
> > > So please, add break point at the place it triggers the ICE and do:
> > > 
> > > (gdb) p &ptr1->x_help_flag
> > > (gdb) p &ptr2->x_help_flag
> > 
> > For this to work, I had to replace the options-save.o with a version
> > compiled by -O0 and that made the problem go away ;-<
> 
> Or you would have to print &ptr1->x_help_flag with a printf and then
> use gdb for the memory.
> 
> > 
> > I am still happy to walk away from this bug report. It is known
> > to occur on only one variant of one architecture and it is hard
> > to reproduce. I can think of better things to work on in gcc.
> 
> Ok...
> 
> > 
> > As far as finding a machine with a bdver2 architecture, I suspect
> > any more recent AMD machine would be fine. 
> > 
> > Has no one checked the compile farm ?
> 
> No, there's not a bdver2 machine.

Maybe the issue reproduces with only -mtune=bdver2 or with -march=bdver2 
-mno-xop (XOP is what's removed from znver2 for example, not 100% sure
that's all, but ...).  It does sound like eventually options-save.c
is miscompiled somehow ...
Comment 77 David Binderman 2022-01-03 22:22:12 UTC
(In reply to rguenther@suse.de from comment #76)
> Maybe the issue reproduces with only -mtune=bdver2 or with -march=bdver2 
> -mno-xop (XOP is what's removed from znver2 for example, not 100% sure
> that's all, but ...).  It does sound like eventually options-save.c
> is miscompiled somehow ...

Thanks for the guidance.

I tried a build with -march=bdver2 -mno-xop and it worked fine.

So the xop feature is the culprit.
Comment 78 David Binderman 2022-01-03 22:32:44 UTC
-mxop adds 124 functions. I am not sure how to find out which ones are broken.

Is there some way to add only some of the 124 into the machine description ?
Comment 79 rguenther@suse.de 2022-01-04 07:43:21 UTC
On Mon, 3 Jan 2022, dcb314 at hotmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
> 
> --- Comment #77 from David Binderman <dcb314 at hotmail dot com> ---
> (In reply to rguenther@suse.de from comment #76)
> > Maybe the issue reproduces with only -mtune=bdver2 or with -march=bdver2 
> > -mno-xop (XOP is what's removed from znver2 for example, not 100% sure
> > that's all, but ...).  It does sound like eventually options-save.c
> > is miscompiled somehow ...
> 
> Thanks for the guidance.
> 
> I tried a build with -march=bdver2 -mno-xop and it worked fine.
> 
> So the xop feature is the culprit.

OK, so can you - in a -march=bdver2 built tree (that then fails) - produce
options-save.ii (preprocessed source) and attach that?  Can you try
whether you get past the failure point when you add -fno-tree-vectorize
to just the options-save.o compilation?  Can you provide the -v output
of the options-save.o compile so we get the exact cc1plus invocation?

I'll then try to figure out what goes wrong by looking at the
assembly output.
Comment 80 Martin Liška 2022-01-04 08:35:25 UTC
I've got access to a bdver2 machine, so I should be able to reproduce it.
Comment 81 David Binderman 2022-01-04 11:14:30 UTC
Created attachment 52118 [details]
preprocessed source code

Bug seems to have moved to unwind-dw2.c. Preprocessed source code attached.
Comment 82 David Binderman 2022-01-04 11:19:50 UTC
(In reply to rguenther@suse.de from comment #79)
> OK, so can you - in a -march=bdver2 built tree (that then fails) - produce
> options-save.ii (preprocessed source) and attach that?  

Done.

> Can you try whether you get past the failure point when you add -fno-tree-vectorize to just the options-save.o compilation?  

Flag doesn't help.

> Can you provide the -v output
> of the options-save.o compile so we get the exact cc1plus invocation?

Compile command is this:

/home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/ -B/home/dcb/gcc/results.20220104/x86_64-pc-linux-
gnu/bin/ -B/home/dcb/gcc/results.20220104/x86_64-pc-linux-gnu/lib/ -isystem /home/dcb/gcc/results.20220104/x86_64
-pc-linux-gnu/include -isystem /home/dcb/gcc/results.20220104/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -g -
O3 -march=native -O2  -g -O3 -march=native -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-e
rror=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem
 ./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fn
o-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../
../trunk.git/libgcc -I../../../trunk.git/libgcc/. -I../../../trunk.git/libgcc/../gcc -I../../../trunk.git/libgcc/
../include -I../../../trunk.git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS  -MT un
wind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c -fno-tree-vectorize ../../../trunk.git/libgcc/unwind-dw2.c 
-fvisibility=hidden -DHIDE_EXPORTS 

cc1 command line is

 /home/dcb/gcc/working/./gcc/cc1 -quiet -v -I . -I . -I ../.././gcc -I ../../../trunk.git/libgcc -I ../../../trunk.git/libgcc/. -I ../../../trunk.git/libgcc/../gcc -I ../../../trunk.git/libgcc/../include -I ../../../trunk.git/libgcc/config/libbid -iprefix /home/dcb/gcc/working/gcc/../lib/gcc/x86_64-pc-linux-gnu/12.0.0/ -isystem /home/dcb/gcc/working/./gcc/include -isystem /home/dcb/gcc/working/./gcc/include-fixed -MD unwind-dw2.d -MF unwind-dw2.dep -MP -MT unwind-dw2.o -D IN_GCC -D USE_ELF_SYMVER -D IN_LIBGCC2 -D USE_ELF_SYMVER -D ENABLE_DECIMAL_BID_FORMAT -D HAVE_CC_TLS -D USE_TLS -D HIDE_EXPORTS -isystem /home/dcb/gcc/results.20220104/x86_64-pc-linux-gnu/include -isystem /home/dcb/gcc/results.20220104/x86_64-pc-linux-gnu/sys-include -isystem ./include ../../../trunk.git/libgcc/unwind-dw2.c -march=bdver2 -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mno-avx2 -msse4a -mfma4 -mxop -mfma -mno-avx512f -mbmi -mno-bmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -mno-adx -mabm -mno-cldemote -mno-clflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mno-fsgsbase -mfxsr -mno-hle -msahf -mlwp -mlzcnt -mno-movbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid -mno-rdrnd -mno-rdseed -mno-rtm -mno-serialize -mno-sgx -mno-sha -mno-shstk -mtbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mno-xsavec -mno-xsaveopt -mno-xsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -quiet -dumpbase unwind-dw2.c -dumpbase-ext .c -mlong-double-80 -mshstk -g -g -g -O3 -O2 -O3 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -version -fchecking=1 -fcf-protection=full -fbuilding-libgcc -fno-stack-protector -fpic -fcf-protection=full -fexceptions -fvisibility=hidden
Comment 83 Martin Liška 2022-01-04 13:51:58 UTC
I was able to reproduce that, analyzing it right now.
Comment 84 Martin Liška 2022-01-04 13:52:16 UTC
Thanks David for help!
Comment 85 Martin Liška 2022-01-04 17:27:00 UTC
Ok, so the options-save.c is really miscompiled. I reduced that down to:

$ cat options-save2.ii
struct cl_optimization {
  /* All have value 0. */
  char x_flag_keep_gc_roots_live;
  char x_flag_lifetime_dse;
  char x_flag_limit_function_alignment;
  char x_flag_live_range_shrinkage;
  char x_flag_loop_interchange;
  char x_flag_loop_nest_optimize;
  char x_flag_loop_parallelize_all;
  char x_flag_unroll_jam;
  char x_flag_lra_remat;
  char x_flag_errno_math;
  char x_flag_modulo_sched;
  char x_flag_modulo_sched_allow_regmoves;
  char x_flag_move_loop_invariants;
  char x_flag_move_loop_stores;
  char x_flag_non_call_exceptions;
  /* Value 1. */
  char x_flag_nothrow_opt;
} cl_optimization_save_ptr;

int val0, val1;

void cl_optimization_save() {
  cl_optimization_save_ptr.x_flag_keep_gc_roots_live = val0;
  cl_optimization_save_ptr.x_flag_lifetime_dse = val0;
  cl_optimization_save_ptr.x_flag_limit_function_alignment = val0;
  cl_optimization_save_ptr.x_flag_live_range_shrinkage = val0;
  cl_optimization_save_ptr.x_flag_loop_interchange = val0;
  cl_optimization_save_ptr.x_flag_loop_nest_optimize = val0;
  cl_optimization_save_ptr.x_flag_loop_parallelize_all = val0;
  cl_optimization_save_ptr.x_flag_unroll_jam = val0;
  cl_optimization_save_ptr.x_flag_lra_remat = val0;
  cl_optimization_save_ptr.x_flag_errno_math = val0;
  cl_optimization_save_ptr.x_flag_modulo_sched = val0;
  cl_optimization_save_ptr.x_flag_modulo_sched_allow_regmoves = val0;
  cl_optimization_save_ptr.x_flag_move_loop_invariants = val0;
  cl_optimization_save_ptr.x_flag_move_loop_stores = val0;
  cl_optimization_save_ptr.x_flag_non_call_exceptions = val0;
  cl_optimization_save_ptr.x_flag_nothrow_opt = val1;
}

$ /tmp/gcc/objdir2/./gcc/xg++ -B/tmp/gcc/objdir2/./gcc/ -O2 options-save2.ii -S -O3 -march=core2 -o good.s -fno-checking -fdump-rtl-final=good.txt

$ /tmp/gcc/objdir/./prev-gcc/xg++ -B/tmp/gcc/objdir/./prev-gcc/ -O2 options-save2.ii -S -O3 -march=core2 -o good.s -fno-checking -fdump-rtl-final=bad.txt

diff good.txt bad.txt prints:

 (insn:TI 12 5 39 2 (set (reg:V16QI 23 xmm3 [94])
         (mem/u/c:V16QI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0  S16 A128])) "options-save2.ii":25:54 1652 {movv16qi_internal}
      (expr_list:REG_EQUIV (const_vector:V16QI [
                 (const_int -128 [0xffffffffffffff80]) repeated x8
                 (const_int 0 [0])
                 (const_int 1 [0x1])
                 (const_int 4 [0x4])
                 (const_int 5 [0x5])
-                (const_int 8 [0x8])
-                (const_int 9 [0x9])
-                (const_int 12 [0xc])
-                (const_int 13 [0xd])
+                (const_int -128 [0xffffffffffffff80]) repeated x4
             ])
         (nil)))

So as seen, different vector constants are saved to xmm3.
Comment 86 Martin Liška 2022-01-04 17:29:16 UTC
Optimized dump is equal:

void cl_optimization_save ()
{
  vector(8) short int vect__2.20;
  vector(16) char vect__2.19;
  int val0.0_1;
  int val1.15_3;
  vector(4) int _22;
  vector(4) int _25;

  <bb 2> [local count: 1073741824]:
  val0.0_1 = val0;
  _25 = {val0.0_1, val0.0_1, val0.0_1, val0.0_1};
  val1.15_3 = val1;
  _22 = {val0.0_1, val0.0_1, val0.0_1, val1.15_3};
  vect__2.20_26 = VEC_PACK_TRUNC_EXPR <_25, _25>;
  vect__2.20_27 = VEC_PACK_TRUNC_EXPR <_25, _22>;
  vect__2.19_28 = VEC_PACK_TRUNC_EXPR <vect__2.20_26, vect__2.20_27>;
  MEM <vector(16) char> [(char *)&cl_optimization_save_ptr] = vect__2.19_28;
  return;

}
Comment 87 Martin Liška 2022-01-04 17:43:37 UTC
Self-contained test-case:

$ cat options-save2.ii
char flags[16];

int one = 1, two = 2;

void
__attribute__ ((noipa))
save() {
  flags[0] = one;
  flags[1] = one;
  flags[2] = one;
  flags[3] = one;
  flags[4] = one;
  flags[5] = one;
  flags[6] = one;
  flags[7] = one;
  flags[8] = one;
  flags[9] = one;
  flags[10] = one;
  flags[11] = one;
  flags[12] = one;
  flags[13] = one;
  flags[14] = one;
  flags[15] = two;
}

int
main()
{
  save ();

  __builtin_printf ("flags[0]=%d, flags[15]=%d\n", flags[0], flags[15]);
  if (flags[15] != 2)
    __builtin_abort ();

  return 0;
}
Comment 88 Martin Liška 2022-01-04 18:43:08 UTC
And the miscompiled file is i386-expand.o.
Comment 89 Martin Liška 2022-01-04 19:31:50 UTC
Closing as the miscompilation is unrelated to this.
Comment 90 Martin Liška 2022-01-05 14:43:36 UTC
Note that I can bootstrap with -O3 -march=native on bdver1 when I apply the fix for PR103905.
Comment 91 David Binderman 2022-01-06 14:57:35 UTC
I confirm that the problem seems fixed to me in today's trunk.
Thanks to everyone for what has been an unusually difficult bug to find.
Comment 92 Andrew Pinski 2024-03-27 00:54:54 UTC
*** Bug 85961 has been marked as a duplicate of this bug. ***