https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #8 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f4e92d62dccb96ade753f3a8f49be1b5f61c31f1
commit r14-9666-gf4e92d62dccb96ade753f3a8f49be1b5f61c31f1
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #6 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #5)
> Maybe we should always use kmask under AVX512, currently only >= 128-bits
> vector of vector _Float16 use kmask, < 128 bits vector still use vector mask.
>
and we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #3 from Sam James ---
float quantize_x_1, quantize_x_0;
short *quantize_xq;
short quantize_x0;
void quantize() {
short x1 = quantize_xq[0] =
quantize_x0 + ((quantize_x0 > 0) & (quantize_x_0 < 0));
quantize_xq[1] = 1 + ((x1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #2 from Sam James ---
Created attachment 57812
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57812=edit
spec.i.orig.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #1 from Sam James ---
The original failed with:
```
../liblc3-1.0.4/src/spec.c: In function ‘quantize’:
../liblc3-1.0.4/src/spec.c:210:21: error: type mismatch in binary expression
210 | LC3_HOT static void quantize(enum lc3_dt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97585
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97585
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108629
Bug ID: 108629
Summary: 549.fotonik3d_r regresses 15-24% at -O2 -flto
-march=x86-64-v3 since r13-1203-g038b077689bb53
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106344
Bug ID: 106344
Summary: A few x86_64 tests fail with -march=x86-64-v2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
Compile PR target/104441 tests with -march=x86-64 to fix test failures
when GCC is configured with --with-arch=native --with-cpu=native.
PR target/104441
* gcc.target/i386/pr104441-1a.c: Compile with -march=x86-64.
* gcc.target/i386/pr104441-1b.c: Likewise.
---
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97281
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98274
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
: Tue Dec 15 10:16:08 2020 +0100
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
strcmp (opts->x_ix86_tune_string + 6, "-v2")
> + || !strcmp (opts->x_ix86_tune_string + 6, "-v3")
> + || !strcmp (opts->x_ix86_tune_string + 6, "-v4"
> + opts->x_ix86_tune_string = "gener
op_alg == rep_prefix_8_byte
--- gcc/testsuite/gcc.target/i386/pr98274.c.jj 2020-12-14 14:44:09.197559567
+0100
+++ gcc/testsuite/gcc.target/i386/pr98274.c 2020-12-14 14:43:22.406080077
+0100
@@ -0,0 +1,8 @@
+/* PR target/98274 */
+/* { dg-do compile { target lp64 } } */
+/* { dg-options "-mabi=sysv -O2 -march=x86-64-v2" } */
+
+void __attribute__((target ("avx")))
+foo (void)
+{
+}
Jakub
On Mon, Dec 14, 2020 at 7:09 AM Uros Bizjak wrote:
>
> On Mon, Dec 14, 2020 at 2:13 PM Jakub Jelinek wrote:
> >
> > Hi!
> >
> > If somebody has -march=x86-64-v2 (or -v3 or -v4) in $CFLAGS, $CXXFLAGS etc.,
> > then -m32 or -mabi=ms stops working.
>
On Mon, Dec 14, 2020 at 2:13 PM Jakub Jelinek wrote:
>
> Hi!
>
> If somebody has -march=x86-64-v2 (or -v3 or -v4) in $CFLAGS, $CXXFLAGS etc.,
> then -m32 or -mabi=ms stops working.
> What is worse, if one configures gcc --with-arch-32=x86-64-v2 (or -v3 or -v4),
> then -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98274
--- Comment #1 from Jakub Jelinek ---
Created attachment 49760
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49760=edit
gcc11-pr98274.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98274
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98274
Bug ID: 98274
Summary: -march=x86-64-v[234] incompatible with target
attribute
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Hi!
If somebody has -march=x86-64-v2 (or -v3 or -v4) in $CFLAGS, $CXXFLAGS etc.,
then -m32 or -mabi=ms stops working.
What is worse, if one configures gcc --with-arch-32=x86-64-v2 (or -v3 or -v4),
then -mabi=ms stops working.
I think that is a nightmare user experience. It is ok that x86-64-v
The current development docs say:
>x86-64-v2
>x86-64-v3
>x86-64-v4
>
> These choices for cpu-type select the corresponding
> micro-architecture level from the x86-64 psABI. They are only available
> when compiling for an x86-64 target that uses the System V psABI.
>
> Since these cpu-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97585
Bug ID: 97585
Summary: Improve documentation for -march=x86-64 to say MMX,
SSE, SSE2 are implied
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #9 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:16664e6e4fb4281be6477c13989740d44c963c77
commit r11-3764-g16664e6e4fb4281be6477c13989740d44c963c77
Author: H.J. Lu
Date: Fri Oct 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #8 from H.J. Lu ---
(In reply to Florian Weimer from comment #7)
> (In reply to H.J. Lu from comment #6)
> > (In reply to Florian Weimer from comment #5)
> > > (In reply to H.J. Lu from comment #4)
> > > > x86-64-v2 includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #7 from Florian Weimer ---
(In reply to H.J. Lu from comment #6)
> (In reply to Florian Weimer from comment #5)
> > (In reply to H.J. Lu from comment #4)
> > > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #6 from H.J. Lu ---
(In reply to Florian Weimer from comment #5)
> (In reply to H.J. Lu from comment #4)
> > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.
>
> It's called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #5 from Florian Weimer ---
(In reply to H.J. Lu from comment #4)
> x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.
It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good enough?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
H.J. Lu changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
uid based mechanisms to determine whether such code
> can or can't be called?
With glibc-hwcaps change:
https://sourceware.org/pipermail/libc-alpha/2020-October/118184.html
shared libraries under subdirectories compiled with -march=x86-64-v[234]
have no CPUID check. A command-line op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97281
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97281
Bug ID: 97281
Summary: Mark- march=x86-64-v[234] binaries
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
Florian Weimer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #2 from CVS Commits ---
The master branch has been updated by Florian Weimer :
https://gcc.gnu.org/g:324bec558e95584e8c1997575ae9d75978af59f1
commit r11-3578-g324bec558e95584e8c1997575ae9d75978af59f1
Author: Florian Weimer
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #1 from Florian Weimer ---
First patch committed (preparatory only):
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=92e652d8c21bd7e66c
Second patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555174.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
Florian Weimer changed:
What|Removed |Added
Last reconfirmed||2020-09-30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
Bug ID: 97250
Summary: Implement -march=x86-64-v2, -march=x86-64-v3,
-march=x86-64-v4 for x86-64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #20 from Jan Hubicka ---
> OK, will do, but, at least superficially, our situation seems very similar to
> this one, so I thought it would be better to keep this one going. But, again,
> I'll open the new one as soon as I can make a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #19 from Vadim Zeitlin ---
(In reply to Jan Hubicka from comment #18)
> We need a reproducer to fix bugs.
Yes, of course, I understand this. I just didn't have time to make one yet,
we've literally discovered the issue only today
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #18 from Jan Hubicka ---
> I've just subscribed to this bug because we see bug slow downs in our project
> when switching from 8.3 to 10.2 (89% slower in an important use case, 30%
> slowdown more or less across the board), without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #17 from Vadim Zeitlin ---
I've just subscribed to this bug because we see bug slow downs in our project
when switching from 8.3 to 10.2 (89% slower in an important use case, 30%
slowdown more or less across the board), without any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Mon, Aug 24, 2020 at 3:23 PM H.J. Lu wrote:
> > Speaking of pragmas, these should be added outside cpuid.h, like:
> >
> > #pragma GCC push_options
> > #pragma GCC target("general-regs-only")
> >
> > #include
> >
> > void cpuid_check ()
> > ...
> >
> > #pragma GCC pop_options
> >
> >
On Sun, Aug 23, 2020 at 9:03 AM Uros Bizjak wrote:
>
> On Sun, Aug 23, 2020 at 5:23 PM H.J. Lu wrote:
> >
> > On Sun, Aug 23, 2020 at 10:18:28AM +0200, Uros Bizjak wrote:
> > > On Sat, Aug 22, 2020 at 9:09 PM H.J. Lu wrote:
> > >
> > > > > > Compile CPUID check with "-mno-sse -mfpmath=387" to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #15 from Jan Hubicka ---
> I think, this inliner change needs to be reverted. People expect -O2 to
> produce
> decently optimized binaries, and starting with gcc 10.x it doesn't deliver.
> -O3
> traditionally enabled optimizations
> I think, this inliner change needs to be reverted. People expect -O2 to
> produce
> decently optimized binaries, and starting with gcc 10.x it doesn't deliver.
> -O3
> traditionally enabled optimizations that may or may not improve performance
> (and historically, sometimes even break code),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #14 from Dávid Bolvanský ---
Or change -Os to be gcc10 -O2 with less inlining, -revert O2 to gcc9 -02 and
implement -Oz to create agressive “-Os”.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #13 from andysem at mail dot ru ---
I think, this inliner change needs to be reverted. People expect -O2 to produce
decently optimized binaries, and starting with gcc 10.x it doesn't deliver. -O3
traditionally enabled optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #12 from Artem S. Tashkinov ---
Michael has admitted that might be a specific CPU relate regression:
> Been running some more tests today:
> - Tried on a i9-10980XE Cascade Lake and Cascade Lake Xeon systems and did
> not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #11 from Jan Hubicka ---
>
> Maybe you want to use same GCC version as phoronix used (GCC 10.2)?
OK, I will give it a try, but there are no inliner changes in gcc 10.2
compared to 10.1.
Honza
>
> Maybe you want to use same GCC version as phoronix used (GCC 10.2)?
OK, I will give it a try, but there are no inliner changes in gcc 10.2
compared to 10.1.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #10 from Dávid Bolvanský ---
>> Compiler version : GCC10.1.1
Maybe you want to use same GCC version as phoronix used (GCC 10.2)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #9 from Jan Hubicka ---
scimark
GCC 9:
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #8 from Jan Hubicka ---
This is the built withour release flags override as seems to be done by
phoronix:
GCC 9:
y4m [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw [info]: output file: /dev/null
x265 [info]: HEVC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #7 from Jan Hubicka ---
X265
GCC 9:
y4m [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw [info]: output file: /dev/null
x265 [info]: HEVC encoder version 3.1.2+1-76650bab70f9
x265 [info]: build info [Linux][GCC 9.3.1][64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #6 from Jan Hubicka ---
Coremark.
GCC 9 run1:
CoreMark Size: 666
Total ticks : 12310
Total time (secs): 12.31
Iterations/Sec : 24370.430544
Iterations : 30
Compiler version : GCC9.3.1 20200406 [revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #5 from Jan Hubicka ---
OK, I started with checking Himeno where phoronix reports 4377->2681
on my notebook (Intel(R) Core(TM) i7-6600U CPU) there may be around 1-5%
regression that is not inliner related
GCC 10
Loop executed for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #4 from Jan Hubicka ---
There was changes to -O2 inliner. I have
- enabled auto-inlininig
- reduced early inlining a bit
- reduced limits for inlining functions declared inline
The second two was needed to keep code size under
as slow for |[10/11 Regression] GCC
|-O2 -march=x86-64 vs. GCC |10.2: twice as slow for -O2
|9.3/8.4 |-march=x86-64 vs. GCC
||9.3/8.4
Keywords||missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #2 from Artem S. Tashkinov ---
Looks like even kernel performance is affected:
https://lore.kernel.org/lkml/20200507224530.2993316-1-ja...@zx2c4.com/
That was surely not a change for the better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
Dávid Bolvanský changed:
What|Removed |Added
CC||david.bolvansky at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
Bug ID: 96337
Summary: GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC
9.3/8.4
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
On Donnerstag, 11. Juli 2019 20:58:04 CEST Allan Sandfeld Jensen wrote:
> Years ago I discovered Chrome was optimizing with -march=x86-64, and
> knowing was an undocumented arch that would optimize for K8 I laughed at it
> and just removed that piece of idiocy from our fork of Chr
Years ago I discovered Chrome was optimizing with -march=x86-64, and knowing
was an undocumented arch that would optimize for K8 I laughed at it and just
removed that piece of idiocy from our fork of Chromium, so it would be faster
than upstream. Recently though I noticed phoronix is also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57112
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
--- Comment #3 from Paul Brannan ---
-march=x86-64 is in the man page for gcc 8.2 (it was not in the man page for
5.4; I'm not sure which version it first appears).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57112
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2013-04-29 00:00:00 |2015-10-6
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57112
Bug #: 57112
Summary: -march=x86-64 not documented
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57112
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
75 matches
Mail list logo
