https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127
--- Comment #2 from Jonathan Wakely ---
Would it be easy to only link for strings that look like WikiNames and not
identifiers in all lowercase like "noreturn"?
e.g. a regex like [[:upper:]][[:alnum:]]+
That way [[InstallingGCC]] and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120
Claudiu Zissulescu changed:
What|Removed |Added
CC||claziss at gmail dot com
---
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=90127
Frédéric Buclin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=90120
Jakub Jelinek changed:
What|Removed |Added
CC||claziss at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #59 from post+gcc at ralfj dot de ---
> With the C provenance proposal this example is undefined since 'a' is not
exposed (it's address is not converted to an integer).
However, from what I can tell, GCC's behavior does not change if
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=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=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=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=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=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=90126
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
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=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=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=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=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=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=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=90106
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #7
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=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=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=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=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=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=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=90124
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3
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=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=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=90120
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
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=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=90121
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=90108
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=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=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=90124
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
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
101 - 156 of 156 matches
Mail list logo
