https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80036
Bug ID: 80036
Summary: Source line not printed for diagnostic if expanded
from a macro
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80037
Bug ID: 80037
Summary: Bad .eh_frame data in crtend.o
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80037
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
--- Comment #8 from Jerry DeLisle ---
(In reply to Walt Brainerd from comment #7)
> I took "not processed by" to mean that there is no DT edit descriptor
> corresponding to it.
>
> But I see how this might be interpreted otherwise.
>
> Intel ag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856
--- Comment #7 from Martin Liška ---
(In reply to Roland Illig from comment #6)
> I would define the rules as follows, the first matching rule wins:
>
> 1. do not translate messages that contain names of GCC implementation
> functions
>
> 2. do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79820
--- Comment #4 from niXman ---
(In reply to Jonathan Wakely from comment #3)
> and it also needs to be done on line 275.
why?
line 275:
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/config/io/basic_file_stdio.cc?view=markup#l275
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #9 from Jerry DeLisle -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #26 from Jerry DeLisle ---
(In reply to janus from comment #25)
> (In reply to Jerry DeLisle from comment #24)
> > I dont think the parent is suppose to emit the Object name. What if there
> > are multiple components?
>
> Huh, I'm no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80006
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382
--- Comment #9 from Jerry DeLisle ---
Can this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80007
--- Comment #9 from PeteVine ---
Correction, it was about -fomit-frame-pointer period! Setting the environment
C(XX)FLAGS to that flag alone triggers the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79800
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905
--- Comment #3 from Bill Schmidt ---
So, is the desired behavior that the front end produce an error message
instead? Or is the front end supposed to unify these two types and accept the
code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #15 from Palmer Dabbelt ---
Created attachment 40968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40968&action=edit
glibc file that loops
The suggested patch causes an infinate loop while building glibc for RISC-V.
The prepr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80017
--- Comment #1 from Vladimir Makarov ---
Thank you for the report. I've reproduced and started to work on it. The fix
will be probably ready on Wednesday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #27 from Jerry DeLisle ---
With the patch applied and the following test case:
MODULE m
IMPLICIT NONE
TYPE :: t
integer :: j
CHARACTER :: c
integer :: k
CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE
101 - 116 of 116 matches
Mail list logo