https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68082
--- Comment #7 from angelo ---
Hi Andrew,
it is passed some time, i solved mainly the issue with a workaround.
Yes i tested several binutils even last, but is more a matter of compiling the
m68k/coldfire toolchain properly.
Mainly, building if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71776
malithyapa at gmail dot com changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71776
malithyapa at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
--- Comment #14 from Markus Trippelsdorf ---
The reduced testcase needs libstdc++.so from trunk. Otherwise you'll get
undefined reference errors to
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_ .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
--- Comment #13 from Markus Trippelsdorf ---
Created attachment 39606
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39606&action=edit
somewhat reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77528
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #2 from TC ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67856
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67750
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64598
Andrew Pinski changed:
What|Removed |Added
Target||i586-scc-linux-gnu
Status|WA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59857
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #15 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #11)
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #14 from Eric Gallager ---
(In reply to Manuel López-Ibáñez from comment #9)
> 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
> wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67807
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.3
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=77527
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=77526
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |7.0
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=77514
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=77371
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.3
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=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=72717
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.5
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=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=60633
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=67731
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|r
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=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=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=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=68203
Andrew Pinski changed:
What|Removed |Added
CC||programmerjake at gmail dot com
--- Comm
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=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=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=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=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
Andrew Pinski changed:
What|Removed |Added
Keywords||memory-hog
--- Comment #2 from Andrew Pi
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=67739
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic, wrong-code
Statu
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=68048
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=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=68097
Andrew Pinski changed:
What|Removed |Added
Depends on||24021
--- Comment #5 from Andrew Pinski
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=77550
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
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=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=77511
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-w64-mingw32
Status|UN
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=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=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=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=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=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=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=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=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=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=24693
--- Comment #5 from Jonathan Wakely ---
See also PR 77524
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=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=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=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=77560
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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
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=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=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=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=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=77552
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=71089
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=77551
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=77554
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
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=61159
--- Comment #3 from Jan Hubicka ---
Fixed.
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=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=63416
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=77559
--- Comment #2 from Markus Trippelsdorf ---
It works with -std=c++98.
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=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=77532
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 119 matches
Mail list logo