diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2020-12-15 10:16:08 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2020-12-15 10:16:08 +0100 |
| commit | 69bd5d473d22157d0737fc20e98eb3347cbd6ab5 (patch) | |
| tree | f08acbee46c18ee8097de50ef6185fb95033a1db /gcc/fold-const-call.c | |
| parent | cab1b0ebc00ea53040afcbe4b91e653a87915092 (diff) | |
| download | gcc-69bd5d473d22157d0737fc20e98eb3347cbd6ab5.zip gcc-69bd5d473d22157d0737fc20e98eb3347cbd6ab5.tar.gz gcc-69bd5d473d22157d0737fc20e98eb3347cbd6ab5.tar.bz2 | |
i386: Fix up -march=x86-64-v[234] vs. target attribute [PR98274]
The following testcase fails to compile. The problem is that
when ix86_option_override_internal is called the first time for command
line, it sees -mtune= wasn't present on the command line and so as fallback
sets ix86_tune_string to ix86_arch_string value ("x86-64-v2"), but
ix86_tune_specified is false, so we don't find the tuning in the table
but don't error on it.
When processing the target attribute, ix86_tune_string is what
it was earlier left with, but this time ix86_tune_specified is true and
so we error on it.
The following patch does what is done already e.g. for "x86-64" march,
in particular default the tuning to "generic".
2020-12-15 Jakub Jelinek <jakub@redhat.com>
PR target/98274
* config/i386/i386-options.c (ix86_option_override_internal): Set
ix86_tune_string to "generic" even when it wasn't specified and
ix86_arch_string is "x86-64-v2", "x86-64-v3" or "x86-64-v4".
Remove useless {}s around a single statement.
* gcc.target/i386/pr98274.c: New test.
Diffstat (limited to 'gcc/fold-const-call.c')
0 files changed, 0 insertions, 0 deletions