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=89953
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159
Nikolay Orliuk changed:
What|Removed |Added
CC||virkony at gmail dot com
--- Comment
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=79183
Roland Illig changed:
What|Removed |Added
CC||roland.illig at gmx dot de
--- Comment
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=gcc=rev
Log:
PR target/90125
* config/i386/avx512fintrin.h
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
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=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=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=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=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=gcc=rev
Log:
PR c++/90124 - bogus error with incomplete type in decltype.
*
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=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 &&
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=67906
Eric Gallager changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
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
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=gcc=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
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=gcc=rev
Log:
PR libstdc++/90105 make forward_list::sort stable
While testing the fix I also
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=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=gcc=rev
Log:
PR go/90110
compiler: use temporary to avoid early destruction
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=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 #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=87871
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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
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
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=gcc=rev
> Log:
> PR
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=90133
Bug ID: 90133
Summary: Linker error if no
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee:
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=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=gcc=rev
Log:
PR c++/90047 - ICE with enable_if alias template.
In order to make alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432
--- Comment #4 from Uroš Bizjak ---
Created attachment 46182
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46182=edit
Proposed patch
Attached patch introduces DRUNTIME_OS_LINUX_PRE_2639 function that detects
linux version < 2.6.39 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
--- Comment #3 from Dominique d'Humieres ---
Revision r270115 (2019-04-03) compiles the test without error, r270252
(2019-04-10) generates a lot of errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125
Bug ID: 90125
Summary: Typo of AVX512 intrinsics
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #4 from Martin Liška ---
For the 2 test-cases we reach these backtraces:
$ ./xgcc -B. test.c -O1
../../gcc/poly-int.h:1941:12: runtime error: negation of -9223372036854775808
cannot be represented in type 'long int'; cast to an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368
--- Comment #8 from Jonathan Wakely ---
(In reply to Justin Bassett from comment #7)
> and it won't extend to future standardized attributes.
That's a Good Thing. If I use a new standardized attribute like
[[no_unique_address]] I definitely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #57 from Richard Biener ---
(In reply to Richard Biener from comment #56)
> Testcase from PR82177:
>
> #include
> #include
>
> void f(int*, int*);
>
> int main()
> {
> int a=0, y[1], x = 0;
> uintptr_t pi = (uintptr_t)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90126
--- Comment #2 from Jonathan Wakely ---
tl;dr the preprocessor should only be used once. You're running it twice on the
same input.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90108
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
--- Comment #14 from Richard Biener ---
I think implementation-wise GCC outrules aliases that are not visible but takes
care of symbols resolving to NULL. For optimizations of actual accesses it can
assume the symbols do not resolve to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037
--- Comment #9 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #8)
> So, if we change phionlycprop to look for other const/copy initializations
> that can be eliminated and run a pass between DOM and the erroneous-path
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #5 from Martin Liška ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81135
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
Richard Biener changed:
What|Removed |Added
CC||peadar at arista dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
--- Comment #6 from Ville Voutilainen ---
Any chance of moving this warning out of -Wextra and re-considering adding it
there for GCC 10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #58 from Richard Biener ---
(In reply to Richard Biener from comment #49)
> Related testcase from PR61502:
>
> #include
>
> int main()
> {
>int x, y = 1;
>int *volatile v;
>int *p;
>
>v =
>p = v;
>if (p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90126
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #53 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #52)
> I digged a bit, and found a D syntax for the target attribute,
> it is a bit of a complication since D does not have a pre-processor,
> but an empty target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #2 from Richard Biener ---
Created attachment 46183
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46183=edit
32bit math.gox
Here it is. The 64bit one looks similar btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109
--- Comment #3 from nebiun at hotmail dot com ---
Sorry, but the bug is not related to the wrong dimension of a type, but to the
fact that the bitsize of the same type (K type: long, not long long or double
or a user type) is showed as 32 bit as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542
--- Comment #11 from Richard Biener ---
Nathan, what does it take to re-instantiate -fdump-lang-raw for the C frontend?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #52 from Bernd Edlinger ---
I digged a bit, and found a D syntax for the target attribute,
it is a bit of a complication since D does not have a pre-processor,
but an empty target attribute does seem to be ignored without warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #53 from Martin Jambor ---
I'd vote for marking this fixed (and asking anyone with other ideas what could
be improved in generic tuning to open a new bug).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125
--- Comment #1 from Hongtao.liu ---
Last time I add runtime tests for -O2, didn't cover this part which use -O0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90048
--- Comment #2 from Thomas Schwinge ---
Author: tschwinge
Date: Wed Apr 17 08:34:20 2019
New Revision: 270406
URL: https://gcc.gnu.org/viewcvs?rev=270406=gcc=rev
Log:
[PR90048] Fortran OpenACC 'private' clause rejected for predetermined private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114
--- Comment #1 from Thomas Schwinge ---
Author: tschwinge
Date: Wed Apr 17 08:34:10 2019
New Revision: 270405
URL: https://gcc.gnu.org/viewcvs?rev=270405=gcc=rev
Log:
[PR90067, PR90114] Document Fortran OpenACC predetermined private status quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90067
--- Comment #1 from Thomas Schwinge ---
Author: tschwinge
Date: Wed Apr 17 08:34:10 2019
New Revision: 270405
URL: https://gcc.gnu.org/viewcvs?rev=270405=gcc=rev
Log:
[PR90067, PR90114] Document Fortran OpenACC predetermined private status quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90126
--- Comment #1 from Jonathan Wakely ---
I don't think this is a bug.
If you tell gcc that the preprocessed output is preprocessed output, then the
behaviour is consistent. So either:
g++ -E namespace_anonymous_1_min_ok.cpp >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #3 from Richard Biener ---
Btw, I just checked and the build also fails with glibc 2.22 in the same way.
Oddly enough it only fails in a controlled environment but not on a development
machine with the same glibc I do regular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #51 from Jakub Jelinek ---
Author: jakub
Date: Wed Apr 17 08:30:44 2019
New Revision: 270404
URL: https://gcc.gnu.org/viewcvs?rev=270404=gcc=rev
Log:
PR target/89093
* config/arm/arm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037
--- Comment #10 from Jonathan Wakely ---
Jeff posted this to PR 89819 instead of here:
Somewhat trimmed down testcase... Certainly easier to analyze...
typedef __SIZE_TYPE__ size_t;
typedef unsigned long int uintmax_t;
struct group
{
char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #15 from Martin Liška ---
@Nikolay:
As discussed in https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00416.html email
thread, we reached the following consensus with H.J:
- As any AVX512 extensions (apart from AVX512F) can be enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90126
Bug ID: 90126
Summary: gcc can not correctly deal with its own preprocessed
output
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127
Bug ID: 90127
Summary: Disable bugzilla [[wiki_links]] and don't confuse rNN
register names with rN svn revisions
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
--- Comment #7 from Ville Voutilainen ---
Innocent users are going to hit it: https://bugreports.qt.io/browse/QTBUG-75210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17108
--- Comment #9 from Segher Boessenkool ---
Author: segher
Date: Wed Apr 17 09:45:57 2019
New Revision: 270407
URL: https://gcc.gnu.org/viewcvs?rev=270407=gcc=rev
Log:
rs6000: Improve the load/store-with-update patterns (PR17108)
Many of these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125
--- Comment #2 from Jakub Jelinek ---
Created attachment 46186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46186=edit
gcc9-pr90125.patch
Oops, you're right, thanks for noticing.
Here is a full patch including testcases that FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #54 from Wilco ---
(In reply to Jeffrey A. Law from comment #53)
> Realistically the register allocation issues are not going to get addressed
> this cycle nor are improvements to the overall handling of RMW insns in
> combine. So
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:
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=90127
Frédéric Buclin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120
--- Comment #3 from Claudiu Zissulescu ---
Added a patch to solve upper/lower issue:
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00696.html
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
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=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=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
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=90125
--- Comment #3 from Hongtao.liu ---
L(In reply to Jakub Jelinek from comment #2)
> Created attachment 46186 [details]
> gcc9-pr90125.patch
>
> Oops, you're right, thanks for noticing.
> Here is a full patch including testcases that FAIL without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #16 from Nikolay Bogoychev ---
Created attachment 46187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46187=edit
target("arch=foo") doesn't work
(In reply to Martin Liška from comment #15)
> @Nikolay:
>
> As discussed in
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
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:
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=59.437.0=76.437.0=33.437.0;
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
1 - 100 of 156 matches
Mail list logo
