https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #7 from DB ---
Interesting switch, thanks - doesn't make any difference to warnings at the
moment, though.
But it hits on what I'm going for: ensuring the compiler that I'll only use
named enumerator values. Ideally though, the Stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557
Bug ID: 77557
Summary: gcc doesn't warn about code (clang does),
__PRETTY_FUNCTION__ used in struct in function
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557
--- Comment #1 from Andrew Pinski ---
The question comes down to the following is NSDMI considered part of the
constructor or not. If not then GCC is correct here and depends on the
following code is valid or not:
#include
void fn () {
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557
--- Comment #2 from Martin ---
(In reply to Andrew Pinski from comment #1)
> The question comes down to the following is NSDMI considered part of the
> constructor or not. If not then GCC is correct here and depends on the
> following code is va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558
Bug ID: 77558
Summary: c-c++-common/va-arg-va-list-type.c fails for aarch64
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558
Tom de Vries changed:
What|Removed |Added
CC||christophe.lyon at st dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60016
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54839
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58203
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77559
Bug ID: 77559
Summary: Implicit conversion from pointer to reference fails
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #9 from Manuel López-Ibáñez ---
In summary, neither adding 'default' or 'return' are recommended to silence
this warning if you think the warning is wrong. If you think the warning will
always be wrong, use __builtin_unreachable(). If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70582
--- Comment #6 from Jan Hubicka ---
Does this still reproduce? I have implemented the optimization that removes
weakrefs with definition provided in other unit so this may be solved/hidden by
it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77431
--- Comment #3 from Marek Polacek ---
I like -Wduplicated-branches, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64279
--- Comment #3 from Marek Polacek ---
Yea, as usually, macros will need to be taken into account here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77533
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77534
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77532
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #20 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77559
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77559
--- Comment #2 from Markus Trippelsdorf ---
It works with -std=c++98.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558
Tom de Vries changed:
What|Removed |Added
Summary|c-c++-common/va-arg-va-list |c-c++-common/va-arg-va-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63416
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64316
--- Comment #5 from Jan Hubicka ---
Author: hubicka
Date: Sun Sep 11 12:08:28 2016
New Revision: 240081
URL: https://gcc.gnu.org/viewcvs?rev=240081&root=gcc&view=rev
Log:
PR ipa/64316
* gcc.dg/ipa/pr63416.c: New testcase.
Added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159
--- Comment #3 from Jan Hubicka ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Sun Sep 11 12:15:02 2016
New Revision: 240082
URL: https://gcc.gnu.org/viewcvs?rev=240082&root=gcc&view=rev
Log:
PR ipa/61159
* compile/pr61159.c: New testcase
Added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77554
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57726
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77551
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50147
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71089
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77556
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77552
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71915
Martin Liška changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557
--- Comment #3 from Jonathan Wakely ---
N.B. for clang 3.9 the program prints "top level" not the constructor name.
__PRETTY_FUNCTION__ is a non-standard extension so the standard says nothing
about how it works. The similar function-local prede
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558
--- Comment #4 from Christophe Lyon ---
(In reply to Tom de Vries from comment #2)
> Fails for arm as well (as mentioned here:
>
> The failure is different, but the root cause is the same. Also the ICE
> already appears before the patch introduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
--- Comment #7 from Sascha Steinbiss ---
Is there any progress on this? Actually such a functionality as provided by
-ffile-prefix-map would also be highly desirable in the context of the
Reproducible Builds effort [1]. Build-specific source path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77560
Bug ID: 77560
Summary: Redefinition of lower bound in explicit-shape dummy
argument
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77560
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77560
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77553
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
Bug 32834 depends on bug 77560, which changed state.
Bug 77560 Summary: Redefinition of lower bound in explicit-shape dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77560
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71231
--- Comment #17 from Dominique d'Humieres ---
> This problem seems fixed. The runtimes are back to normal.
AFAICT the output does not seem right with r240076 and "-fprotect-parens -Ofast
-funroll-loops -ftree-loop-linear -fomit-frame-pointer -fw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
--- Comment #5 from Yu Xuanchi ---
So there is a problem clang does not support nested function. Like:
-
void foo() {
void foo1() {
// Bar
}
}
-
And cpp also not supported. But gcc support it as an extensions. So how we deal
with code lik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63263
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693
--- Comment #5 from Jonathan Wakely ---
See also PR 77524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77561
Bug ID: 77561
Summary: Unclear diagnostic for invalid declaration of partial
specialization as friend
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
--- Comment #6 from Yu Xuanchi ---
So I think in short term. We just reject those code. Because our aim is to
support this feature like clang. If there is no any problem. I'll go impl it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
--- Comment #7 from Yu Xuanchi ---
And there is another option. Because clang documentation say:
"However, when an overloadable function occurs within an extern "C" linkage
specification, it’s name will be mangled in the same way as it would in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #10 from DB ---
(In reply to Manuel López-Ibáñez from comment #8)
Thanks for the thoughts!
> Those "artificial kludges" not only silence the warning, but also make the
> code more readable and help the optimizer. A call to abort()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557
--- Comment #4 from Martin ---
(In reply to Jonathan Wakely from comment #3)
> N.B. for clang 3.9 the program prints "top level" not the constructor name.
And for __func_ clang 3.9 has has an empty string. Which makes me think clang
3.9 moves th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
--- Comment #8 from Yu Xuanchi ---
I have test extern "C" in clang. Look like clang dose not actually mangled it
to "C format". I think because clang C front-end actually not have any mangle
logic. So it just mangled it like CPP front-end does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77561
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> The user is not trying to declare a specialization, they're trying to define
> a friend. The error should tell them that is allowed,
Oops, should tell them t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #11 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #6)
> This should probably depend on the -fstrict-enums flag, as that controls
> whether enums can have any value or just those values that are enumerated.
No, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #12 from DB ---
(In reply to Jonathan Wakely from comment #11)
> Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> -fstrict-enums tells the compiler it will never have a value outside that
> range. It does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77511
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77511
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-w64-mingw32
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546
--- Comment #5 from PeteVine ---
ARMv7 for example is not affected, on the contrary, GCC6 posts a very small
improvement (29.2 vs 29.0).
Back on aarch64, however, GCC7 is able to get some of the lost performance back
@ 37 avg. A clue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77530
--- Comment #4 from Vincent Lefèvre ---
Note that the current behavior should be correct on NetBSD 7. But it isn't on
NetBSD 5.1 and 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
Andrew Pinski changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
Andrew Pinski changed:
What|Removed |Added
Depends on||24021
--- Comment #5 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68082
Andrew Pinski changed:
What|Removed |Added
Target|m68k|m68k-linux
--- Comment #6 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68086
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68048
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562
Bug ID: 77562
Summary: large amount of memory usage when allocating big
arrays
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67739
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic, wrong-code
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562
--- Comment #1 from Andrew Pinski ---
There is a dup of this bug somewhere already. Basically the front-end decides
it is going to "unroll" the loop for the constructors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562
Andrew Pinski changed:
What|Removed |Added
Keywords||memory-hog
--- Comment #2 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to DB from comment #10)
> Yeah, I've since thought of using abort(), which as you say, silences the
> warning - and indicates with sufficient strength that this shouldn't happen.
> assert() i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562
--- Comment #3 from programmerjake at gmail dot com ---
I would think that unrolling loops would be best left till after
gimplification.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468
--- Comment #7 from PeteVine ---
$ gcc $CFLAGS -o c-ray-mt c-ray-mt.c -lm -lpthread && ./c-ray-mt -t 32 -s
160x120 -r 8 -i sphfract -o output.ppm
-mcpu=cortex-a53 : Rendering took: 2 seconds (1958 milliseconds)
-mcpu=cortex-a73 : Rendering took:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68203
Andrew Pinski changed:
What|Removed |Added
CC||programmerjake at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562
--- Comment #5 from Andrew Pinski ---
Note I suspect this is due to "long a = 1;" being treated as a constexpr
something like that now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
--- Comment #11 from Markus Trippelsdorf ---
(In reply to Bernd Edlinger from comment #9)
> I'm unable to reduce the test case...
Creduce is running and hopefully I will have a small testcase tomorrow morning.
trippels@gcc2-power8 ~ % cat chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
--- Comment #12 from Bernd Edlinger ---
(In reply to Markus Trippelsdorf from comment #11)
> (In reply to Bernd Edlinger from comment #9)
> > I'm unable to reduce the test case...
>
> Creduce is running and hopefully I will have a small testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67751
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67731
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67242
--- Comment #4 from Andrew Pinski ---
There might be a dup of this one already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60633
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562
--- Comment #6 from programmerjake at gmail dot com ---
(In reply to Andrew Pinski from comment #5)
> Note I suspect this is due to "long a = 1;" being treated as a constexpr
> something like that now.
it is. In the original code I had, S has a c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71912
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72717
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69188
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.5
Summary|[Regression 5/6/7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77371
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77514
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77514
Andrew Pinski changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #3 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77526
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77518
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77527
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77541
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77545
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.3
1 - 100 of 119 matches
Mail list logo
