https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #82 from Iain Sandoe ---
Author: iains
Date: Thu Apr 18 06:53:21 2019
New Revision: 270435
URL: https://gcc.gnu.org/viewcvs?rev=270435&root=gcc&view=rev
Log:
fix PR89864
2019-04-18 Erik Schnetter
Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90134
Bug ID: 90134
Summary: ICE in duplicate_eh_regions_1, at except.c:557
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, openmp
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85789
--- Comment #1 from Vittorio Zecca ---
I confirm it is still in trunk 270309, must be compiled with
nonzero optimization
~/local/gcc-270309-undefined/bin/gcc -S -O gccerr67.c
../../gcc/gcc/cse.c:2215:34: runtime error: signed integer overflow:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #81 from Jürgen Reuter ---
LLVM worked, so I think there are enough green lights now for committing this
fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813
--- Comment #10 from Eric Gallager ---
(In reply to rsand...@gcc.gnu.org from comment #8)
> Author: rsandifo
> Date: Tue Jan 15 16:46:54 2019
> New Revision: 267941
>
> URL: https://gcc.gnu.org/viewcvs?rev=267941&root=gcc&view=rev
> Log:
> PR in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #10 from ian at gcc dot gnu.org ---
Author: ian
Date: Thu Apr 18 04:11:22 2019
New Revision: 270434
URL: https://gcc.gnu.org/viewcvs?rev=270434&root=gcc&view=rev
Log:
PR go/90110
compiler: use temporary to avoid early des
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90047
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Thu Apr 18 03:32:24 2019
New Revision: 270433
URL: https://gcc.gnu.org/viewcvs?rev=270433&root=gcc&view=rev
Log:
PR c++/90047 - ICE with enable_if alias template.
In order to mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90133
Bug ID: 90133
Summary: Linker error if no
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Peter Bergner changed:
What|Removed |Added
Attachment #46189|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #32 from Peter Bergner ---
(In reply to Peter Bergner from comment #26)
> (In reply to Vladimir Makarov from comment #25)
> > (In reply to Peter Bergner from comment #24)
> >> I don't know why r0 isn't in profitable_regs for pseudo 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #80 from Jürgen Reuter ---
> A little late to the party, but this revised patch worked for me on
> 10.4.4/Xcode10.2 with gcc8.3.0, gcc7.4.0, and gcc6.5.0. fftw3-3.3.8 built
> and passed all tests against the patched gcc8 and gcc7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #79 from fink at snaggledworks dot com ---
(In reply to Iain Sandoe from comment #68)
> Created attachment 46176 [details]
> revised fixincludes patch.
>
> So I have an answer about the language implications.
>
> Any C++ program cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159
Nikolay Orliuk changed:
What|Removed |Added
CC||virkony at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Wed Apr 17 21:47:20 2019
New Revision: 270427
URL: https://gcc.gnu.org/viewcvs?rev=270427&root=gcc&view=rev
Log:
PR libstdc++/90105 make forward_list::sort stable
While testing the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159
--- Comment #3 from Marek Polacek ---
Ok, this shouldn't be too hard. I guess I could implement it for GCC 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159
Eric Gallager changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
Eric Gallager changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #22 from Segher Boessenkool ---
#line 0 isn't valid C code. If it causes problems we should just
error on it (and perhaps even when it doesn't (yet) cause problems).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
--- Comment #2 from Martin Sebor ---
I think the following test case reproduces what's going on in decNumber.c.
Both GCC 8 and 9 issue the warning (IIRC, the warning was added in GCC 7 for
writes but enhanced to reads in GCC 8).
$ cat a.c && gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90123
--- Comment #2 from iris ---
Hi Andrew, thank you so much for your comments!
I tried cproto4.7m and I no longer see these errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #21 from Jonny Grant ---
Hi! In comment 9 I raised if #line 0 could be prevented please
#line next_line_num
So a line can only be >=1 as I understand it.
Editors show files from line 1. There's no line 0
Godbolt can't show the erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89949
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89325
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Apr 17 19:24:55 2019
New Revision: 270422
URL: https://gcc.gnu.org/viewcvs?rev=270422&root=gcc&view=rev
Log:
PR c++/89325
* g++.dg/ext/attrib58.C: New test.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|jakub at red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Wed Apr 17 19:23:45 2019
New Revision: 270421
URL: https://gcc.gnu.org/viewcvs?rev=270421&root=gcc&view=rev
Log:
PR target/90125
* config/i386/avx512fintrin.h (_mm_maskz_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
Roland Illig changed:
What|Removed |Added
CC||roland.illig at gmx dot de
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
--- Comment #10 from Marek Polacek ---
Author: mpolacek
Date: Wed Apr 17 18:26:42 2019
New Revision: 270418
URL: https://gcc.gnu.org/viewcvs?rev=270418&root=gcc&view=rev
Log:
PR c++/90124 - bogus error with incomplete type in decltype.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368
--- Comment #9 from Justin Bassett ---
After more reflection, I do believe that ignoring attributes from unknown
namespaces is one of the best options.
My suggestion of whitelisting attributes falls apart when we consider how many
attributes the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90047
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
--- Comment #8 from Jason Merrill ---
(In reply to Marek Polacek from comment #7)
> (In reply to Marek Polacek from comment #6)
> > The operand of the decltype specifier is an unevaluated operand and perhaps
> > we have to take that into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
Bug ID: 90132
Summary: make bootstrap fails with -O3 (gcc9 snapshot 20190414)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #8 from Walter Landry ---
(In reply to Martin Liška from comment #5)
> (In reply to bin cheng from comment #4)
> > Another problem is the generated binary has segment fault issue even
> > compiled O0:
> >
> > $ ./g++ -O0 pr90078.cc -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
--- Comment #9 from Martin Jambor ---
I have only seen this when compiling with -march=native on Zen, but even at -O2
(which I overlooked yesterday, and which is also confirmed by LNT).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
--- Comment #7 from Marek Polacek ---
(In reply to Marek Polacek from comment #6)
> The operand of the decltype specifier is an unevaluated operand and perhaps
> we have to take that into account here.
...i.e., naming of objects does not, by its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88330
--- Comment #1 from emsr at gcc dot gnu.org ---
I saw this through reddit:
https://gitlab.com/lock3/gcc-new.git branch origin/contracts-jac-kona
This user has several interesting branches of contracts and concepts!
Wiki: http://gummif.github.io
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #61 from Jakub Jelinek ---
At least looking at x86_64-linux gcc/deh.o, I really don't see any .text
comdats, only data comdats, all STT_FUNC symbols are in the same section,
except for the global ctors in .text.startup and dtors in .t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109
--- Comment #5 from Jim Wilson ---
Stabs requires that we emit info for all of the base types at the start. But
if one of the base types does not exist for a 32-bit K&R C target, then we are
struck, as that can't be described. And if we can't d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89146
--- Comment #2 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #1)
> I've looked for constraints that include [ijnIJKLMNO] together with [mo] and
> couldn't find any. So, not really sure what note_invalid_constants is
> suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #9 from Ian Lance Taylor ---
> I think the *end != '\0' check is the problem here. The temporary object is
> gone at that point.
Ah ha. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #60 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #59)
> That looks like a D FE bug then.
> In any case, why can't you just use -mgeneral-regs-only on the deh.d
> compilation command line?
Could work, just anxious,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #7)
> (In reply to rsand...@gcc.gnu.org from comment #6)
>
> Thanks for handling this.
>
> > > template
> > > inline POLY_BINARY_COEFF (Ca, Ca)
> > > k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #7 from Jakub Jelinek ---
(In reply to rsand...@gcc.gnu.org from comment #6)
Thanks for handling this.
> > template
> > inline POLY_BINARY_COEFF (Ca, Ca)
> > known_alignment (const poly_int_pod &a)
> > {
> > typedef POLY_BINARY_CO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037
--- Comment #11 from Jeffrey A. Law ---
That may be an interesting approach. I think we'd want the new blocks created
by threading as well as the original blocks we threaded through since their
in-degree gets reduced which in turn can expose ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85762
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #12 from Martin Jambor ---
Author: jamborm
Date: Wed Apr 17 15:52:16 2019
New Revision: 270414
URL: https://gcc.gnu.org/viewcvs?rev=270414&root=gcc&view=rev
Log:
2019-04-17 Martin Jambor
Backport from mainline
201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85762
--- Comment #10 from Martin Jambor ---
Author: jamborm
Date: Wed Apr 17 15:52:16 2019
New Revision: 270414
URL: https://gcc.gnu.org/viewcvs?rev=270414&root=gcc&view=rev
Log:
2019-04-17 Martin Jambor
Backport from mainline
201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459
--- Comment #12 from Martin Jambor ---
Author: jamborm
Date: Wed Apr 17 15:52:16 2019
New Revision: 270414
URL: https://gcc.gnu.org/viewcvs?rev=270414&root=gcc&view=rev
Log:
2019-04-17 Martin Jambor
Backport from mainline
201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #31 from Segher Boessenkool ---
It's how you do a parallel of a mov and a flags set, which of course you
can have before RA, and you want created by combine, typically. Or do I
misunderstand the question?
(I though Arm have a "movs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532
--- Comment #18 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Wed Apr 17 15:40:12 2019
New Revision: 270413
URL: https://gcc.gnu.org/viewcvs?rev=270413&root=gcc&view=rev
Log:
gcc/ChangeLog:
2019-04-17 Kelvin Nilsen
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89736
--- Comment #5 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Wed Apr 17 15:40:12 2019
New Revision: 270413
URL: https://gcc.gnu.org/viewcvs?rev=270413&root=gcc&view=rev
Log:
gcc/ChangeLog:
2019-04-17 Kelvin Nilsen
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
maic changed:
What|Removed |Added
CC||maic23 at live dot de
--- Comment #8 from maic -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
20190417 (experimental) [trunk revision 270407] (GCC)
$ gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
#Wrong result#
$ gcc-trunk -g abc.c outer.c -O3
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x40040f: file abc.c, line 16.
Breakpoint 1, main () at abc.c:16
16optimize_me_not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #7 from Ian Lance Taylor ---
> What is the condition i > 0x7fff for? Shouldn't that test val instead?
Yes, it certainly should. Thanks. It's not the problem here, but should be
fixed.
> Just a wild guess - does this->body_.su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130
Bug ID: 90130
Summary: gdc.test/runnable/test12.d FAILs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #59 from Jakub Jelinek ---
That looks like a D FE bug then.
In any case, why can't you just use -mgeneral-regs-only on the deh.d
compilation command line?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #58 from Bernd Edlinger ---
No, sorry, the attribute on the prototype gets ignored, as the following
is compiled without generating an error:
private int test(double x)
{
return x > 1.0;
}
static if (GNU_ARM_EABI_Unwinder)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #30 from Jakub Jelinek ---
Is the *movsi_compare0 pattern actually ever a benefit before RA? At least in
this case it clearly results in a worse generated code rather than better, and
I bet in other cases too, it just ties the hands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #7)
> Benchmarking r270408 on branch vs. trunk on Haswell doesn't show any
> regression
> for me. Will double-check with up-to-date CPU 2017 tree.
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #20 from Martin Liška ---
>
> Does this mean that if I have an avx512bw+dq function, I'd have to have two
> identical versions of it that I have to target with arch=canonlake and
> arch=amd-something-with-avx512? Seems a bit... unell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #6 from rguenther at suse dot de ---
On Wed, 17 Apr 2019, ian at airs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
>
> --- Comment #4 from Ian Lance Taylor ---
> Thanks for the file. Unfortunately it looks f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Wed Apr 17 13:28:39 2019
New Revision: 270410
URL: https://gcc.gnu.org/viewcvs?rev=270410&root=gcc&view=rev
Log:
PR middle-end/90095
* internal-fn.c (expand_mul_overflow):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #5 from Andreas Schwab ---
What is the condition i > 0x7fff for? Shouldn't that test val instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #7 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #4 from Ian Lance Taylor ---
Thanks for the file. Unfortunately it looks fine.
The error is coming from Import_function_body::read_type in
gcc/go/gofrontend/import.cc. At the point of the error this->body_ +
this->off_ points to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #19 from Nikolay Bogoychev ---
(In reply to Martin Liška from comment #18)
> (In reply to Martin Liška from comment #17)
> > >
> > > @Martin:
> > >
> > > Thank you for the detailed answer. This could work for now. I have a few
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150
--- Comment #16 from Martin Nowak ---
Regarding the dlopen/dlclose in handleForName, the semantics of RTLD_NOLOAD are
so that it bumps the reference count if the library had been previously loaded.
The sections module uses the handle as identifie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> CPU 2006 436.cactusADM also has an interesting history:
> https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/
> 436_cactusADM_big.png
compared to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
--- Comment #5 from Richard Biener ---
CPU 2006 436.cactusADM also has an interesting history:
https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/436_cactusADM_big.png
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #57 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #56)
> Can't you just add prototypes?
> Like:
> static if (GNU_ARM_EABI_Unwinder)
> {
> @attribute("target", ("general-regs-only"))
> private _Unwind_Reason_Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #56 from Jakub Jelinek ---
Can't you just add prototypes?
Like:
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #55 from Bernd Edlinger ---
But, how about that:
Index: deh.d
===
--- deh.d (revision 270395)
+++ deh.d (working copy)
@@ -28,6 +28,7 @@
import gcc.unwind.p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #54 from Bernd Edlinger ---
Hmm, I see. What I am trying to accomplish is, put the target
attribute on every function that calls directly or in-directly
to CONTINUE_UNWINDING. And do that only for ARM.
For gdc_personality it is str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129
--- Comment #1 from Richard Biener ---
IIRC we have a duplicate for this (albeit with -msse2 vs. none)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
--- Comment #3 from Martin Liška ---
Direct graph link to branch comparison:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=148.437.0&plot.1=59.437.0&plot.2=76.437.0&plot.3=33.437.0&;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129
Bug ID: 90129
Summary: Wrong error: inlining failed in call to always_inline
‘_mm256_adds_epi16’: target specific option mismatch
Product: gcc
Version: 9.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #18 from Martin Liška ---
(In reply to Martin Liška from comment #17)
> >
> > @Martin:
> >
> > Thank you for the detailed answer. This could work for now. I have a few
> > questions about it:
> >
> > Wouldn't that create issues in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
--- Comment #2 from Richard Biener ---
Ugh. Cactus is really ugly code :/ For one there's an invariant switch () in
the innermost loop, expanded to a binary tree (slightly different split point
GCC 8 vs. trunk), obviously unswitching cannot han
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869
--- Comment #3 from Claudiu Zissulescu ---
DOC is string that shortly describes an machine dependent option. This string
is used to throw an warning/error when the underling option is not available
for a specific architecture, which can be arcem,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
Bug ID: 90128
Summary: 507.cactuBSSN_r is 9-11% slower at -Ofast and native
march/tuning on Zen CPUs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #17 from Martin Liška ---
>
> @Martin:
>
> Thank you for the detailed answer. This could work for now. I have a few
> questions about it:
>
> Wouldn't that create issues in the future if AMD decide to release avx512
> for their CPU
1 - 100 of 156 matches
Mail list logo
