https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83473
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83484
Jonathan Wakely changed:
What|Removed |Added
Keywords|link-failure|accepts-invalid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83511
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
--- Comment #14 from Jonathan Wakely ---
(In reply to Aso Renji from comment #13)
> Still have same problem in g++ 6.3.0. So, please reopen this bug.
What do you mean by "same problem"? The original testcase does not produce a
warning with GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83450
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83557
--- Comment #2 from m68k ---
Thanks for the feedback of this forgotten/unexpected behavior.
The funny part of this is, that the rules are not easy to adopt
see what printf("%c\r\n", 'A');
5.LC1:
6 0002 25630D0A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83557
--- Comment #3 from m68k ---
Thanks for the feedback of this forgotten/unexpected behavior.
The funny part of this is, that the rules are not easy to adopt
see what printf("%c\r\n", 'A');
5 .LC1:
6 0002 25630D0A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
--- Comment #18 from sergey.shalnov at intel dot com ---
Yes, I agree that vector_store stage has it’s own vectorization cost.
And each vector_store has vector_construction stage. These stages are different
in gcc slp (as you know).
To better illu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735
--- Comment #3 from Jonathan Wakely ---
Those Python exceptions come from GDB, but I'm not sure why.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83533
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83538
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83450
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Sun Dec 24 09:17:38 2017
New Revision: 255992
URL: https://gcc.gnu.org/viewcvs?rev=255992&root=gcc&view=rev
Log:
PR libstdc++/83450 avoid -Wreturn-type warning in test
PR libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83450
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
--- Comment #15 from Aso Renji ---
(In reply to Jonathan Wakely from comment #14)
> What do you mean by "same problem"? The original testcase does not produce a
> warning with GCC 6.3.0
No, this warning still appear if (and only if) you use -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83580
Bug ID: 83580
Summary: Wrong constant folding
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83581
Bug ID: 83581
Summary: [8 Regression] ICE in expand_LOOP_VECTORIZED, at
internal-fn.c:2397
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83567
Paul Thomas changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83567
--- Comment #2 from Paul Thomas ---
Created attachment 42962
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42962&action=edit
A partial fix for the PR
The attached patch clears the ICE and yields the correct result. However, there
is still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83533
--- Comment #3 from Rostislav Povelikin
---
(In reply to Jonathan Wakely from comment #2)
> GCC 4.7.x has not been maintained or supported by the upstream GCC project
> for several years, and this is already fixed in GCC 4.8.0
Hi Jonathan,
Cou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560
--- Comment #6 from urbanjost at comcast dot net ---
Thanks! As always, I am astonished at what has been accomplished. Fortran's
viability itself depends so much on the availability of an open compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582
Bug ID: 83582
Summary: GCC is unable to fold the code of identical
lambda-expressions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
James Clarke changed:
What|Removed |Added
Attachment #42961|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #14 from Segher Boessenkool ---
(In reply to Jim Wilson from comment #11)
> This part
>
> >r358 is known to have the high half zero:
> > 22: r358:DI=r357:SI#0^r341:SI#0
>
> is wrong. The upper bits of both registers are unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #15 from Eric Botcazou ---
> Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS
> should still be true on ia64 given the description in the documentation.
I disagree, WORD_REGISTER_OPERATIONS means that the (g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83583
Bug ID: 83583
Summary: ICE in synthesize_implicit_template_parm, at
cp/parser.c:38794
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #16 from Jim Wilson ---
That referred patch was written by Eric Botcazou for PR59461 which is for
SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value in a
64-bit reg are undefined. So it does not appear to be c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #17 from James Clarke ---
(In reply to Eric Botcazou from comment #15)
> > Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS
> > should still be true on ia64 given the description in the documentation.
>
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #18 from Jim Wilson ---
SPARC defines WORD_REGISTER_OPERATIONS, and works the same as ia64. The upper
bits of a 64-bit register after a 32-bit operation are don't care bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #19 from James Clarke ---
(In reply to Jim Wilson from comment #16)
> That referred patch was written by Eric Botcazou for PR59461 which is for
> SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value
> in a 64-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #20 from Jim Wilson ---
I don't see the distinction here. Ia64 has instructions that operate on 32-bit
values too, like cmp4.
On sparc, given this testcase
int
sub (int i, int j, int k)
{
return i + j + k;
}
the compiler generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582
--- Comment #2 from Andrew Pinski ---
Most likely because the requirement that two different lambdas need not to
compare equal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83581
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
Component|rtl-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83237
--- Comment #5 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Sun Dec 24 22:08:52 2017
New Revision: 255993
URL: https://gcc.gnu.org/viewcvs?rev=255993&root=gcc&view=rev
Log:
2017-12-24 Michele Pezzutti
PR libstdc++/83237
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83533
--- Comment #4 from Jonathan Wakely ---
This was a bug in GCC 4.7.x which is fixed in GCC 4.8.0
We already fixed it, and do not support GCC 4.7 (or anything older than GCC 6),
so there's nothing more we can do. Either use the workaround or use a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
Bug ID: 83584
Summary: "ISO C forbids conversion of object pointer to
function pointer type" -- no, not really
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #1 from Keith Thompson ---
Tested on x86_64 Ubuntu 17.04, gcc 7.1.0 built from source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #2 from Andrew Pinski ---
Your reading of the spec is different than the GCC folks read it.
See PR 11234 which requested the error in the first place. Note C11 and
C89/C90 has not changed in this area as far as I can tell.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #4 from Keith Thompson ---
I'm aware that the standard has not changed in this area from C90 to C99
to C11. The conversion is undefined behavior, not a constraint violation,
in all three editions.
If the conversion is forbidden, wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83520
--- Comment #3 from Touma Hatano ---
Sorry for misleading.
My point was that if we can replace
snprintf (program_name, sizeof (program_name), program_invocation_name);
with
snprintf (program_name, sizeof (program_name), "%s",
program_invocati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480
--- Comment #3 from Arseny Solokha ---
Likely a duplicate of PR80463.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83585
Bug ID: 83585
Summary: [8 Regression] Assembler messages: Error: can't
resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560
--- Comment #7 from Jerry DeLisle ---
Patch posted here:
https://gcc.gnu.org/ml/fortran/2017-12/msg00089.html
46 matches
Mail list logo
